IPSEC problems with pf
I'm trying to setup an IPSEC transport connection between my home and one of my VPS hosts. I can successfully setup an IPv6 connection from an internal host to the VPS but can't setup an IPv4 connection from my firewall to that host. I'm using openiked-portable in esp transport mode using psk (at least for testing). My configuration (much simplified) looks like: Host firewall (internet) VPS 'Host' has a public IPv6 address and I can successfully setup an IPSEC transport connection between it and 'VPS'. IPSEC doesn't work through NAT so I have setup an IPv4 IPSEC transport layer from firewall to VPS. The iked processes can exchange isakmp packets and appear to setup the connection. Running tcpdump on both ends, I see: * "ping VPS" from firewall sends ICMP packets in the clear. They arrive at VPS but there's no response. * "ping firewall" from VPS sends IPSEC esp packets which arrive at firewall but there's no response. Comparing the pf configurations between firewall and VPS, the main difference is that the firewall is configured to NAT internal hosts onto the Internet and RDR some inbound ports to internal hosts. I am logging blocked packets so I'm confident that pf is not blocking the esp packets. I've tried enabling net.inet.ipsec.debug and that generates occasional message like "kernel: key_acqdone: ACQ 19 is not found." but that hasn't helped me solve the problem. I don't understand: a) Why outgoing ICMP packets from firewall to VPS aren't going through the IPSEC transport. b) Why firewall is ignoring incoming IPSEC esp packets. Is anyone able to help? -- Peter Jeremy signature.asc Description: PGP signature
Re: IPSEC problems with pf
CC'ing more knowledgeable developers. 25.09.2021 6:03, Peter Jeremy wrote: > I don't understand: > a) Why outgoing ICMP packets from firewall to VPS aren't going through >the IPSEC transport. > b) Why firewall is ignoring incoming IPSEC esp packets. > > Is anyone able to help? I know three main reasons that may prevent firewall+IPSec from working as expected: 1) for incoming packets: kernel could drop incoming packet withing ipsec code incrementing one of counters shown with "netstat -sp ipsec" command, so you should check it out first; 2) for both outgoing and incoming packets there could be processing order problem: packets processed first by pfil(9) framework (so pf/ipfw have a chance to do NAT etc.) and only then sent to ipsec(4) to transform (in FreeBSD 11 at least), not vice versa. 3) also read if_enc(4) manual page to make familiar with net.enc.out.* and net.enc.in.* sysctl family, as it may affect, too. If you do not use enc(4) pseudo-interface, make sure you changed defaults to: net.enc.in.ipsec_filter_mask=0 net.enc.out.ipsec_filter_mask=0
Re: IPSEC problems with pf
Em 2021-09-24 20:03, Peter Jeremy escreveu:
I'm trying to setup an IPSEC transport connection between my home and
one of my VPS hosts. I can successfully setup an IPv6 connection from
an internal host to the VPS but can't setup an IPv4 connection from my
firewall to that host. I'm using openiked-portable in esp transport
mode using psk (at least for testing).
My configuration (much simplified) looks like:
Host firewall (internet) VPS
'Host' has a public IPv6 address and I can successfully setup an IPSEC
transport connection between it and 'VPS'.
IPSEC doesn't work through NAT so I have setup an IPv4 IPSEC transport
layer from firewall to VPS. The iked processes can exchange isakmp
packets and appear to setup the connection. Running tcpdump on both
ends, I see:
* "ping VPS" from firewall sends ICMP packets in the clear. They
arrive
at VPS but there's no response.
* "ping firewall" from VPS sends IPSEC esp packets which arrive at
firewall but there's no response.
Comparing the pf configurations between firewall and VPS, the main
difference is that the firewall is configured to NAT internal hosts
onto the Internet and RDR some inbound ports to internal hosts. I
am logging blocked packets so I'm confident that pf is not blocking
the esp packets.
I've tried enabling net.inet.ipsec.debug and that generates occasional
message like "kernel: key_acqdone: ACQ 19 is not found." but that
hasn't helped me solve the problem.
I don't understand:
a) Why outgoing ICMP packets from firewall to VPS aren't going through
the IPSEC transport.
b) Why firewall is ignoring incoming IPSEC esp packets.
Is anyone able to help?
Hello!
I have a client with similar conf
Fortigate Local(IPSec) <-> FreeBSD with PF <-> Internet <-> Foritgate
Remote(IPSec)
In pf.conf something like this:
FORTIGATE_LOCAL=10.0.0.11
EXT_IP=192.168.0.10
# normalization
scrub in all fragment reassemble
# NAT output
nat on $IF_EXT from $FORTIGATE_LOCAL to any -> $EXT_IP
# NAT IPSEC
nat on $IF_EXT proto udp from $FORTIGATE_LOCAL port { 500, 4500 } to any
-> $EXT_IP static-port
nat on $IF_EXT proto esp from $FORTIGATE_LOCAL to any -> $EXT_IP
static-port
# rdr admin-fortigate
rdr pass on $IF_EXT from any to $EXT_IP -> $FORTIGATE_LOCAL
# internet output
pass out on $IF_EXT from $EXT_IP to any
I hope it's useful!
Re: IPSEC problems with pf
On Fri, Sep 24, 2021 at 4:04 PM Peter Jeremy wrote: > > IPSEC doesn't work through NAT > Did NAT-T stop working?
[Bug 254695] Hyper-V + TCP_BBR: Kernel Panic: Assertion in_epoch(net_epoch_preempt) failed at netinet/tcp_lro.c:1180
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254695 --- Comment #43 from Gordon Bergling --- (In reply to commit-hook from comment #42) @tuexen: could you MFC this bugfix to stable/13? I think this bug can then be closed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added CC||a...@freebsd.org Status|Open|In Progress Assignee|n...@freebsd.org |k...@freebsd.org Flags|maintainer-feedback?(kp@fre |maintainer-feedback+ |ebsd.org) | --- Comment #24 from Kubilay Kocak --- (In reply to Kristof Provost from comment #23) Appreciate the detail Kristof. If we're aware of any breadcrumbs available (mailing list, reviews, or elsewhere) for Andreys plans or wip, please add them here. ^Triage: Assign to committer resolving via base 20ffd88ed54f pending MFC -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 --- Comment #23 from Kristof Provost --- (In reply to Kubilay Kocak from comment #22) That works for me. I have no plans to work on increasing this limit, but ae@ is working on a new and improved dummynet version which will no doubt also address this problem. As far as I know there's no timeline for that, but anyone interested in working on this problem should coordinate with him. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added Flags||mfc-stable13? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.
[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kubilay Kocak changed: What|Removed |Added Flags|maintainer-feedback?(loos@F |maintainer-feedback?(kp@fre |reeBSD.org) |ebsd.org) Keywords|needs-qa| --- Comment #22 from Kubilay Kocak --- (In reply to Kristof Provost from comment #21) Close this pending discussion on list (or in a new issue) to solve this in the broader/general case? The issue is resolved 'as reported' (no longer a signed integer limit) and has been around since 2014. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
[Bug 194453] dummynet(4): pipe config bw parameter limited to 2Gbits/s (signed integer limit)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194453 Kristof Provost changed: What|Removed |Added CC||k...@freebsd.org --- Comment #21 from Kristof Provost --- (In reply to Franco Fichtner from comment #20) It does not fully solve the problem, no. It was committed because it was easy, and doubling the limit is not nothing. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
