Hi, thanks for your quick response ;) > > 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. Ok, just out of curiosity, should I reread the docs to find out what they do help for ? It was not really clear to me on the first couple of reads. > > * 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. OK, I'll read them again. But basically you're saying it's NOT because the X port forwarding opens up a second connection ? Am I wrong in my assumption about how ssh X port forwarding works, or is this not an issue here ? > > * 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 you're saying it looks like it works right, but it doesn't ? Hm, ok. So are the times when it doesn't work totally random, or is there some logic in it ? > 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. Meanwhile, I recompiled my kernel with the patches and at first glance I get the same behaviour. I will look into it some more tomorrow when I'm back at work. What I wanted to ask re: masquerading is, if I add an iptables rule to do masquerading without specifying a device, is that ok ? or should I have one for each device specifically ? The nano doc says that for fixed IP addresses you need an SNAT rule, while for PPPoE devices you need MASQUERADE. Which should I be using for a DHCP device ? > > 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 On first inspection, no. Is there some way I can debug incoming packets ? What else can I give as feedback ? Thanks again for your help, it is much appreciated. Thomas -- The Dave/Dina Project : future TV today ! - http://davedina.apestaart.org/ <-*- -*-> I'm alive. I can tell because of the pain. <-*- thomas@apestaart.org -*-> URGent, the best radio on the Internet - 24/7 ! - http://urgent.rug.ac.be/
