Am 25.07.2017 um 17:38 schrieb 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.
When I type setkey -PD I get:
10.24.66.0/24[any] 10.26.1.0/24[any] any
in ipsec
esp/tunnel/81.24.74.3-213.244.192.191/unique:2
created: Jul 26 11:03:53 2017 lastused: Jul 26 11:40:02 2017
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=5 seq=1 pid=4292
refcnt=1
10.26.1.0/24[any] 10.24.66.0/24[any] any
out ipsec
esp/tunnel/213.244.192.191-81.24.74.3/unique:2
created: Jul 26 11:03:53 2017 lastused: Jul 26 11:40:02 2017
lifetime: 9223372036854775807(s) validtime: 0(s)
spid=6 seq=0 pid=4292
refcnt=1
So it's in use.
But when I type in your command it just "hangs". Not the system, but the
command doesn't get completed.
root@PB-FW1-FRA:~ # 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/require ;
<waiting cursor>
dmesg and syslog is clean, no error. Also adding the -v for verbose
doesn't output anything.
Will have to investigate on this.
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.
Ok, then it's clear why it doesn't work. Thanks for you efforts!
Will debug with the OPNsense dev's to catch this one ..
Michael
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
