NAT before IPSEC - reply packets stuck at enc0

[Andrey V. Elsukov]

On 25.07.2017 10:36, Muenz, Michael wrote:
> Am 24.07.2017 um 19:01 schrieb Andrey V. Elsukov:
>>
>> .1.1: ICMP echo reply, id 33347, seq 28416, length 8
>> This does not match with what I expected to see. The reply here should
>> be something like "10.24.66.25 > 10.26.2.N: ICMP echo reply".
>>
>> It seems the problem is with ipfw_nat, that for both directions thinks
>> that packets are inbound and this leads to incorrect translation.
>>
>> Can you modify your IPsec security policies, so outgoing packets from
>> 10.26.2.0/24 will go through the same tunnel? Then you need to modify
>> nat rule:
>>
>> ipfw nat 1 config ip 10.26.1.1
>> ipfw add 179 nat 1 log ip from 10.26.2.0/24 to 10.24.66.0/24 out xmit
>> enc0
>> ipfw add 179 nat 1 log ip from 10.24.66.0/24 to 10.26.1.1 in recv enc0
>>
> 
> Hi,
> 
> when I change it to
> 
> out xmit enc0
> 
> nothing happens because the packets have to math the IPSEC SA before
> entering the tunnel (and enc0 I guess).
> So it has to be
> 
> in recv vtnet1

ICMP request should be matched by outbound IPsec policy. Looking to your
tcpdump, you use tunnel IPsec mode. So, how this should work:

* 10.26.2.N sends ICMP request to 10.24.66.25

* 10.26.1.1 handles it by tunnel mode IPsec security policy, something like:
	spdadd -4 10.26.2.0/24 10.24.66.0/24 any -P out ipsec \
	    esp/tunnel/213.244.192.191-81.24.74.3/require;
* IPsec code does lookup for IPsec SA and uses something like:
	add 213.244.192.191 81.24.74.3 esp 0x2478d746 -m tunnel -E ...;

* Then if_enc(4) pfil handler is called and now you need to do address
translation (with net.enc.out.ipsec_filter_mask=1), and in tcpdump you
should see not yet translated packet:
	10.26.2.N > 10.24.66.25: ICMP echo request ....

* Then IPsec code does IP encapsulation and you will see:
	213.244.192.191 > 81.24.74.3: IPIP ...
	    10.26.1.1 > 10.24.66.25: ICMP echo request

(in my previous patch was a bug, and you did not see outbound packet two
times in tcpdump, I attached new patch where it is fixed)

* Then IPsec sends encrypted packet to 81.24.74.3.

* The second host sends ICMP reply to 10.26.1.1.

* 213.244.192.191 recieves encrypted packet and does IPsec SA lookup, it
should have something like:
	add 81.24.74.3 213.244.192.191 esp 0xce702ac1 -m tunnel -E ...;

* IPsec code does decryption and if_enc(4) hook  is called, and you will
see in the tcpdump:
	81.24.74.3 > 213.244.192.191: IPIP ...
	    10.24.66.25 > 10.26.1.1: ICMP echo reply

* Since we use net.enc.out.ipsec_filter_mask=2, this packet will not be
handled by firewall and IPsec will do IP decapsultion, and then will
pass decapsulated packet to the pfil where it will be translated:
	10.24.66.25 > 10.26.2.N: ICMP echo reply ....

* Then this packet goes to ip_input() -> ip_forward() processing. To
avoid extra IPsec processing you should have no security policy that
matches "10.24.66.25 > 10.26.2.N" packet, or this should be policy that
requires "none" IPsec processing.

* Then ip_forward() sends this packet to 10.26.2.N.

-- 
WBR, Andrey V. Elsukov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: if_enc.diff
Type: text/x-patch
Size: 2357 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20170725/6d0d50ab/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20170725/6d0d50ab/attachment.sig>