From owner-freebsd-pf@freebsd.org Tue Mar 17 19:56:04 2020 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F19D2712F5 for ; Tue, 17 Mar 2020 19:56:04 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48hkSJ5zRXz3Drk for ; Tue, 17 Mar 2020 19:56:00 +0000 (UTC) (envelope-from cristian.cardoso11@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id a43so6302621edf.6 for ; Tue, 17 Mar 2020 12:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=7M25fHDxkGxKRnBZNvMpU+hZRPLtWXbjWSzd8vuscmc=; b=FSt10XOw7FO0LcTOB01g4dPGF/zr2T9pSflClA+4LhRWSUUqHdB24HnXacIAwSD+AY G9Tcsb58lge/9BiEFnpfea2VMklndHfdhEq7XUXzcOnGUBK+6RwqhqD0YzWvyaJj9g+p GN4GGAlooNCJH3yNTfD4uC2aXPUX4Msuuko0L+PIG7a0IoJBsJ+kk4k9m8YV+m4jPCGe LAV0XrY5O4+7y6kAvyf0zr2yVkepIWNHf856JN8eHaKRMeOrBtmAVgIAHMDZd8On5HPa fFQs7lsFDI2nnJinU7KTZCwaR+vIYoD1DP7tcrfWA/f+DKQ4+jLMkah/NKt/z7Q0/7Kr aKow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=7M25fHDxkGxKRnBZNvMpU+hZRPLtWXbjWSzd8vuscmc=; b=k6RbSmJmF6/WZCrWyajO6rVzMU71eUiAktPZMyDKve1dwke9+g2okSEeSdfapmN/E0 hYWo2MjYM9U9uiTeKFF2u1jD6ba9TPdmmM04K89ZgBDoO5SG3OETxMz4KhlM7oKAy1aN obd5Qne/yBLzmIMoME8BZXjFExQoOF4yXW0Pt0nWn94FQOYpYuxJW1rCm99LI8MyXJf7 /bNMFUdp3bYN8JgC1KIpsiFQ9pODtEp7YtqMitUKV9vVgak4ZB2SUWu/AmsQ6ZP27J5C xfs0qFFCa7Yz49TsADDRCQTIqpMdJXOP4veDdDWe00OkaAdlDaJZ4gZ2kZ//MA2Xma0l 9Efg== X-Gm-Message-State: ANhLgQ3msJVwFxEgTRroCWS7/vF648NeSADJkDsoPCy/7v/d6KIqEgcD vaYLVupCL3qEsCdKlXmhcImYeUPlGpEFPCQuTAlPCsgNWQ== X-Google-Smtp-Source: ADFU+vuIenfqBSS++ffM2CNXNq4HeGbT80DxRH4434Q9bl23z+th0qAmCX3lbVPvp/cy5sZtEigl3gWqseGWMjfGc0s= X-Received: by 2002:a17:906:e10d:: with SMTP id gj13mr745063ejb.291.1584474958261; Tue, 17 Mar 2020 12:55:58 -0700 (PDT) MIME-Version: 1.0 References: <4c936163-f77b-3fe1-56be-8f6967add0ef@viklenko.net> <59961b63-a5b8-e0e6-55de-76ab9c43763c@viklenko.net> In-Reply-To: From: Cristian Cardoso Date: Tue, 17 Mar 2020 16:55:46 -0300 Message-ID: Subject: Re: PF + IPsec To: Artem Viklenko Cc: freebsd-pf@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 48hkSJ5zRXz3Drk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=FSt10XOw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of cristiancardoso11@gmail.com designates 2a00:1450:4864:20::52c as permitted sender) smtp.mailfrom=cristiancardoso11@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[c.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; IP_SCORE(0.00)[ip: (-9.55), ipnet: 2a00:1450::/32(-2.39), asn: 15169(-1.65), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2020 19:56:04 -0000 After some more research, I discovered a few things. The nat in the enc0 interface that you informed me was correct. The part I did not understand and did not know until now is that when the tunnel is / 24 to / 24 external routes do not enter into the route table of the setkey command. After discovering this, I put it in rc.conf ipsec_enable =3D "YES" # Set to YES to run setkey on ipsec_file ipsec_file =3D "/ etc / ipsec.conf" # Name of config file for setkey and in the /ipsec.conf file I put the following spdadd -4 10.0.0.0/8 10.31.32.67 any -P out ipsec esp / tunnel / my valid ip - remote valid ip / unique: 1; spdadd -4 10.31.32.67 10.0.0.0/8 any -P in ipsec esp / tunnel / my valid ip - remote valid ip / unique: 1; With that + the nat rule that you indicated everything worked correctly. Referral link that might help someone else: https://unix.stackexchange.com/questions/457838/nat-outbound-ipsec-packets-= using-pf-on-freebsd-11-and-strongswan-x-fortigate https://www.freebsd.org/cgi/man.cgi?query=3Dsetkey&sektion=3D8&manpath=3Dfr= eebsd-release-ports http://www.freenix.no/arkiv/daemonnews/200101/ipsec-howto.html Thank you for your help Em ter., 17 de mar. de 2020 =C3=A0s 10:22, Cristian Cardoso escreveu: > > I tried first that way you said, but it doesn't work, returned the > expired ttl message in transit, when I try to run icmp from some host > that is on a network outside freebsd, in my test only with the nat > rule in enc0 > > Running tests from a host on another network, for example on the > 10.7.8.0/24 network > > The way is this > 10.7.8.243 -> 172.0.10.11 -> 10.19.12.251 -> vpn tunnel > > Without the nat rule on the xn0 interface, neither echo reply occurs > within the vpn tunnel > With the nat rule, on the xn0 interface, echo reply occurs within the > enc0 interface, only the packet is returned outside 10.19.12.251 which > does not occur for networks outside freebsd / 24 > > In the freebsd route table, the tunnel is configured in this way via stro= ngswan > 10.31.32.67/32 10.19.12.251 UGS xn0 > > Thanks for help =3D ) > > Em ter., 17 de mar. de 2020 =C3=A0s 09:54, Artem Viklenko > escreveu: > > > > You don't need rdr > > > > nat on enc0 inet from 10.0.0.0/8 to 10.31.32.0/24 -> 10.19.12.251 > > > > > > On 17.03.20 14:35, Cristian Cardoso wrote: > > > I tried as follows without success: > > > > > > rdr on xn0 inet proto icmp from 10.31.32.67 to 10.0.0.0/8 -> 10.19.12= .251 > > > nat on xn0 inet proto icmp from 10.0.0.0/8 to 10.31.32.67/32 -> 10.19= .12.251 > > > rdr on enc0 inet proto icmp from 10.31.32.67 to 10.0.0.0/8 -> 10.19.1= 2.251 > > > nat on enc0 inet proto icmp from 10.0.0.0/8 to 10.31.32.67 -> 10.19.1= 2.251 > > > > > > xn0 is my interface that goes to the internal network that is beyond > > > the freebsd and enc0 of the vpn, I just put the icmp protocol for > > > testing > > > I checked on tcpdump on the enc0 interface, which occurs echo request > > > and echo reply, but does not return to the PC that ran icmp on anothe= r > > > network within 10.0.0.0/8 > > > > > > Any suggestion? > > > > > > Em ter., 17 de mar. de 2020 =C3=A0s 02:48, Artem Viklenko > > > escreveu: > > >> > > >> Hi! > > >> > > >> PF do NAT on outbound and RDR on inbound. > > >> You can try to do NAT on enc0 interface instead of lan. > > >> > > >> > > >> On 17.03.20 04:28, Cristian Cardoso wrote: > > >>> Hello > > >>> I'm setting up a Freebsd server for ipsec vpn communication with > > >>> strongswan and I'm having some difficulties in the operation > > >>> > > >>> The freebsd server's local network is 10.19.12.0/24 and can connect > > >>> correctly to the network on the other side of the tunnel. > > >>> > > >>> I would like another network behind my server to connect to the tun= nel as well. > > >>> > > >>> In linux I would nat the network that is arriving as follows: > > >>> iptables -t nat -A POSTROUTING -s 10.0.0.0/8 -d 10.31.32.0/24 -j > > >>> --SNAT --to 10.19.12.251 > > >>> > > >>> In FreeBSD I tried to run the rule as follows, but to no avail > > >>> nat on $ LAN inet from 10.0.0.0/8 to 10.31.32.0/24 -> 10.19.12.251 > > >>> > > >>> Is there any other way to generate the equivalent of FreeBSD postro= uting? > > >>> > > >>> Best Regards > > >>> _______________________________________________ > > >>> freebsd-pf@freebsd.org mailing list > > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-pf > > >>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.or= g" > > >>> > > >> > > >> -- > > >> Regards! > > > > > > > -- > > Regards!