NAT before IPSEC - reply packets stuck at enc0

[Andrey V. Elsukov]

On 25.07.2017 15:17, Muenz, Michael wrote:
>>> * 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 ...;
>>
>> Thanks for the detailed explaination! I only know the insights with
>> Linux, but what I try to achieve is, not to build a SA fpr 10.26.2.0
>> to 10.24.66.0.
>> So IMHO the address rewriting from 10.26.2 to 10.26.1 should be done
>> before getting to the IPSEC process.
>> In Linux a packet not matching a SA would simply be dropped by kernel
>> or throw a "NO PROPOSAL CHOSEN" since there's no known SA for
>> 10.26.2.0 to 10.24.66.0.

As I said already, the NAT thinks that both packets are inbound and does
translation for source address each time. You need to do translation for
both directions on enc0 interface like I described, or you need to
somehow hack/modify ipfw_nat.

You do not need to create SA for 10.26.2.0->10.24.66.0, you only need
create security policy, that will "route" such packets into the IPsec
tunnel. The translation will be done inside IPsec before IP
encapsulation and encryption. Since you are using tunnel mode IPsec,
replies will be returned to your external IP address, and this SA is
exists already. After decryption and IP decapsulation the destination
address of packet will be translated back to 10.26.2.N on if_enc(4).

> 14:02:53.960436 (authentic,confidential): SPI 0xdeda7104: IP (tos 0x0,
> ttl 63, id 6287, offset 0, flags [none], proto ICMP (1), length 28, bad
> cksum b07 (->c07)!)
>     10.26.1.1 > 10.24.66.25: ICMP echo request, id 38600, seq 0, length 8
            ^^^ - this address must be 10.26.2.N, and it will be
translated on "out xmit enc0".

> 14:02:53.960460 (authentic,confidential): SPI 0xdeda7104: IP (tos 0x0,
> ttl 64, id 32607, offset 0, flags [none], proto IPIP (4), length 48, bad
> cksum 0 (->c99b)!)
>     213.244.192.191 > 81.24.74.3: IP (tos 0x0, ttl 63, id 6287, offset
> 0, flags [none], proto ICMP (1), length 28)
>     10.26.1.1 > 10.24.66.25: ICMP echo request, id 38600, seq 0, length 8
            ^^^ - and here it will become 10.26.1.1 after translation.

> 14:02:53.968634 (authentic,confidential): SPI 0xcdea472d: IP (tos 0x0,
> ttl 58, id 18352, offset 0, flags [none], proto IPIP (4), length 48)
>     81.24.74.3 > 213.244.192.191: IP (tos 0x0, ttl 63, id 38328, offset
> 0, flags [none], proto ICMP (1), length 28)
>     10.24.66.25 > 10.26.1.1: ICMP echo reply, id 38600, seq 0, length 8
                         ^^^ - here your gateway receives the reply and
will do IP decapsulaton.

> 14:02:53.968653 (authentic,confidential): SPI 0xcdea472d: IP (tos 0x0,
> ttl 63, id 38328, offset 0, flags [none], proto ICMP (1), length 28)
>     10.26.1.1 > 10.26.1.1: ICMP echo reply, id 44919, seq 0, length 8
      ^^^ - here packet will be translated back on "in recv enc0" and
will have the following addresses: 10.24.66.25 > 10.26.2.N

> 
> So the most specific nat rule in order to get the packet into enc0 is:
> 
> ipfw nat 1 config ip 10.26.1.1 log reverse
> ipfw add 179 nat 1 log all from 10.26.2.0/24 to 10.24.66.0/24 in recv
> vtnet1
> ipfw add 179 nat 1 log all from 10.24.66.0/24 to 10.26.1.1 in recv enc0

ipfw nat 1 config ip 10.26.1.1 log
ipfw add 179 nat 1 all from 10.26.2.0/24 to 10.24.66.0/24 out xmit enc0
ipfw add 179 nat 1 all from 10.24.66.0/24 to 10.26.1.1 in recv enc0

-- 
WBR, Andrey V. Elsukov

-------------- 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/ac29d412/attachment.sig>