Hi all I have been working with Shorewall connected to two ISPs lately, and I would like to suggest a couple of improvements to the MultiISP.html documentation page. I followed the examples in that page (but the legacy setup and the USE_DEFAULT_RT one), but I had problems with locally (by the firewall) generated packets: I wanted them to go out using only one ISP, but if I use a tcrules rule to accomplish this, I have all the packets that flow through the correct ISP connection, but 50% of them is given the wrong ip source address (the one from the other ISP NIC). What I found not to be so clearly stated in MultiISP.html is that when a packet is generated by the firewall and the application does not bind the socket to a particular source IP, then the source IP is determined by the kernel with a routing table lookup. At this time it is still unknown what mark will be associated to the packet by the rules in tcrules, so the source IP selection is not influenced by this. So if I have 2 ISP, declared balanced in the providers config file as the documentation suggests, I have half the packets given the source IP from the first ISP, and the other half from the other. Eventually the packet will be marked by tcrules, and only one outgoing ISP will be used. But the source IP has already been fixed, making 50% of packets going out with the wrong address. So if I use tcrules to cause all traffic to use one provider, I necessarily have to masq the firewall generated outgoing traffic when a packet goes out an ISP link, but has the other ISP source IP. I put in masq two rows like this: INTERFACE SOURCE ADDRESS $IF_ISP1 $ISP2_IP $ISP1_IP $IF_ISP2 $ISP1_IP $ISP2_IP
Exactly the same issue happens when you use tcrules to direct a particular application through either one of the ISP, and the solution is the same. This problem does not exist if you use rtrules instead of tcrules to direct traffic to one of the providers. This happens because an rtrules line directly causes a routing policy rule to be created. So when the kernel selects the source IP, the lookup "sees" this rule, and is done right. Obviously, however, rtrules is a lot less flexible than tcrules. So I would suggest to clearly state in the MultiISP page that if you use tcrules to direct locally generated traffic, then you must masq at least your outgoing connections, and explain why. This would go in the "Routing a Particular Application Through a Specific Interface" paragraph, and in the "USE_DEFAULT_RT" paragraph under the line "Although 'balance' is automatically assumed when USE_DEFAULT_RT=Yes, you can easily cause all traffic to use one provider except when you explicitly direct it to use the other provider via shorewall-rtrules (5) or shorewall-tcrules (5)." Another small detail: the document suggest to put in rtrules the line: - - shorewall 11999 But this gives " ERROR: You must specify either the source or destination in a rtrules entry". It's enough to substitute 0.0.0.0/0 for one of the dashes. Hope this saves some time to others. Luigi ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
