# IPSEC transport mode + NAT, theory explain needed

## salam

Hello,

I'm trying to setup IPSEC and need some explanation why this situation does not work:

HOST ---> ROUTER[NAT] ===== IPSEC ESP ====== SERVER

Let's say it is DNS, so UDP/53

From what I understand, IPSEC takes place AFTER the packet is NATed(as shown here https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg), so there should be no modification done to mess up already secured packet.

So DNS request should be something like:

192.168.0.2:43000 -> 8.8.8.8:53

Packet arrives at router, then source is changed by NAT to something like 20.20.20.20:[port], then it is encrypted and sent.

ESP arrives at server, where it is decrypted, served and reply is sent.

Encrypted reply arrives, is decrypted, so router should see 8.8.8.8:53 -> 20.20.20.20:[port], where NAT tracking should recognize it, change destination to 192.168.0.2:43000 and send to final host.

That it doesn't work I already know. But I'd like to know what's behind it.

Only thing that I think of is that after IPSEC encrypts the packet, it is sent back to IP stack and processed again. But same happens with router's locally generated packet where it works OK.

----------

## NeddySeagoon

salam,

Does this page help?

----------

## Hu

What do you see that leads you to say it does not work?  What is the first step that behaves incorrectly?

----------

## NeddySeagoon

salam,

DNS may be a special case. There are two networks here.

There is the physical network keeping your network connection alive. You need to keep DNS for that outside of the IPSEC tunnel.

There is the logical network that flows over your physical network. Only DNS for whatever is on the logical network must flow over IPSEC.

----------

## salam

I checked the link, I'm aware about NAT-T existence, what I cannot understand is technical background of given situation, this part of the text is what interests me:

 *Quote:*   

> Also in some cases depending on the level of encryption, the payload and in particular the headers are encrypted when using IPSec ESP mode. The NAT device can not change these encrypted headers to its own addresses, or do anything with them.
> 
> The NAT device in the middle breaks the authenticity, integrity and in some cases can not do anything at all with the packet.

 

OK, but still, NAT takes place before ESP, so nothing in packet is changed after (here, NAT is not "in the middle" as it is done by same device as is ipsec endpoint).

I have active policy with "source: any ==> target:my_server, UDP/53 (+opposite way on server side)"

Of course, directly from endpoint, all works OK, from a host behind this endpoint, it does not. And I cannot figure out what happens with that dropped packet. 

According to the packet flow diagram

1) Client behind NAT sends DNS request to my_server, UDP/53

2) Packet arrives at router, which is configured to do both NAT and IPSEC

3) There is no bridging, so packet will travel following the "green" part of the diagram until it hits "NAT postrouting", where NAT takes place

4) At "xfrm lookup", policy is matched, packet is encoded and sent back over output chains. Note that after NAT, source address is changed to public IP of the router, so now it should be same situation as if the packet was locally generated (xfrm lookup is done with source IP of router, be it local packet, or one after NAT)

5) Since no more packet processing rules match this encoded packet, it is sent out from the interface.

6) Tcpdump at DNS server shows no incoming communication, packet did not leave the router.

And I cannot figure out, where is that difference since IPSEC should not interact with previous NAT at all.

Also, it doesn't depend on protocol used, i can make a policy even for ICMP and it behaves exactly same.

----------

