From owner-freebsd-net@freebsd.org Tue Jul 25 13:07:10 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89BD7C7BE08 for ; Tue, 25 Jul 2017 13:07:10 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward3m.cmail.yandex.net (forward3m.cmail.yandex.net [5.255.216.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 241DF7657E for ; Tue, 25 Jul 2017 13:07:09 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from smtp2j.mail.yandex.net (smtp2j.mail.yandex.net [IPv6:2a02:6b8:0:801::ac]) by forward3m.cmail.yandex.net (Yandex) with ESMTP id CF0DE210A9; Tue, 25 Jul 2017 16:07:05 +0300 (MSK) Received: from smtp2j.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2j.mail.yandex.net (Yandex) with ESMTP id 38A0F3EC1176; Tue, 25 Jul 2017 16:06:59 +0300 (MSK) Received: by smtp2j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 3j40SKlXyB-6wYGrWw1; Tue, 25 Jul 2017 16:06:58 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1500988018; bh=rvtrYksE4esL8S1P72M9zakp3Y8dq6J/oG62q8NHowI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=s/fnxPw+Dn6IgiGpiTBwFRehF6sJBLqLUXhvUzIIH1hl7WXaCFzY1FejClm228SqQ nAJbl2GOY1BXB3JhYNtNTwitNOZE4BPnImD283esmGlihgo4Huzl0uQkw02O2HrhoO X5Kt579AaOdNJCVmMpbCy8T+Id9CbjbWKT2LR7K8= Authentication-Results: smtp2j.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: NAT before IPSEC - reply packets stuck at enc0 To: "Muenz, Michael" , freebsd-net@freebsd.org References: <459d59f7-2895-8aed-d547-be46a0fbb918@spam-fetish.org> <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> <63e80fcf-915e-2dd5-d8c9-1904c8261c6f@yandex.ru> <1c91cd8f-105d-e886-3126-67505c6c3900@spam-fetish.org> <1e889acf-49d1-b70f-7097-82e6e4dfabb6@spam-fetish.org> <454ed1b7-a80f-b096-cfa1-3c32d1e60f7d@yandex.ru> <5dfdfbb3-1046-5abe-b23a-b62c215b5d08@yandex.ru> <860b48aa-b99e-7b71-3724-587ee0a7fe80@spam-fetish.org> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Message-ID: <1b831b84-1d3f-38cb-acee-07a339315417@yandex.ru> Date: Tue, 25 Jul 2017 16:04:24 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <860b48aa-b99e-7b71-3724-587ee0a7fe80@spam-fetish.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jrsdn1IOse63sP203C3ehgDAiE8NG7MJO" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jul 2017 13:07:10 -0000 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" To: "Muenz, Michael" , 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> <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> <63e80fcf-915e-2dd5-d8c9-1904c8261c6f@yandex.ru> <1c91cd8f-105d-e886-3126-67505c6c3900@spam-fetish.org> <1e889acf-49d1-b70f-7097-82e6e4dfabb6@spam-fetish.org> <454ed1b7-a80f-b096-cfa1-3c32d1e60f7d@yandex.ru> <5dfdfbb3-1046-5abe-b23a-b62c215b5d08@yandex.ru> <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--