PFTPX fails to launch helper on Multiple VIP setup.
This was present in ver 1.2 and still is in 1.2.1-RC2 Build Nov 8th.
We had Centipede support look at this and they confirmed it as a known bug and said it was repaired in 1.2.1-RC.
Unfortunately we still seem to have the same problem, here is the scenario…
Dell PE 850 2GB RAM and 6 NICs
4 port Router Board 44
WAN = 1 static Internet IP and 245 VIP(Carp)
LAN - 1 static (Internal SUB-A) + 1 CARP failover IP
Carp -1 static (Internal Sub-B) + 1 CARP failover IP
LAN2 - 1 static (internal SUB -C) + 1 CARP failover IP
LAN3 - 1 static (internal SUB -D) + 1 CARP failover IP
LAN4 - 1 static (Internat SUB -E) + 1 CARP failover IP
WAN Nats all Internet IP's to LAN systems across all but CARP Interfaces. (aprox 40 systems)
After creating multiple NAT rules to allow FTP from different Internet IP's to separate backend systems across any LAN interface and upon a reboot of the firewall only one PFTPX helper service is running for each interface. There should be 1 service running for each VIP on the WAN interface that there is a FTP rule for.
We have found though testing that if after reboot you go and edit any FTP rule (Modify description) and save it forces a reload of the firewall and FTP helper application and adds the next ftp in the list. It does seem to have predictable loading. If you have 40 FTP NAT rules upon boot it loads rule #40, after editing any ftp rule and reloading firewall rule #39 will have been loaded.. and so on descending through the NAT FTP rules.
The problem with the work around is with 40+ FTP rules it takes one of my techs 1.5 hours to fully bring up the firewall services after a need for reboot.
#1 Is the Dev team aware of this issue?
#2 Is there a faster way for us to do a workaround until a fix can be put in place?
P.s Kudo's DEV team as this system rocks and we really appreciate all your hard work...
Please update your support ticket and we'll track it down. You are working with the development team with your commercial support through Centipede. There was a known issue in 1.2, but it was fixed and confirmed fixed in 1.2.1. If this is still a problem, there must be something different happening here and we'll need to work with you to resolve it.
The Devs are aware of your issue. Please work with Centipede as cmb requested.