Two Networks on one System

[Robert Bonomi]

> From owner-freebsd-questions at freebsd.org  Tue Jun 21 17:34:22 2011
> From: n j <nino80 at gmail.com>
> Date: Wed, 22 Jun 2011 00:02:53 +0200
> To: freebsd-questions at 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.