On Wed, Oct 10, 2012 at 6:32 AM, Steve Clark sclark@netwolves.com wrote:
I was trying to figure out what criteria to use to mark the connection. FTP is such a braindead application, using to channels and active and passive mode. What really needs to happen is someway to tell the kernel to recheck the routing after SNAT.
I'm mostly sure that if you mark the *connection* to the FTP server, the related data will follow its path.
Again, multipath routing is complex, and Shorewall will do it properly. At the very least, I recommend building a working configuration with Shorewall and then reading the rules that it compiles to understand why it handles routing the way that it does.
Steve, what you need is to send packages of particular stream via particular ISP in situation where stupid load balancing will brake a connection, send it via different ISP and thus change the clients IP.
Shorewall and it's Multi-ISP config is only thing you need for this to work.
Hi Ljubomir,
Thanks for the response. We have 450 units in the field and have only needed to do this at one site. I am using a userspace script to monitor the viability of each isp and changing the routing accordingly as described in the LARTC document. Our units in the field use CentOS so we don't want to use a custom kernel outside of what CentOS provides. That's why I am reluctant to use the patches at
If you have a squid parked somewhere with working internet routing, a quick-fix would be to export ftp_proxy=http://squid_ip:port before running yum (or whatever is using ftp). You can even port-forward this over an ssh connection if your squid proxy can't be reached directly.