2 Issues with pfSense 1.2 RC3
-
Is is possible that doing an upgrade from 1.0.1 rather than a clean install of 1.2 RC3 is causing my FTP hell?
-
That's why I asked about the pftpx process in ps.
I followed that pointer, thanks. I ran the command in the shell and got some feedback that I couldn't interpret. But there was one line and you said to expect one per Helper-Enabled Interface, so that seemed right to me.
-
See also:
http://forum.pfsense.org/index.php/topic,6107.0.html
Which I'm having a hard time understanding…
-
This issue seems to go WAY back:
http://www.mail-archive.com/discussion@pfsense.com/msg01852.html
-
FTP (outbound) works fine here. Granted we only have one WAN, one LAN(vlan), and one OPT(vlan). The FTP helper etc. is DISBALED on all interfaces. No special port forwards/firewall rules on 21 or anything like that. We just had to tinker with the ftp proxy option on different interfaces but we got there. Lucky for us we were one of the 99% user error category.
-
Thanks mhab12.
Could you provide some detail on the "tinker with the FTP proxy options" for me?
-
Tinker with the FTP proxy options = Toggle the FTP proxy option on and off in various combinations across all your interfaces.
-
Okay… In the newest version I think it's called "FTP Helper", so I'm assuming we're talking about the same thing.
Thanks for your help.
-
FTP Helper is a FTP Proxy. It is called "FTP Helper" in the GUI but it's basically a proxy.
-
Thanks. At this point, I've come to the conclusion there are some very serious bugs in the FTP HELPER (proxy) in PFSense 1.2 RC3. I know many people have posted that they have it working, but I've now put over 40 hours into this single issue (yes, it's crazy) and I simply can't get it to work with my config. I'm thinking it has to do with being Multi-WAN and CARP…
I am, sadly, going to back-out my PFSense HA implementation and go back to SmoothWall until I can get FTP working on the bench. I had neglected to test FTP before putting this into production (my bad), and had also assumed this would not be a big deal. From the volume of posts around, it certainly IS a big deal. My personal belief is that it will hold this software back until addressed. I know what the sentiment is for FTP, and I don't disagree on technical grounds, but it's simply used too much by big corporate players today to be overlooked...
When I get back on SmoothWall, I will start removing pieces of my PFSense config to see if I can isolate exactly where FTP dies on the bench. I'm going to try a single-WAN / CARP config next... See if that works. If it doesn't I will try single-WAN single PFSense, see if that works. Sure hope the larger community decides FTP needs attention before RC3 becomes a real release....
All the input and time responding to my questions is deeply appreciated.
-
Thats strange as I know of NO FTP bugs…. Maybe you should walk through http://devwiki.pfsense.org/FTPTroubleShooting first.
-
When I get back on SmoothWall, I will start removing pieces of my PFSense config to see if I can isolate exactly where FTP dies on the bench. I'm going to try a single-WAN / CARP config next… See if that works. If it doesn't I will try single-WAN single PFSense, see if that works. Sure hope the larger community decides FTP needs attention before RC3 becomes a real release....
IMO It's always a good practice to do a test with as default install as possible first. If that works one can move closer to one's intended install until it breaks. Then report what has been done so it is possible to duplicate.
I do also appreciate when software is released, that known limits is shown beside features.
just my 2 cent…..
-
Thats strange as I know of NO FTP bugs…. Maybe you should walk through http://devwiki.pfsense.org/FTPTroubleShooting first.
Thanks… But I've been through that like 6 times.
-
Thats strange as I know of NO FTP bugs…. Maybe you should walk through http://devwiki.pfsense.org/FTPTroubleShooting first.
Thanks… But I've been through that like 6 times.
Well thats fine but it really does fix 99% of the edge cases. I Honestly see nothing strange with your configuration. So suit yourself.
-
Thats strange as I know of NO FTP bugs…. Maybe you should walk through http://devwiki.pfsense.org/FTPTroubleShooting first.
Thanks… But I've been through that like 6 times.
Well thats fine but it really does fix 99% of the edge cases. I Honestly see nothing strange with your configuration. So suit yourself.
Gotta love being the 1 exception in 100!! ;D Believe me when I tell you that I would LOVE to have done something to mess this up because that would mean that I could fix it. I will take all of the above suggestions about starting from factory install (again) and building up with FTP tests at every change.. I will report that data back as I would hope it could help the community or someone else hitting this same wall.
-
Okay, as promised, I wanted to report back on my efforts to find EXACTLY where my FTP problem came into play. As mentioned above, I had to back-out my implementation of PFSense from production so I could do the experimentation on the bench. As suggested, I started building from the factory install up to see where it was.. And, thankfully, I found it.
Also as promised, I'm ready to eat crow and firmly admit that this was user-driven. I made a very small config change that caused this. Yes, totally my fault (which is actually what I was hoping for)… But for others who might hit this, I wanted to document it because nothing I read pointed me to this outcome and I sunk over 40 hours of time into this.
MY CONFIG: Dual-WAN, Dual PFSense boxes with CARP for high-availability fail-over using Virtual IPs for both WAN interfaces (WAN and OPT1) and a Virtual IP for the LAN interface (Default Gateway for all clients on LAN). CARP running over OPT2 with a cross-over cable. PORT FORWARDS for 80 and 443 and Firewall rules to allow traffic on both WANs for web servers. I use an OUTBOUND NAT (FIREWALL / NAT / OUTBOUND) on both WANs so that the source IP for outbound traffic was consistent regardless of which physical box was MASTER (otherwise the source is the address on the interface). This is important if you run any web services that verify your source IP or a VPN tunnel, etc. Additionally, I wanted all LAN traffic to appear to come from the default gateway and not the interface of the box that was MASTER, so I had an outbound NAT on the LAN as well.... FTP HELPER is DISABLED (checked) on all interfaces except LAN (where it is active) as the directions state.
FTP BEHAVIOR: I was able to initiate an FTP session from inside LAN to an FTP server on the internet. I could log in successfully. However, as soon as I did a GET, PUT or DIR, the session hung and eventually timed out.
MY MISTAKE THAT BROKE FTP: In the Outbound NAT on WAN, you CAN NOT have the source IP be *... This will kill the FTP helper / proxy. The source in the rule for the outbound NAT needs to be your specific LAN NETWORK (10.1.1.0 / 24 in my case). Even with the loopback rule in place (as the directions state), FTP will not function. After I changed the OUTBOUND NAT rule SOURCE to 10.1.1.0 / 24, my FTP sessions (PUT, GET and DIR) all worked instantly.
After thinking about this for a while, I think I see why it killed FTP. From what I've read, FTP needs a second port to operate. This is what the FTP helper manages. With my OUTBOUND NAT rule set to source = * that second sessions must have been messed up somehow. This would explain why my login would work, but the PUT / GET / DIR would not.. I dunno. That's about the best I can explain it. The good news is that PFSence auto-defaulted to the right setting. So let it do it's thing..
So I'm sure many here are not surprised with this outcome. My lesson (once again): Change as little as possible no matter how little you think the change is... It might bite you! Also, freely admit in your early posts that the problem is likely you ;-)
And I thank everybody for their input. I'm now officially in support of the FTP functionality in PFSense (not that anyone asked) for my config above. We've migrated it back into production and tested failover with great success. We are running about 1,000,000 page loads a day (about 4,000 sessions at any one time) and this software works great on 4 year-old desktops (1.8 Ghz PIV 500 Megs RAM). Given that it's free, this is simply amazing to me..
Thanks again...
-
Thanks for the follow up! Stickying this topic.
-
The perfect fix for me…
Basically the main problem for me on this original post was having FTP resources inside the firewall - accessing FTP resources internally - going out the firewall and then back in. When you try to access an FTP resource you have behind the firewall, it is best and recommended you use DNS internally to point to the FTP address. For example: If you have ftp.company.com and that is inside your border / behind the firewall, it is best if you just create a DNS entry for that internally using internal IP Address so it does not even go out and back in through firewall. Some people use the DNS forwarder of pfSense, but I just use Active Directory's DNS since I use AD for all my clients. All my internal AD zones uses something like company.local so it works well along with another DNS zone of company.com. Having the second zone for external addresses / internal resource allows me to not even go through the pfSense gateway/firewall and back in - so FTP works period - without all the hacks required.
EXAMPLE / CLARIFICATION: I have an FTP public resource of 66.x.x.x from the outside with address of ftp.company.com. Internally, if I did this BEFORE it would go out the firewall since it is public and then try to come back in - this did not work using stock/default setup on 1:1 NAT. The workaround as stated above is to create a DNS pointer or forwarder to the internal servers internal ip address - so it never goes out anymore - since its part of internal DNS entries/zone. So instead of of pointing to 66.x.x.x, I create a DNS entry for internal users at the internal ip address of 192.168.x.x/24 for any company.com public address - therefore the traffic never goes out the firewall for any of my public company.com addresses. The ftp.company.com would point to 192.168.x.x (in my DNS zone for internal DNS server - this is not the main / public DNS server - not the actual SOA/NS for external clients) instead of public/routable ip address of 66.x.x.x. Hope this clears it up for alot of folks.
-
Excellent write-up. Yes, that's a common problem. Use DNS or host files to fix it and keep things from jogging out and back in the firewall when it's not needed. I've seen the same issues in a Netscreen / Juniper evironment as well…
Little update on my November FTP problem: All still good 6 months later. This software is simply awesome. Running millions of sessions a day in HA, with multiple WANS on extremely inexpensive hardware (like $400 for both boxes). No FTP problems at all.
I really can't say enough positive about this Firewall software. Unbeatable.
-
Thanks Scott and Team for such a great tool of pfSense. I have been using it for about a year without issue! Started with 1.0.1, and just now upgraded to 1.2 and looking great.
So I guess this is my first REAL issue which I just cannot for the life of me figure out. I also cannot get incoming FTP to work. I have now spent some 20 hours scouring the web, reading the troubleshooting guide, and tons of forum posts on this topic, and this was the most helpful post, but still can't get this to work.
I have the default setup with the LAN, 1 WAN, and the OPT1 enabled (renamed DMZ). I have doubled and trippled back many times and tried as many combinations of enableing/disabling FTP Helpers on the different interfaces, and then removing, and recreating the NAT port forward which creates the firewall rules through FTP Helper. NOTHING WORKS.
Here's my main problem it seems. There seems to be an issue when ENABLING FTP Helper on my WAN for some reason. If I enable it, then create the NAT Port forward for port 21, it tells me FTP Helper is creating the firewall rules required on the WAN for it to work (it creates 2). However, whenever I have FTP Helper enabled on the WAN, for some reason, I CANNOT connect to the FTP At all. I.e.:
[05:48:35] Connection attempt 14…
[05:48:35] Resolving host name "x.x.x.x"
[05:48:35] Connecting to x.x.x.x Port: 21
** (Host IP hidden)However, If I go in and disable the FTP Helper on the WAN, and then recreate the NAT Port Forward/rules needed… I CAN connect to the FTP, however, the FTP Server sends me the internal IP such as 10.1.1.100 instead of the public IP. Since the FTP Helper is disabled on the WAN, it of course is not translating the PASV connection attempt comming from the server and replacing the internal IP with the external INTERFACE IP.
So my question is why would it be that by just Enabling the FTP Helper on the WAN (and of course deleting and recreating the NAT Port Forward/rules for FTP Post 21), that all of a sudden I CANNOT even connect to the FTP Server? BTW, I did try from multiple clients (SmartFTP, IE, and IPSwitch WS_FTP, and they all do the same!!!!).
I have tried recreating this over and over, and I cannot seem to figure out why this is happening.