NAT before IPSEC - reply packets stuck at enc0

[Andrey V. Elsukov]

On 26.07.2017 15:33, Muenz, Michael wrote:
>> Also, since your policies uses "unique" level, you need to specify the
>> same level using "unique:N" syntax.
>>
>> Also if it is interesting to you, I patched ipfw_nat to be able specify
>> needed direction. The patch is untested at all :)
>>     https://people.freebsd.org/~ae/nat_in_out.diff
>>
>> You need to rebuild ipfw(4) and ipfw_nat(4) kernel modules, and also
>> ipfw(8) binary.
>>
> 
> You are a genius! Many thanks for you patience with me! Now I have a
> running setup and it also works with unpatched OPNsense kernel:
> 
> kldload ipfw_nat
> ipfw nat 1 config ip 10.26.1.1 log
> ipfw add 179 nat 1 log all from 10.26.2.0/24 to 10.24.66.0/24 out xmit enc0
> ipfw add 179 nat 1 log all from 10.24.66.0/24 to 10.26.1.1 in recv enc0
> 
> setkey -PD | grep unique
> setkey -v -c
> 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/unique:X ;
> ^D
> 
> Thats all! I got it running, did a reboot and then it failed everytime
> until I saw the number after unique changes.
> 
> How is this number calculated? I need this for templating the script.

This number is chosen by strongswan. It would be better to know how to
configure it to specify both prefixes. You also can set 10.26.0.0/22
prefix somewhere in leftsubnet, and then filter 10.26.1.0/24 and
10.26.3.0/24 using firewall. I think then strongswan will generate
policy that will route all needed traffic into tunnel. And no manual
post-configuration will be needed.

-- 
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/20170726/0a5b8a66/attachment.sig>