Hello, On Thu, 21 Mar 2002, Thomas Vander Stichele wrote: > Then I started writing the firewall script. > I start by applying the iptables rules for statefulness (are these > necessary ? exactly what do they do). I removed the interface They are independent from the routing stuff. > configuration commands, since that is handled by redhat. > Then I remove the default route, and add the three tables which together > implement the load balancing. > > For outgoing connections, this mostly works : I can tell from traceroutes > that I get alternating outgoing gateways. > > Now for the problems I'm having : > > * before, when only using the ADSL as gateway, I could ssh to other boxes > on the internet without problems. With the new setup, when I ssh to one > of them (and the route goes over the second interface), the connection > hangs at the moment ssh starts up the X port forwarding. I suppose this Some users report for this problem with openssh where the TOS changes in established state cause using a different route (selected from the multipath scheduler). The new cached route differs in the TOS field and so to a new gw/outdev. In short, the problem is that the multipath scheduler when used for NAT is used for all packets, not only at connection setup. The details are explained in the docs. > is because (IIRC) ssh tries to set up a connection from that box to my > current machine, which somehow fails. If the route happens to go over the > first interface, everything is ok. > > * When trying to access the firewall from the outside, connections only > get established when coming in over the ADSL interface. When coming in > over the cable interface, the connection hangs, indicating the route back > is failing. This seems to me like another symptom of the same problem as > the other. May be, to summarize, the rule is: "the plain kernel _only seems_ to work correctly for setups with NAT and multipath routes". > So here is a set of questions ;) You knew this was coming ... > > a) nano.txt only mentions outgoing connections. Does this document apply > to incoming connections as well or not ? Should it work as outlined there, Yes, the routing is considered symmetric. > should I infer different iptables and ip rules to handle incoming traffic, > or does it work in another way entirely ? No, it will work only by using the routing rules. > b) Since I don't have a default gateway and the gateway alternation works > on outgoing routes, I suppose that my gateway setup is correct. So the > fact that it cannot make incoming connections over eth2 is not due to eth1 > being the default gateway as was the case before. > But what else could cause this behaviour ? Is it possible I might have my > SNAT/MASQUERADE set up wrong to get this effect ? > > c) do I need to apply julian's patches in order for this basic setup > (incoming traffic on both interfaces) to work ? It is my understanding You should apply the patches if you expect the router correctly to NAT the packets when using multipath route. I hope the ssh problem will disappear because there the multipath scheduler selects new route only for the first packet in each connection, the established connections are considered bound to the masquerade address for which usually we don't have multipath route. > from browsing through the archive that, for this basic functionality, it's > not necessary. I will of course apply these patches later on to have > gateway failure detection, but my question is if applying these patches > now or not will have any effect on my current setup. I hope there will be effect > Here is a list of output of various commands : look good > (I have to note here that using redhat's network configuration initialized > the 192.168.254.0/24 to be "scope link" only, so no proto kernel and no > src addresss. I thought that this might have been wrong so I changed it > manually but it had no effect as far as I could tell) In any case make sure the preferred source IP is valid or autoselected to be such. The routing rules look good, I didn't checked the iptables > I hope this is enough information to help me debug the situation. Any > help is MUCH appreciated. > > Thanks in advance, > Thomas Regards -- Julian Anastasov <ja@ssi.bg>
