FTP Server behind pfSense - "Entering passive mode" dropped if invalid IP?
-
Hey everyone
I had to stand up a quick FTP server on my network for reasons and I ran into a weird issue. I followed the instructions to port forward the FTP port as well as the passive mode ports I'm using to the internal host behind pfSense. I configured the FTP server software to use those specific ports. I got on an external connection and tried to get into my FTP server. The connection established fine, but as soon as the client sent the PASV command things died and nothing happened.
I started up packet tracers on both ends of the connection. The client sent PASV command and it was received by the server fine. The server returned "227 Entering Passive Mode (0,0,0,0,204,173)" to the client, but the client never received it and the server kept queuing tcp retransmissions of the packet. The client entered a similar loop with tcp retransmissions of its PASV command packet.
After some finagling I finally figured out that vsftpd won't send the right pasv_address set in the config if it's listening on IPv6. I disabled that, and magically my reply for passive mode changed to the right IP and the packets came through.
The question I have though is regarding why the original reply was dropped. How can I confirm that the reply was dropped by pfSense and why? I've got logging enabled on default drop rules. I have no weird drop rules that would catch this FTP reply. I have no IPS/IDS setup, just a basic pfSense NAT firewall with a couple of VLANs and a tp-link managed switch (SG2008). I can't see any dropped packets in the firewall logs relating to the FTP connection. To all appearances pfSense did nothing to the packets but they were somehow dropped between the server and the client, but only when the 227 reply was an invalid IP (also dropped when it is an RFC1918 IP). Does anyone have an idea where I can start looking to figure out what caused this behaviour and why pfSense dropped the packet (if it did)? Any way to confirm the 227 reply packet goes out the WAN interface to write pfSense off as the source of the issue?
-
What I remember from the FTP server I set up in passive only mode some years ago is that you need to tell the FTP server two things (I can't remember the exact details so this is a little vague):
-
The public IP address where the replies from the server come from to the client. This will modify the response the client gets on connection to use the server's public IP address instead of the private one.
-
The passive ports used (and forwarded on the router/firewall) for listening for data connections.
Edit: I dug out the details, the server was set up using ProFTPd and the directives that were needed were "MasqueradeAddress" and "PassivePorts". Refer to the documentation of the server software you're using for equivalent configuration parameters.
-
-
well (0,0,0,0,204,173) means IP 0.0.0.0 on port (204*256)+173 so how wold that ever work 0.0.0.0 sure isn't your public IP.
If your server sends it rfc1918 address how would the client ever connect to that? When you setup passive server behind pfsense. The server has to send the correct public IP and the ports that it sends has to be forwarded already. Your above would of been port 52397 is that forwarded?
-
well (0,0,0,0,204,173) means IP 0.0.0.0 on port (204*256)+173 so how wold that ever work 0.0.0.0 sure isn't your public IP.
If your server sends it rfc1918 address how would the client ever connect to that? When you setup passive server behind pfsense. The server has to send the correct public IP and the ports that it sends has to be forwarded already. Your above would of been port 52397 is that forwarded?
Yes, I understand quite well it wouldn't work but that's not what I'm going for here. My question isn't because the connection wouldn't have worked anyway, it's why the actual packet was apparently dropped by pfSense. I understand that if the packet was passed the connection wouldn't have worked because the data wasn't right, but what made the decision to drop the packet itself? pfSense isn't acting as an FTP proxy, there's nothing I configured to inspect FTP traffic, all I did was tell pfSense to forward traffic on those ports, it shouldn't care that the encapsulated FTP command setting passive mode is using invalid data for the address. The packet should have been forwarded anyway, the FTP connection fails because the passive command isn't right, I fix it, NBD. But it doesn't seem to be left to fail that way, the packet with the PASV reply doesn't make it to the client at all.
There's no clue in the logs explaining that pfSense dropped the packets. The FTP server sends the packets. I want to confirm if pfSense is the one responsible for dropping them (not forwarding to WAN), and if so, why and where I see that in the logs. Note that I got the original issue fixed, FTP works fine now, but I'm trying to figure out the strange behaviour with the way the reply packet is dropped when the reply with a bad IP is dropped entirely.
-
Why would pfsense drop data inside the control channel because the info was wrong/bad?? Pfsnese doesn't do anything with the data inside the ftp control channel.
Who says that packet didn't get to the client? Did you sniff on the client, did you sniff on pfsense wan and see if it want out? FTP is clear unless your using ftps or ftpes so you can see exactly what is going on with ftp.
-
Yes, like I said in my first message, I sniffed at both server and client. Server sent the packets. Client never saw them.
I see now the Packet Capture option in the diagnostics menu in pfSense. I'll play around with that later to confirm the packets make it out of the WAN interface.
