Tuesday, July 8, 2008

Stupid Routing Tricks

As you might have read, I'm just about done building the new equipment stack that is going to go into the new co-location. I'm at the stage where I'm trying to finalize all the equipment settings. This includes pesky things like setting up the external firewall cluster with the right IP configuration.

There is the small difficulty that my external devices have a public IP block that isn't routed to my office. Effectively, this means that I've got to do bizarre, black magic to get my internal equipment to recognize the a.b.c.0/27 network our new colo provided us. I've done it, and I feel dirty. Here's a diagram of essentially what I've got now:

The networking-oriented among you will probably see the issue immediately. With the strategic use of static routes, I can get our internal machines to see the external interfaces of the colo netscreens, and once that happens, I can setup the VPN tunnel between the two. However, at this point, there's no way short of NAT to get the colo machines access to the internet. As soon as traffic leaves my 2611, the source IP gets seen as the colo-provider's IP, and routed far, far away.

I can use NAT, but then I'll have to change the config on my 5GTs, which I'm hoping to avoid. Today I may try some static route trickery to have the colo machines temporarily route everything through the VPN tunnel and let the 5GT's take care of traffic. That may work.

Anyway, if I come up with an interesting solution, I'll be sure to let you know!