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 21

    The 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


Locked