Two Networks on one System

[Damien Fleuriot]

On 6/21/11 1:28 PM, Martin McCormick wrote:
> 	Here is what the issue is right now. The remote campus
> in question has been on number space that was part of our Class
> B network. They got a block of subnets for their DNS's and
> campus enterprises and work stations. We secured them their own
> number space and they are migrating from their portion of our
> network to their new network and both nets are presented
> routable from the rest of the world.
> 
> 	If you do a whois query for their domain, you get the
> address on our network of their primary DNS. When one updates
> the whois data, there is a lag of some hours until new queries
> start going to the new address of their primary DNS. In the mean
> time, we don't really care but we would like for the new
> interface for the primary to be reachable so that the minute the
> information changes, we're answering lookups. After that point,
> we will permanently take down the old interface address on our
> network and probably reboot with the normal configuration now
> being the new IP address.
> 
> 	The problem I have, probably due to a misunderstanding
> of what I need to do, is easy to describe.
> 
> 	The defaultrouter statement in rc.conf or
> 
> route add default x.x.x.x
> 
> from the command line sets an interface to know that packets
> whose destinations or sources that are outside the subnet go to
> that default gateway.
> 
> 	When I set up the secondary interface, I have not been
> able to come up with a statement or statements that tell fxp1
> that it's default router is y.y.y.y so you can't ever reach it
> from outside the new subnet.
> 
> 	Once traffic ever gets in to the system, it will
> probably stay together based on the interface where it came
> from, but it won't have to do it for hopefully more than a few
> hours.
> 
> 	I have tried both a second physical connection and an
> alias and have ended up with the same behavior each time. Since
> we have the second NIC active, I prefer to use it if I can ever
> get it to use its router just like the primary interface does.
> 
> 	Right now, I can get on to our secondary DNS which is in
> the same subnet as the new address for the primary and log right
> in to the primary through the new interface. From anywhere else
> on the Earth, that new address is as dead as a doornail.
> 
> 	I certainly appreciate every posting so far as routing
> is one of the thorniest issues one can encounter in networking
> so the more one is aware of, the less head-scratching and
> frustration there is.
> 
> Martin McCormick
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"




Let's summarize it like so:


Your client has a DNS serveur called "dns1".

This server has an IP from your subnet, from example 100.100.100.53 in
100.100.100.0/24

Your client has gotten 200.200.200.0/24 from the RIPE NCC and wants to
migrate to their new IP range.

Your client wants and needs to maintain their 100.100.100.0/24 addresses
for some time.



First, on dns1, you'll configure an interface with both public IPs,
either on a vlan interface or on a physical interface:


CURRENT:
ifconfig em0 inet 100.100.100.53/24
route add default 100.100.100.1


PLANNED:
ifconfig em0 inet 200.200.200.53/24 alias

This command adds the "200.200.200.53" IP on your em0 interface but
doesn't remove the previous one.

Your now have em0 with 2 public IPs, one in each range.



PROBLEM:
However, if you try to ping 200.200.200.53, say from host 50.50.50.50,
the server dns1 tries to reach you back with its default route at
100.100.100.1.

Stateful filtering or simple antispoof rules prevent that.



SOLUTION:
You need a way to reply using a specific route depending on which IP was
requested by the internet user at 50.50.50.50

If they queried 100.100.100.53, you need to route through 100.100.100.1.
If they queried 200.200.200.53, you need to route through 200.200.200.1.


TECHNICAL IMPLEMENTATION:
pf provides the tools for what you'd like to do, through the "reply-to"
option in access rules.

Find below an example:

# VARIABLES DEFS
pub_if="em0" # Our network interface with the public IPs bound to it
pub_100="100.100.100.53" # Our own IP in the 100.100.100.0/24 range
gw_100="100.100.100.1" # Our ISP's router in the 100.100.100.0/24 range
pub_200="200.200.200.53" # Our own IP in the 200.200.200.0/24 range
gw_200="200.200.200.53" # Our ISP's router in the 200.200.200.0/24 range


# ACCESS RULES
pass in log on $pub_if reply-to ($pub_if $gw_100) inet proto {tcp,udp}
from any to $pub_100
pass in log on $pub_if reply-to ($pub_if $gw_200) inet proto {tcp,udp}
from any to $pub_200



That is all you need.

Automatically, PF will use the router 100.100.100.1 for packets that
were destined to IP 100.100.100.53 on server dns1 , and 200.200.200.1
for packets destined to 200.200.200.53

This solution provides the symmetric routing you're looking for and is
proven, we use it in production just fine here.