From: Julian Anastasov <ja@ssi.bg>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Question re: multi-homed access
Date: Thu, 21 Mar 2002 21:35:37 +0000 [thread overview]
Message-ID: <marc-lartc-101674653703309@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101673309716255@msgid-missing>
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>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
next prev parent reply other threads:[~2002-03-21 21:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-21 17:50 [LARTC] Question re: multi-homed access Thomas Vander Stichele
2002-03-21 21:35 ` Julian Anastasov [this message]
2002-03-21 23:02 ` Thomas Vander Stichele
2002-03-21 23:55 ` Julian Anastasov
2002-03-22 9:58 ` Thomas Vander Stichele
2002-03-22 10:34 ` Julian Anastasov
2002-03-22 17:15 ` Thomas Vander Stichele
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-101674653703309@msgid-missing \
--to=ja@ssi.bg \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.