Date: Mon, 20 Oct 2014 11:18:10 -0500 From: Matthew Grooms <mgrooms@shrew.net> To: freebsd-net@freebsd.org Subject: Broken IPsec + enc +pf/ipfw Message-ID: <544535C2.9020301@shrew.net>
next in thread | raw e-mail | index | archive | help
All, There appears to be an issue with FreeBSD 10.x when using enc device to filter inbound traffic on the receive path. After searching the mailing lists, I see two different people reporting the issue ... https://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076900.html https://lists.freebsd.org/pipermail/freebsd-net/2014-February/037951.html The second report had tracked it down to a specific commit ... http://svnweb.freebsd.org/base?view=revision&revision=254519 There appears to be quite a bit of info in both email threads, but I'll do my best to sum it up again. When an ESP packet arrives at a host for processing, the packet is seen on the enc0 interface but isn't seen by the pf firewall. This prevents the firewall from creating a state entry so returned packets get blocked by the firewall. IMO, this degrades the security of IPsec as makes it pretty much impossible to have a stateful firewall protect inbound traffic that arrives from an IPsec peer unless you are willing to write rules that let private network traffic inbound via your public interface after disabling enc ... # enc0 device options net.enc.in.ipsec_bpf_mask=2 net.enc.in.ipsec_filter_mask=2 net.enc.out.ipsec_bpf_mask=1 net.enc.out.ipsec_filter_mask=1 NOTE: These are the recommended settings from the ENC(4) man page. It should cause the inbound and outbound packets to be visible on the enc device without the outer header. [root@fw1 ~]# tcpdump -nei enc0 src or dst x.x.x.x tcpdump: WARNING: enc0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 65535 bytes capability mode sandbox enabled 11:06:42.256172 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 0, length 64 11:06:43.257731 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 1, length 64 11:06:44.260129 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 2, length 64 11:06:45.263452 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 3, length 64 11:06:46.264225 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 4, length 64 11:06:47.258684 (authentic,confidential): SPI 0x032a11d7: x.x.x.x > y.y.y.y: ICMP echo request, id 12350, seq 5, length 64 [root@fw1 ~]# tcpdump -nei pflog0 src or dst x.x.x.x tcpdump: WARNING: pflog0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on pflog0, link-type PFLOG (OpenBSD pflog file), capture size 65535 bytes capability mode sandbox enabled 11:06:42.257911 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 0, length 64 11:06:43.258224 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 1, length 64 11:06:44.260459 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 2, length 64 11:06:45.263674 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 3, length 64 11:06:46.264364 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 4, length 64 11:06:47.259121 rule 0..16777216/0(match): block in on vlan20: y.y.y.y > x.x.x.x: ICMP echo reply, id 12350, seq 5, length 64 I can confirm this is a regression between 9.x to 10.x as I upgraded a set of firewalls last night from 9.2 to 10.0. They use exactly the same configuration with the exception of some tweaks to the carp interface config ( changed significantly between 9.x and 10.x ). I also have two other sets of firewalls that run the exact same type of configuration on 9.x that are working exactly as expected. Lastly, I tried to locate a relevant PR but didn't find anything concrete. Is this related to the issue? And if so, can it be MFCd? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=110959 Thanks, -Matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?544535C2.9020301>