|
Hylafax Mailing List Archives
|
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
Re: [hylafax-users] Hylafax Client - Server problem
I have to say most of the times this question comes up (which is a lot),
it is answered with only partial fragments of the whole story, and I
don't find the recent answers much better.
I've also Googled for this repeatedly because it trips me up every time
I move some services from one server to another and my Hylafax client at
the new location ceases to be able to send to my hylafax server. You
can also Google for getting ftp working through a firewall/router and it
is just as confusing, where many people ask the question, and every
answer is a little different, and none is just right for me. Of course
it doesn't help that the "correct" answer has changed over time as the
versions of ipchains, iptables, etc. have changed.
I think I've even griped before about this lack of a definitive answer
or thorough how-to on this topic. Or maybe I just grumbled to myself
and never got around to actually griping to the list. Anyway, can I
give the full answer that will work for everyone? Probably not because
there are so many different setups out there. But here goes.
Hylafax protocol between the client and the server, like ftp, uses two
ports, a control port and a data port. The control port for hylafax, by
default, is 4559 (equivalent to port 21 for ftp), so the hylafax server
is listening there. The client initiates by sending a request with the
source port set to some high port number (>1024), and the destination
port is 4559. So to get this through your firewall/router, you just
have to forward all port 4559 traffic arriving at the firewall's
external IP to port 4559 at the Hylafax server's (internal) IP. Simple
hylafax protocol commands like CD, or PWD, (most of which are the same
as ftp commands) that only require short responses will work with this
setup. You can test this with a normal command line ftp client that
accepts a port number argument:
# ftp fax.mydomain.com 4559
Connected to fax.mydomain.com.
220 fax.mydomain.com server (HylaFAX (tm) Version 4.2.0) ready.
Name (fax.mydomain.com:root): root
230 User root logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
257 "/" is the current directory.
Commands like LS, DIR, GET, PUT that require longer responses need to
use the data port. If the client is in active mode (which sendfax is,
and I don't see any options to change that), it sends the server (over
the already-working command port) the PORT command to tell the server to
use the some other high port number for data, then the client listens on
that port number, and the server initiates a connection to the client
with source port 4558 and a destination port of the high port just
indicated by the client. If the client is in passive mode, it sends the
PASV command (over the already-working command port) and the server
answers with some high port number and begins listening on that port,
and the client makes a connection from some high port on itself as the
source port, to the high port that the server just indicated as the
destination port.
So if you haven't figured a way to get that (active) server-to-client
connection or that (passive) client-to-server connection through your
firewall/router, those commands (LS, DIR, etc) probably won't work yet,
they will fail in one of the following two ways:
For example, if the client is using passive ftp, I get this (because the
server is providing its LAN IP address for the data connection, which
the client, being on the internet, cannot route to):
ftp> ls
227 Entering passive mode (192,168,1,10,9,247)
ftp: connect: No route to host
If the client is using active ftp, I get this:
ftp> passive
Passive mode off.
ftp> ls
200 PORT command successful.
425 Cannot build data connection: No route to host.
You can see similar stuff if you test things from the client machine
with the command line program sendfax, and use the -v or -vv (verbose)
option.
Actually the fix for me was to change the client's (!) iptables to allow
ALL connections from the server:
(in /etc/sysconfig/iptables:)
-A RH-Firewall-1-INPUT -s fax.mydomain.com -m state --state NEW -m tcp
-p tcp -j ACCEPT
Once I got this working, I tried sendfax using a huge file, so I'd have
time to run netstat on the client, on the firewall/router, and on the
server to see what was going on. Here is a portion of the sendfax output:
...
-> TYPE I
200 Type set to Image.
SEND compressed data, 4788968 bytes
-> PORT CLIENTIP,235,100
200 PORT command successful.
-> MODE Z
200 Mode set to ZIP.
-> STOT
150 FILE: /tmp/doc15850.ps (Opening new data connection).
SEND 1945462 bytes transmitted (2.5x compression)
226 Transfer complete (FILE: /tmp/doc15850.ps).
...
(note: in that PORT line, I've replaced the comma separated IP address
with "CLIENTIP", and the meaning of the 235,100 is the port number 235 *
256 + 100 = 60260, which agrees with what is seen below.)
And here is the netstat output... In the following, I've replaced actual
IP addresses with CLIENTIP (the client), EXTERNALIP (the firewall).
Also 192.168.1.1 is the firewall's LAN interface, 192.168.1.10 is the
server's LAN interface:
From the client's point of view, the connections were (netstat -n):
Proto Recv-Q Send-Q Local Address Foreign
Address State
tcp 0 0 CLIENTIP:60259 EXTERNALIP:4559 ESTABLISHED
tcp 0 24616 CLIENTIP:60260 EXTERNALIP:63844 ESTABLISHED
from the firewall's point of view:
tcp 0 0 192.168.1.1:2096 192.168.1.10:4559
ESTABLISHED
tcp 0 0 EXTERNALIP:4559 CLIENTIP:60259 ESTABLISHED
from the server's point of view:
tcp 0 0 192.168.1.10:4558 CLIENTIP:60260 ESTABLISHED
tcp 0 0 192.168.1.10:4559 192.168.1.1:2096
ESTABLISHED
It seems that from the server's point of view, it is connecting its port
4558 all the way to the client IP, port 60260. But from the client's
point of view, it is coming from the firewall's IP, port 63844 to the
client's port 60260. (I think this is because of masquerading packet
modifications on the firewall/router.) Neither of these high port
numbers is predictable, so that's why I had to open up the client's
firewall to allow connections from the server.
If you can digest that, you'll see why I couldn't make up a more
restrictive firewall rule on the client. The data connection comes from
the server with an unpredictable source port and unpredictable
destination port (63844 and 60260 in the above example).
So I hope that answers the question of the current thread, and more
importantly, I hope that is most of the answer for most of the people
who look for this question in the archives. I have to admit I don't
know about the ip_conntrack_ftp suggestion made by Kimble. But like I
said, I have mine working and I've not set up any connection tracking on
the firewall. But even with connection tracking, I don't see how that
would improve the situation of the client accepting the data connection
from the server.
If anyone who REALLY knows the Hylafax protocol can correct, clarify, or
elaborate on any of the above, please enlighten me.
Regards.
Martin
Kimble Young wrote on 19/11/04 01:19 PM:
Thomas
The problem is that your router is not doing the ftp connection
tracking on port 4559. In linux it is easy as making sure that
ip_conntrack_ftp is running with 4559 specified as one of the ports.
eg
insmod ip_conntrack_ftp ports=21,4559
What was happening to me was the client was connecting but not able to
transfer the postscript file and was hanging at this point.
support wrote:
Hi,
I have port 4559 forwarded on NAT. My host.faxd is correct. Will it
be my
NAT problem or hylafax does not support NAT address translation?
Thomas
----- Original Message ----- From: "Matthias Reich" <rei@xxxxxxxx>
To: "support" <support@xxxxxxxxxxxx>
Cc: <hylafax-users@xxxxxxxxxxx>
Sent: Friday, November 19, 2004 2:21 PM
Subject: Re: [hylafax-users] Hylafax Client - Server problem
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Freitag, 19. November 2004 04:26 schrieb support:
Hi everyone,
I have set up a fax server using hylafax version 4.20 on fedora core 2
recently. It works fine.
If I put the fax server behind an NAT, (i.e. fax server has an
internal IP
192.168.1.xx), some problem occurs when I try to use print-to-fax fax
client to sent a fax from windows to fax server. For example, if I use
WHFC
to send a fax from windows to hylafax using default port 4559, where
hylafax server is behind NAT, the data connection seems hanging up. The
document could not be sent to fax server.
However, if I remove the NAT and set the hylafax server IP to a
public IP
220.246.21.xx, the document can be sent successfully from windows
through
port 4559.
Is there a solution solving this kind of problem? Thank you.
Thomas Tam
------------------------------------
support@xxxxxxxxxxxx
Hi Thkmas,
did you check your rules of the NAT is port 4559 forwarded ?
check your hosts.hfaxd file if you are permitted to connect
(see man hosts.hfaxd)
____________________ HylaFAX(tm) Users Mailing List _______________________
To subscribe/unsubscribe, click http://lists.hylafax.org/cgi-bin/lsg2.cgi
On UNIX: mail -s unsubscribe hylafax-users-request@xxxxxxxxxxx < /dev/null
*To learn about commercial HylaFAX(tm) support, mail sales@xxxxxxxxx*
