Multi-WAN and active FTP in 2.0.0

jimicus

Hi,

I'm having difficulty with active FTP across a multi-WAN pfSense cluster with the WAN interfaces set up as a failover pair. (Circumstances are forcing me to use active FTP. Passive does work, but I can't use it.) This was previously working fine in 1.2.3 and was upgraded through the automated upgrade process (ie. I didn't reinstall from scratch and reload configuration from a backup).

Brief overview of configuration:

Two WAN interfaces. One has a public IP address and operates NAT, the other does not (and doesn't NAT). For the purpose of this, we'll call the interface on the public internet WAN and the interface that is already NAT'ed ADSL. The default gateway is WAN; there is a gateway group in place which places ADSL above WAN in tiering.
Traffic is routed using policy-based firewall routing; there is no FTP-specific rule but all public internet traffic is forced over the failover group.

I'm seeing the following behaviour:

Client establishes FTP command session with server. This goes across ADSL and works.
Client attempts to do something that uses FTP data traffic (anything will do)
The server sends a TCP SYN from port 20 to a random port on the client. pfSense allows this and the TCP SYN is seen coming in the ADSL interface, traversing the firewall and leaving the interface pfsense shares with the client.
The client sends a TCP SYN/ACK back to the server. pfSense sees this coming in but it never leaves the pfSense unit. Examination of the logs suggests that the returning SYN/ACK was passed onto the WAN interface where it was blocked - I assume because there was no corresponding TCP SYN state relating to that connection. Note it should have been passed across the ADSL interface.

I have been able to workaround this by forcing all FTP traffic across the default gateway.

I can't find any obvious reason why this should be, nor does a quick google suggest anyone else has resolved this. Did I miss something?

Gertjan

Hi !

Two questions pop up:

You use a upgraded system. What about testing a Relesase 2.0 version, using i.e. a LiveCD boot ?
Switching to a single WAN connection drops the problem ?

jimicus

Switching to a LiveCD with the same configuration isn't an option, unfortunately - the firewall in question is in a live environment which I can't risk messing with.

But given the nature of what I've seen - and that forcing all FTP traffic across the default gateway provides an effective workaround - I'd imagine setting it up with a single WAN link would work just fine.

Gertjan

@jimicus:

Switching to a LiveCD with the same configuration isn't an option, unfortunately - the firewall in question is in a live environment which I can't risk messing with.

That's why you could use a LiveCD.
It will be a question of rebooting from CD, which will down the Internet connection for about 30 sec. and 2 minutes for you to to setup up a LAN interface. Then, using the GUI interface, your import your settings XML file (take the one you saved on your PC from your hard disk install).
Booting from CD will not touch the install on the hard disk !!Rebooting without CD will boot the hard disk install as before.

Normally, you should be allowed to bring the firewall down for a minute or 2 - otherwise you could even apply patches and updates that need a reboot.
If you can't reboot, then you have a mission critical setup. Your hardware will be doubled, so … test on your spare system then ;)