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
signature.asc
Description: OpenPGP digital signature
