Date: Tue, 21 Jun 2011 18:34:47 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org, nino80@gmail.com Subject: Re: Two Networks on one System Message-ID: <201106212334.p5LNYloa051794@mail.r-bonomi.com> In-Reply-To: <BANLkTikXYxXCeRX1NY-Z179vx_SDkiJK=w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Tue Jun 21 17:34:22 2011
> From: n j <nino80@gmail.com>
> Date: Wed, 22 Jun 2011 00:02:53 +0200
> To: freebsd-questions@freebsd.org
> Subject: Re: Two Networks on one System
>
> I can't really say I understand the exact problem the OP has,
As _I_ understand it, one of two things are going on:
a) he has servers LIVING BEHIND _NAT_ in one address-space, and directly
addressable in a 2nd address-space. Thus if packets come 'in' on one
interface, and go 'out' on the other interface, they hit the external
Internet with a _different_ 'source address' than the _external_
'destination address' on the packets that they are a 'reply' to.
b) the severs have addresses on two separate publicly-addressable networks,
the only routing information those machines have is 1) a route for
each directly connected network, and 2) a single 'default' route.
Thus all 'reply' packets for connections from a _non-directly-conntected_
network go 'out' the default route, _regardless_ of which network
they came in on.
This is classical 'asymmetric' routing, and *should* "just work",
*UNLESS* there are 'anti-spoofing' filters "somewhere" along the
'default' route. Filters that *DO*NOT*KNOW* that they _should_
pass packets with 'source addresses' of that 2nd network.
Issue a) is resolvable *ONLY* with 'policy based routing' within the server,
based on outgoing packet _source_addreess_
Issue b) is resolvable _either_ by policy based routing, as above, *OR* by
finding -where- along the 'default' path the anti-spoofing rules are, and
updating them to allow passage of the 'asymmetric' packets.
Applying the appropriate policy based routing _is_ fairly simple, using 'pf',
per the rules that others have provided.
*IF* 'situation b)', above, applies, the overhead of 'pf' can be eliminated
by updating the anti-spoofing rules in the default outbound path. Of course,
this solution requires the co-operation of the admins at the point along the
default route where those anti-spoofing rules are being applied. It is _not_
clear whether or not the OP is part of that group.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106212334.p5LNYloa051794>