3

I have a dilemma; I have a customer with an application server running on CentOS 5 (latest). The app server is configured with 2 interfaces:

eth0 - connect to the client network with subnet 192.168.3.0/24
eth1 - connects to local subnet which hosts all the devices the application manages with subnet 192.168.1.0/24

The problem is that the client has a remote office which has a subnet that overlaps with the app server internal network (namely 192.168.1.0/24) and would like the users in that subnet to have access to the app server. Here's some ascii art to help get the topology across:

|--------------------------------------------|                |---------------------------------------------------|
|    Application Server Internal Network     |                |            Internal Client Network                |
|                                            |                |                                 Remote Network    |
|                       ----------------     |                |    ---------------            ------------------  |
|                       |              |     | 192.168.3.0/24 |    |    Client    |           |                |  |
|  192.168.1.0/24 <>--<>   App Server   <>------<>      <>-------<>   Controlled  |           | 192.168.1.0/24 |  |
|                   eth1|              |eth0 |                |  .1| Cisco Router |           |                |  |
|                     .1----------------.10  |                |    ----------------           ------------------  |
|--------------------------------------------|                |---------------------------------------------------|

I'm trying to resolve the issue by calling upon the Linux router capabilities (iptables targets DNAT, SNAT, NETMAP, ROUTE, etc.), but I'm stumped. The client is attempting to access 192.168.3.10 to access the web app but the packets never get back as the app server see the connection attempt as being from a locally connected device and proceeds to arp for the MAC address. I've setup a test environment in our lab and this is what tcpdump reveals when I attempt a ping from the client PC:

tcpdump -n -l -i eth0 net 192.168.1.0/24
15:50:40.006196 IP 192.168.1.48.10689 > 192.168.3.10.10690: S 1413694241:1413694241(0) win - <mss 1460,nop,nop,timestamp 1413694241 0,nop,wscale 1>
15:50:41.002813 IP 192.168.1.48.10689 > 192.168.3.10.10690: S 1413694241:1413694241(0) win - <mss 1460,nop,nop,timestamp 1413694242 0,nop,wscale 1>

tcpdump -n -l -i eth1 net 192.168.1.0/24
15:50:40.008269 arp who-has 192.168.1.48 tell 192.168.3.10
15:50:41.003657 arp who-has 192.168.1.48 tell 192.168.3.10

I've requested the client to implement NAT on their Cisco router and they have started the change approval process. However, their network change requests take over 3 weeks to get approved so they were hoping that this issue can be resolved on the Linux end sooner; the app server is not under their change approval process being that it is an isolated network and under our direct control! The only thing we cannot do is change the IP address on the app server eth0 interface!

Cheers, ak.

3
  • 4
    NAT is an ugly solution. A company should make planned use of IP space and not assign overlapping subnets in their locations. Rather than employ NAT, they should fix their network by renumbering one or both locations. Not doing so may result in other problems in the future. As for this question, you may be a better/faster response on Server Fault or Unix & Linux as this has more to do with configuring a server than a network.
    – YLearn
    Oct 19 '14 at 14:46
  • I had contemplated posting on the Linux forum but then after doing some searches, it appeared to me that this was a networking issue hence I posted here. As for the NAT issue, the client knew that they already had a network that was overlapping, but they reckoned it was not in scope then! C'est la vie.
    – AnthonyK
    Oct 19 '14 at 20:49
  • @AnthonyK you are correct, this is fully a network engineering question, but the truth is that you will get better network engineering answers on unix.stackexchange.com .
    – dan
    Aug 19 '20 at 15:03
5

I was able to find a kludge to my dilemma. Since all traffic coming to the app server from the overlapping subnet is heading to port 80 (and no host on the local overlapping subnet talks to port 80 - apologies for overlooking that part in my question above), all I need to do is mark the packets heading out of port 80 using iptables, create a new routing table for the remote overlapping subnet, add routing information for the new routing table, and finally implement policy routing for the marked packets.

Below are the commands I used:

iptables -t mangle -A OUTPUT -p tcp --sport 80 -d 192.168.1.0/24 -j MARK --set-mark 30
echo "200 overlap" >> /etc/iproute2/rt_tables
ip route add 192.168.1.0/24 via 192.168.3.1 table overlap
ip rule add fwmark 30 lookup overlap

This resolved the issue and was quite an eye opener to what the Linux router can really accomplish!

Cheers, ak.

2
  • Policy routing, no matter what the platform, can be impressive. Just don't forget to remove it when no longer needed or troubleshooting will be fun.
    – cpt_fink
    Oct 21 '14 at 3:15
  • That's quite true. My first encounter with policy routing was on a Cisco router; now I realize that Linux is just as good - probably even more flexible!
    – AnthonyK
    Oct 21 '14 at 12:10
2

Tested on one Archlinux i686 with namespace within VirtualBox:

iptables 1.6.1-1
iproute2 4.11.0-1
linux 4.10.13-1

Perform following on your App server, assuming your client IP from the right is 192.168.1.100.

if your app server is at 192.168.1.1:

ip ro add 192.168.1.100/32 via 192.168.3.1
iptables -t nat -A PREROUTING  -i eth0 -s 192.168.1.100/32 -d 192.168.3.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.1

if a standalone server 192.168.1.48 is sitting on the same network as eth1:

sysctl net.ipv4.ip_forward=1
ip ro add 192.168.1.100/32 via 192.168.3.1
iptables -t nat -A PREROUTING  -i eth0 -s 192.168.1.100/32 -d 192.168.3.10 -p tcp --dport 80 -j DNAT --to-destination 192.168.1.48
iptables -t nat -A POSTROUTING -o eth1 -s 192.168.1.100/32 -d 192.168.1.48 -p tcp --dport 80 -j SNAT --to-source 192.168.1.1

Tune IP/range/PAT as you see fit.

Nice ASCII btw.

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