NAT before IPSEC - reply packets stuck at enc0

[Andrey V. Elsukov]

On 25.07.2017 17:06, Muenz, Michael wrote:
>> 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).
> 
> Can I use this spdadd command also when using strongswan? (Please excuse
> stupid questions)

I'm not familiar with strongswan configuration, but you can just try and
check that the proposed configuration will work.

>> 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
>>
> 
> Ok so your 3 nat commands will only match when there's a new spd like
> above right?
> Since there's nothing on enc0 without it.

Yes, it is. A security policy will route requests from 10.26.2.0/24 into
IPsec tunnel, where they should be translated, and then replies will be
received.

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