Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 17 Mar 2020 16:55:46 -0300
From:      Cristian Cardoso <cristian.cardoso11@gmail.com>
To:        Artem Viklenko <artem@viklenko.net>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: PF + IPsec
Message-ID:  <CAKeEC-%2BZ3pVfbiW=FQso0n5zu08FpRp89bjXXk808MuNgVZZBQ@mail.gmail.com>
In-Reply-To: <CAKeEC-JcXCpxdFv8HKNW7jD8_kY28P05nvuBhSYKVUqrnYg69w@mail.gmail.com>
References:  <CAKeEC-LqP-dAFCeSkCnMLU-Qw-j0KxOXLQSmQzX2poLTKZ2W0Q@mail.gmail.com> <4c936163-f77b-3fe1-56be-8f6967add0ef@viklenko.net> <CAKeEC-JsPwx=9GcbsN5xtV2COQU8S46jjeBUNaQrRNao495cDQ@mail.gmail.com> <59961b63-a5b8-e0e6-55de-76ab9c43763c@viklenko.net> <CAKeEC-JcXCpxdFv8HKNW7jD8_kY28P05nvuBhSYKVUqrnYg69w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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
<cristian.cardoso11@gmail.com> 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
> <artem@viklenko.net> 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
> > > <artem@viklenko.net> 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!



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAKeEC-%2BZ3pVfbiW=FQso0n5zu08FpRp89bjXXk808MuNgVZZBQ>