Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a rather special routing and NAT issue which I hope I can fix somehow. Inside my company we run a supernet like 192.168.0.0/21 (192.168.0.1 - 192.168.7.254) All computers have this subnet mask, without the need to route in order to reach any of the other computers inside this segment.

To some customers we have set up some IPSec tunnels between their and our firewall. Additionally some customers only accept traffic via the tunnel for certain source IP's from within my private network. Like customer A only accepts traffic to his servers (we have to reach for e.g. RDP, SAPGUI etc.) if the source is between 192.168.1.1-192.168.1.10. Another one only accepts source 192.168.3.0/24 and so forth. So far I handle this by assigning an IP from the range in charge to that specific client PC. But now this is becoming quite cumbersome and also it changes within the same day. The user needs to connect to customer A at 9 am and to customer B at 11 am....

In order to be more flexible I thought of centralizing this by having some router inside my lan which I tell that traffic to customer A should go thorugh interface A which has an IP of the required range. But also NAT the traffic in order to hide the real client source IP.

This way I could set up some specific routes for certein destinations to go through this router. I would eliminate the need of always switching client source IP's according to the needs. But I fear that I cannot make this work since my routing would be from the same into the same network again. It's not from my lan to the cusotmer lan, this is done via IPSec later on my firewall, but I just have to hide the client IP like 192.169.2.1/21 claiming to be 192.168.1.2/21

Any ideas? I thought of Windows RRAS Server, but this is good to route from one segment into another one. But inside the same network by just switching IP's.

share|improve this question
    
Consider using something within the 172.16.0.0/12 block for your internal network. Most people forget it's part of RFC 1918, and thus it's much less commonly used. Also consider deploying IPv6 which will eventually make these issues go away entirely. –  Michael Hampton Feb 14 '13 at 20:07
add comment

2 Answers

SNAT / MASQUERADING is in POSTROUTING so by definition routing is not an issue then any more.

You can even change the routing table in one of your local systems so that it does not try to deliver packets for 192.168.0.0/21 locally over its link but sends them to the gateway:

ip route del 192.168.0.0/21

On the gateway you must allow forwarding within the LAN net, of course. But then you can use SNAT even locally. That's probably more fun than testing with the connection to the customer. :-)

share|improve this answer
add comment

I can't stress enough how bad of an idea it is to run a /21 internally IF you have enough hosts to warrant using a /21.

As in, for you to need a /21 (2000+ hosts) a /22 (1000+ hosts) wasn't good enough. If you are running a /21 with 10 hosts, then it doesn't matter.

If this is a server farm where the broadcast traffic is low and understood, then no problem.

But if (as it sounds) If you are running a /21 with 1049+ workstations in the same subnet you're going to have a bad time. Your broadcast traffic would be a spam ridden nightmare.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.