PFTPX troubleshooting help
-
I need to troubleshoot the PFTPX helper services as I have some very odd issues with it.
##The Problem##
We NAT for a Class C of IP's to one of 3 LANs from the WAN interface, [(Wan -> Lan), (Wan -> Lan2) and (Wan -> Lan3)]All interfaces have helper enabled, FTP Nat rules are in place and all internal interfaces have rules to allow (*) to pass.
We had found that we had to modify ftp rule some what to force a reload of the pftpx services for that given rule when the service failed. (edit the discription field and resave rule, then apply filters) then pftpx service would reload and load the correct helper.
This helped get 99% of the IP's to work finally but we have 1 Nat that just will not go. It is listed when (ps -aux |grep pftpx) is executed but still fails to give us a directory listing inside of FTP.
ps -aux | grep pftp
proxy 4345 0.0 0.1 704 276 ?? Ss 21Aug08 0:07.07 /usr/local/sbin/pftpx -f 192.168.160.6 -b 205.149.143.246 -c 21 -g 21
proxy 4371 0.0 0.1 704 324 ?? Ss 21Aug08 0:27.73 /usr/local/sbin/pftpx -c 8021 -g 8021 192.168.10.2
proxy 4414 0.0 0.1 720 340 ?? Ss 21Aug08 0:11.46 /usr/local/sbin/pftpx -c 8023 -g 8021 192.168.160.10
proxy 4438 0.0 0.0 704 84 ?? Ss 21Aug08 0:07.02 /usr/local/sbin/pftpx -c 8024 -g 8021 192.168.150.2
proxy 12967 0.0 0.0 704 76 ?? SNs 22Aug08 0:07.40 /usr/local/sbin/pftpx -f 192.168.10.234 -b 205.149.143.234 -c 21 -g 21
proxy 15827 0.0 0.1 720 340 ?? SNs 21Aug08 0:11.41 /usr/local/sbin/pftpx -f 192.168.160.4 -b 205.149.143.243 -c 21 -g 21
proxy 18987 0.0 0.0 704 76 ?? SNs 22Aug08 0:07.33 /usr/local/sbin/pftpx -f 192.168.10.24 -b 205.149.143.24 -c 21 -g 21
proxy 19391 0.0 0.1 704 280 ?? SNs 21Aug08 0:11.75 /usr/local/sbin/pftpx -f 192.168.10.35 -b 205.149.143.35 -c 21 -g 21
proxy 22372 0.0 0.1 704 300 ?? SNs 21Aug08 0:07.57 /usr/local/sbin/pftpx -f 192.168.10.126 -b 205.149.143.126 -c 21 -g 21
proxy 22550 0.0 0.1 704 320 ?? SNs 22Aug08 0:08.17 /usr/local/sbin/pftpx -f 192.168.10.103 -b 205.149.143.103 -c 21 -g 21
proxy 28068 0.0 0.1 704 308 ?? SNs 26Aug08 0:09.76 /usr/local/sbin/pftpx -f 192.168.10.208 -b 205.149.143.208 -c 21 -g 21
proxy 31443 0.0 0.1 704 276 ?? SNs 22Aug08 0:07.37 /usr/local/sbin/pftpx -f 192.168.10.236 -b 205.149.143.236 -c 21 -g 21
proxy 49015 0.0 0.1 704 340 ?? SNs Fri08AM 0:01.16 /usr/local/sbin/pftpx -f 192.168.10.32 -b 205.149.143.17 -c 21 -g 21
proxy 50415 0.0 0.1 704 296 ?? SNs 22Aug08 0:08.78 /usr/local/sbin/pftpx -f 192.168.10.249 -b 205.149.143.194 -c 21 -g 21
proxy 50753 0.0 0.1 704 340 ?? SNs Fri08AM 0:01.19 /usr/local/sbin/pftpx -f 192.168.150.230 -b 205.149.143.230 -c 21 -g 21
proxy 52247 0.0 0.1 704 276 ?? SNs 22Aug08 0:07.49 /usr/local/sbin/pftpx -f 192.168.10.235 -b 205.149.143.235 -c 21 -g 21
proxy 55937 0.0 0.1 704 300 ?? SNs 22Aug08 0:07.78 /usr/local/sbin/pftpx -f 192.168.10.34 -b 205.149.143.34 -c 21 -g 21
proxy 67517 0.0 0.1 704 316 ?? SNs 8Sep08 0:02.61 /usr/local/sbin/pftpx -f 192.168.10.100 -b 205.149.143.100 -c 21 -g 21
proxy 69571 0.0 0.1 704 276 ?? SNs 22Aug08 0:07.37 /usr/local/sbin/pftpx -f 192.168.10.246 -b 205.149.143.254 -c 21 -g 21
proxy 69985 0.0 0.1 704 332 ?? SNs Thu04PM 0:01.35 /usr/local/sbin/pftpx -f 192.168.10.180 -b 205.149.143.180 -c 21 -g 21
proxy 73719 0.0 0.1 704 280 ?? SNs 22Aug08 0:07.38 /usr/local/sbin/pftpx -f 192.168.160.2 -b 205.149.143.247 -c 21 -g 21
proxy 76078 0.0 0.1 704 304 ?? SNs 4Sep08 0:03.45 /usr/local/sbin/pftpx -f 192.168.10.145 -b 205.149.143.145 -c 21 -g 21
proxy 78705 0.0 0.1 704 308 ?? SNs 4Sep08 0:03.42 /usr/local/sbin/pftpx -f 192.168.10.146 -b 205.149.143.146 -c 21 -g 21
proxy 79097 0.0 0.1 712 288 ?? SNs 22Aug08 0:08.09 /usr/local/sbin/pftpx -f 192.168.10.101 -b 205.149.143.101 -c 21 -g 21
proxy 82832 0.0 0.1 704 308 ?? SNs 22Aug08 0:07.68 /usr/local/sbin/pftpx -f 192.168.10.110 -b 205.149.143.110 -c 21 -g 21
proxy 87836 0.0 0.1 704 324 ?? SNs 22Aug08 0:11.24 /usr/local/sbin/pftpx -f 192.168.10.144 -b 205.149.143.144 -c 21 -g 21The one that fails is
proxy 50753 0.0 0.1 704 340 ?? SNs Fri08AM 0:01.19 /usr/local/sbin/pftpx -f 192.168.150.230 -b 205.149.143.230 -c 21 -g 21##Resolutions##
My question is..
How can we see what it doesn't like? are any logs produced? Is there a way to reload the FTP helper from CMD line? Can we put it in debug mode and get any info on why it fails for this Nat?I have scoured the internet looking for documents that expand on this subject and have come up empty.
This is a production system for our datacenter so reboots are not done lightly thus any reloads need to be of a service and not the entire box unless there is just no other way.
Cubert
-
Also just a side note…
This was working at first deployment and then just stoped... So it was working at one time for this address.
-
I been able to troubleshoot this further and found an interesting "bug".
Here is the situation,
Have Nat'ed a dozen Carp VIP's from WAN to MULTIPLE LAN interfaces using port forward FTP rules. Pretty basic…
Here is some extra info about system setups, This is a HA clustered setup between 2 identical systems. No Loadbalacing or TC taking place.
Apon reboot only the last rule in the NAT table for FTP loads, if you hit "reload filters" no new ftp helpers are loaded but still the last FTP nat rule is loaded(pftpx). Now if you edit any ftp rule and save it(edit on the non parsed discription field) it will tell you to apply filter rules, during the monitoring of the filter rules you see it activate ftp helpers. Go check you ftphelpers (ps -aux |grep pftp) the last helper rule is there and the 2nd to last is now there... Repeat process and the 3rd from bottom now shows up... repaet untill all helpers are loaded.
I tested this 3 times to make sure it did it every time and what was required to get it to do it. It did...
Can anyone else confirm this?
Cubert
Version info pfSense1.2.0-Final
CARP Cluster (255 active VID)
5 Interfaces (1 WAN 3LAN 1 CARP)15+ FTP NATS using port forwarding
-
pfSense developers confirmed that the behavior I am seeing is a known bug in pfSense 1.2-release. The bug stems from the way that the ftp helper applications are started with CARP-type virtual IP addresses. This is fixed in pfSense 1.2.1
Cubert