Date: Tue, 25 Jul 2017 16:04:24 +0300 From: "Andrey V. Elsukov" <bu7cher@yandex.ru> To: "Muenz, Michael" <m.muenz@spam-fetish.org>, freebsd-net@freebsd.org Subject: Re: NAT before IPSEC - reply packets stuck at enc0 Message-ID: <1b831b84-1d3f-38cb-acee-07a339315417@yandex.ru> In-Reply-To: <860b48aa-b99e-7b71-3724-587ee0a7fe80@spam-fetish.org> References: <459d59f7-2895-8aed-d547-be46a0fbb918@spam-fetish.org> <a082662c-145e-0132-18ef-083adaa59c33@yandex.ru> <1c0de616-91ff-a6f9-d946-f098bc1a709f@spam-fetish.org> <911903d1-f353-d5d6-d400-d86150f88136@yandex.ru> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--jrsdn1IOse63sP203C3ehgDAiE8NG7MJO
Content-Type: multipart/mixed; boundary="4WKEsO2edLwn6NSwgNAxU0dXx95bGmUHx";
protected-headers="v1"
From: "Andrey V. Elsukov" <bu7cher@yandex.ru>
To: "Muenz, Michael" <m.muenz@spam-fetish.org>, freebsd-net@freebsd.org
Message-ID: <1b831b84-1d3f-38cb-acee-07a339315417@yandex.ru>
Subject: Re: NAT before IPSEC - reply packets stuck at enc0
References: <459d59f7-2895-8aed-d547-be46a0fbb918@spam-fetish.org>
<a082662c-145e-0132-18ef-083adaa59c33@yandex.ru>
<1c0de616-91ff-a6f9-d946-f098bc1a709f@spam-fetish.org>
<911903d1-f353-d5d6-d400-d86150f88136@yandex.ru>
<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>
In-Reply-To: <860b48aa-b99e-7b71-3724-587ee0a7fe80@spam-fetish.org>
--4WKEsO2edLwn6NSwgNAxU0dXx95bGmUHx
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
On 25.07.2017 15:17, Muenz, Michael wrote:
>>> * 10.26.2.N sends ICMP request to 10.24.66.25
>>>
>>> * 10.26.1.1 handles it by tunnel mode IPsec security policy,
>>> something like:
>>> 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;
>>> * IPsec code does lookup for IPsec SA and uses something like:
>>> add 213.244.192.191 81.24.74.3 esp 0x2478d746 -m tunnel -E ...;
>>
>> Thanks for the detailed explaination! I only know the insights with
>> Linux, but what I try to achieve is, not to build a SA fpr 10.26.2.0
>> to 10.24.66.0.
>> So IMHO the address rewriting from 10.26.2 to 10.26.1 should be done
>> before getting to the IPSEC process.
>> In Linux a packet not matching a SA would simply be dropped by kernel
>> or throw a "NO PROPOSAL CHOSEN" since there's no known SA for
>> 10.26.2.0 to 10.24.66.0.
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).
> 14:02:53.960436 (authentic,confidential): SPI 0xdeda7104: IP (tos 0x0,
> ttl 63, id 6287, offset 0, flags [none], proto ICMP (1), length 28, bad=
> cksum b07 (->c07)!)
> 10.26.1.1 > 10.24.66.25: ICMP echo request, id 38600, seq 0, length=
8
^^^ - this address must be 10.26.2.N, and it will be
translated on "out xmit enc0".
> 14:02:53.960460 (authentic,confidential): SPI 0xdeda7104: IP (tos 0x0,
> ttl 64, id 32607, offset 0, flags [none], proto IPIP (4), length 48, ba=
d
> cksum 0 (->c99b)!)
> 213.244.192.191 > 81.24.74.3: IP (tos 0x0, ttl 63, id 6287, offset
> 0, flags [none], proto ICMP (1), length 28)
> 10.26.1.1 > 10.24.66.25: ICMP echo request, id 38600, seq 0, length=
8
^^^ - and here it will become 10.26.1.1 after translation.
> 14:02:53.968634 (authentic,confidential): SPI 0xcdea472d: IP (tos 0x0,
> ttl 58, id 18352, offset 0, flags [none], proto IPIP (4), length 48)
> 81.24.74.3 > 213.244.192.191: IP (tos 0x0, ttl 63, id 38328, offset=
> 0, flags [none], proto ICMP (1), length 28)
> 10.24.66.25 > 10.26.1.1: ICMP echo reply, id 38600, seq 0, length 8=
^^^ - here your gateway receives the reply and
will do IP decapsulaton.
> 14:02:53.968653 (authentic,confidential): SPI 0xcdea472d: IP (tos 0x0,
> ttl 63, id 38328, offset 0, flags [none], proto ICMP (1), length 28)
> 10.26.1.1 > 10.26.1.1: ICMP echo reply, id 44919, seq 0, length 8
^^^ - here packet will be translated back on "in recv enc0" and
will have the following addresses: 10.24.66.25 > 10.26.2.N
>=20
> So the most specific nat rule in order to get the packet into enc0 is:
>=20
> ipfw nat 1 config ip 10.26.1.1 log reverse
> ipfw add 179 nat 1 log all from 10.26.2.0/24 to 10.24.66.0/24 in recv
> vtnet1
> ipfw add 179 nat 1 log all from 10.24.66.0/24 to 10.26.1.1 in recv enc0=
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
--=20
WBR, Andrey V. Elsukov
--4WKEsO2edLwn6NSwgNAxU0dXx95bGmUHx--
--jrsdn1IOse63sP203C3ehgDAiE8NG7MJO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAll3QdgACgkQAcXqBBDI
oXqjxgf/eoFhfgtmK5jLb2nzgqVQfiMlEvLqJlApS5OToB2h/vHPzFb30mkMi9Ts
fJ9K/0M+kcntnSmbNKhZrC1lJowaleV+n8cYHKkjsj5CaNBnieWPMg+p92V0YcUq
lsXeDH3kYExEW9dGE3/FMSl0cmAMa8nARQ8CpsVXp2Nl0jKoc8T5E8AvOeQEdW++
sNF8cwpIokbfNewrYrqQ3Csis2XzAnCEBL6HN7oT+Imajx9lVWdp09vhSlTdLjJl
3TBW/RSEqcCHnVqkqkune4jlTf22TuU8bHPVzuMsJAdpbTv+q4HkKaCqIia0aXYl
0ocA3ZX2wgltznN66A93wDpDeAmthg==
=LF5I
-----END PGP SIGNATURE-----
--jrsdn1IOse63sP203C3ehgDAiE8NG7MJO--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1b831b84-1d3f-38cb-acee-07a339315417>