Quantcast
Channel: linuxadmin: Expanding Linux SysAdmin knowledge
Viewing all articles
Browse latest Browse all 17763

iptables NAT table not translating inbound packets to local address (bidirectional NAT through IPsec)

$
0
0

Hello everybody.

So Mr Network Guy over here's trying to do what he does with CentOS acting as a NAT gateway and VPN concentrator

10.1.1.1 in site 6 needs to talk to 10.1.1.1 in site 7 (identical subnets) through an IPsec tunnel (StrongSwan, if it matters)

NAT table on the VPC concentrators looks like so. Recall they're pretty much mirror images;

Site 6 iptables -t nat -A POSTROUTING -s 10.6.1.1 -o eth1 -j SNAT --to-source 10.1.1.1

Site 7 iptables -t nat -A POSTROUTING -s 10.7.1.1 -o eth1 -j SNAT --to-source 10.0.1.1

IPsec isn't the issue here since the packets get NATed and make it through the tunnel fine. The thing is when they get to the remote concentrator, the NAT rule at that end doesn't translate them back to the local address. Eg when I invoke this from the 10.0.1.1 host in site 6..

ping 10.7.1.1 -c 1

.. that frame makes it through the tunnel and shows up at site 7 concentrator as;

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 18:34:21.615830 IP 10.6.1.1 > 10.7.1.1: ICMP echo request, id 41587, seq 5890, length 64 18:34:21.615871 IP 10.6.1.1 > 10.7.1.1: ICMP echo request, id 41587, seq 5890, length 64

When I look at the MACs the 1st frame is incoming through the tunnel. The second is outgoing on the same interface (yeah I hairpinned just to confuse everyone) to the site 7 concentrator's default gateway untranslated. Filtering for ICMP, I'd have expected to see;

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes 18:34:21.615830 IP 10.6.1.1 > 10.7.1.1: ICMP echo request, id 41587, seq 5890, length 64 18:34:21.615871 IP 10.6.1.1 > 10.1.1.1: ICMP echo request, id 41587, seq 5890, length 64

.. i.e the frame destination gets translated and forwarded to the local 10.1.1.1 endpoint.

This happens both ways. Packet gets NATed locally, goes through the tunnel, then sidesteps the mirror image NAT rule at the remote end and tries to get forwarded as is.

Stuff I've tried ) I thought that applying the NAT entries on the tunnel interface at each end would be the solution, only I don't see any tunnel interfaces in 'ip address show' or 'ifconfig' so I just made it global. This was even worse. Frames from 6 6 get bounced to the site 6 gateway and don't even make it to site 7. ) Mirror image rules on each end that translate 10.36.1.1/10.37.1.1 frames from the tunnel back to 10.1.1.1 ) Confirmed no other rules in play in iptables. ) Confirmed net.ipv4.conf.eth1.forwarding = 1 on both sides (has to be, because frames make it through the tunnel)

Does anyone have an idea where to go next with this?

submitted by simpleharmonicmotion
[link][4 comments]

Viewing all articles
Browse latest Browse all 17763

Trending Articles