HylaFAX The world's most advanced open source fax server
[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*

Project hosted by iFAX Solutions