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 = "YES" # Set to YES to run setkey on ipsec_file ipsec_file = "/ 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=setkey&sektion=8&manpath=freebsd-release-ports http://www.freenix.no/arkiv/daemonnews/200101/ipsec-howto.html Thank you for your help Em ter., 17 de mar. de 2020 às 10:22, Cristian Cardoso <[email protected]> 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 > strongswan > 10.31.32.67/32 10.19.12.251 UGS xn0 > > Thanks for help = ) > > Em ter., 17 de mar. de 2020 às 09:54, Artem Viklenko > <[email protected]> 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.12.251 > > > nat on enc0 inet proto icmp from 10.0.0.0/8 to 10.31.32.67 -> 10.19.12.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 another > > > network within 10.0.0.0/8 > > > > > > Any suggestion? > > > > > > Em ter., 17 de mar. de 2020 às 02:48, Artem Viklenko > > > <[email protected]> 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 tunnel > > >>> 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 > > >>> postrouting? > > >>> > > >>> Best Regards > > >>> _______________________________________________ > > >>> [email protected] mailing list > > >>> https://lists.freebsd.org/mailman/listinfo/freebsd-pf > > >>> To unsubscribe, send any mail to "[email protected]" > > >>> > > >> > > >> -- > > >> Regards! > > > > > > > -- > > Regards! _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "[email protected]"
