[Openswan Users] Openswan + IPTables SNAT both side traffic, is possible?

[Neal Murphy]

(This was supposed to go to the list, so I'm resending....)

On Wednesday 02 March 2011 10:08:06 Claudio Prono wrote:
> Hello all,
> 
> I use OpenSwan with a special IPTables SNAT rule because to the other
> side they have the same subnet IP addresses. So i have inserted a rule
> like this:
> 
> iptables -t nat -A POSTROUTING -s 10.10.0.4 -d 192.168.0.22 -j SNAT
> --to-source 11.10.0.4
> 
> With this rule the client present itself as 11.10.0.4 and all works
> without problems, when the client tryies to access the IP 192.168.0.22.
> But it doesn't work if is the 192.168.0.22 trying to contact the
> 11.10.0.4. I have tried some different rules, to do a reverse nat for
> the traffic from 192.168.0.2 to 11.10.0.4 natted to 10.10.0.4, but
> without any success. Any hint about it?

First, you shouldn't use public IP addresses in this manner, unless you 
control the 11.10.0.4 network. At the least, internet hosts with those 
addresses will become unreachable.

You have 1/4 of the rules needed. I'll assume you will use the correct 
private IP addresses of 10.254.0.0/24 for Left's SNAT LAN and 10.253.0.0/24 
for Right's SNAT LAN. I'll also assume that 10.10.0.0/24 is the LAN address 
that is on both sides.

In prose, each side needs clear, unique addressing to be able to contact the 
other side. You need to full-NAT (SNAT and DNAT) both sides; for this 
example, I've chosen 10.254.0.0/24 for Left's pseudoLAN and 10.253.0.0/24 for 
Right's pseudoLAN. That is, on Left, systems need to access hosts on Right 
using 10.253.0.0/24. On Right, systems need to access hosts on Left using 
10.254.0.0/24. You need to add the respective LAN addresses to each side's 
routing tables.

Then on each side, you must DNAT inbound traffic so the packet arrives at the 
expected node, and SNAT outbound traffic so that recipients of the packets 
have the correct address to send replies to. SNAT is performed after all 
routing is complete, just before the packet is queued for transmission. DNAT 
is performed before any routing is handled, just after the packet has been 
received by the router.

Consider the example of Left host 10.10.0.4 talking to Right host 10.10.0.4. 
Left-10.10.0.4 will use address 10.253.0.4 to contact Right-10.10.0.4. 
Right-10.10.0.4 will use address 10.254.0.4 to contact Left-10.10.0.4. That's 
all they need to know.

LAN Addresses:
  Left: 10.10.0.0/24 (10.254.0.0/24)
  Right: 10.10.0.0/24 (10.253.0.0/24)

On Left, you need to:
  - add a route to 10.253.0.0/24 via the VPN (to Right).
  - add a SNAT from 10.10.0.4 to 10.254.0.4 on outbound packets destined
    for 10.253.0.4. Right will now think the packet came from 10.254.0.4.
    This is done POST_ROUTING.
  - add a DNAT from 10.254.0.4 to 10.10.0.4 on inbound packets arriving
    from 10.253.0.4. The packet will now be routed to Left's 10.10.0.4.
    This is done PRE_ROUTING.

On Right, you need to:
  - add a route to 10.254.0.0/24 via the VPN (to Left).
  - add a SNAT from 10.10.0.4 to 10.253.0.4 on outbound packets destined
    for 10.254.0.4. Left will now think the packet came from 10.254.0.4.
    This is done POST_ROUTING.
  - add a DNAT from 10.253.0.4 to 10.10.0.4 on inbound packets arriving
    from 10.254.0.4. The packet will now be routed to Right's 10.10.0.4.
    This is done PRE_ROUTING.

This ain't no Texas Two-Step. It is a delicate and elegant minuet, requiring 
both sides to cooperate in unison to allow each side to access the other 
side's systems.

This is how it is done on normal routers. I don't know if any adjustments are 
needed for this to work with IPSEC. I don't know how one would write rules to 
allow complete LAN-to-LAN access; the above steps work well for host-to-host 
comms.

As I understand, this is just about the only way one can use the same LAN 
address on both sides of a routed link.

Lucian Gheorghe wrote this very lucidly in his book, "Linux Firewall and 
QoS".