Date: Wed, 26 Jul 2017 11:47:36 +0200 From: "Muenz, Michael" <m.muenz@spam-fetish.org> To: freebsd-net@freebsd.org Subject: Re: NAT before IPSEC - reply packets stuck at enc0 Message-ID: <3a7d5a5b-3b72-4cfe-2d8e-c832f7bfab5c@spam-fetish.org> In-Reply-To: <e870fe5e-431c-49b6-5960-123d0c7be0a9@yandex.ru> References: <459d59f7-2895-8aed-d547-be46a0fbb918@spam-fetish.org> <2d607e1a-a2c0-0f85-1530-c478962a76cd@spam-fetish.org> <3344e189-cdf0-a2c9-3a2a-645460866f2d@yandex.ru> <1279753e-9ad1-2c02-304e-5001e2bbc82f@spam-fetish.org> <15e6eb38-ef0c-7bfd-5f2c-d2acc8ea1af4@yandex.ru> <cdb7e172-4074-4559-1e91-90c8e9276134@spam-fetish.org> <63e80fcf-915e-2dd5-d8c9-1904c8261c6f@yandex.ru> <1c91cd8f-105d-e886-3126-67505c6c3900@spam-fetish.org> <c738380c-e0cc-2d32-934e-a05502887b93@yandex.ru> <1e889acf-49d1-b70f-7097-82e6e4dfabb6@spam-fetish.org> <454ed1b7-a80f-b096-cfa1-3c32d1e60f7d@yandex.ru> <f4c5a11c-a329-d746-ece8-e3752a6c82ea@spam-fetish.org> <5dfdfbb3-1046-5abe-b23a-b62c215b5d08@yandex.ru> <ada882bb-7344-49c5-0e47-e1432f27f1c9@spam-fetish.org> <860b48aa-b99e-7b71-3724-587ee0a7fe80@spam-fetish.org> <1b831b84-1d3f-38cb-acee-07a339315417@yandex.ru> <0bbf5bb9-8089-f9ce-3b1d-e9bcbdbc6c76@spam-fetish.org> <e870fe5e-431c-49b6-5960-123d0c7be0a9@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a7d5a5b-3b72-4cfe-2d8e-c832f7bfab5c>