Project

General

Profile

Bug #8686

IPsec VTI: Assigned interface firewall rules are never parsed

Added by Steve Wheeler over 2 years ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
07/24/2018
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.4.4
Affected Architecture:
All

Description

Traffic entering an assigned VTI interface never hits firewall rules on that specific interface tab even if they are present.
Traffic must still be passed on the main IPsec tab.
This is potentially confusing, it's not the expected behavior that other interface types exhibit.

History

#1 Updated by Jim Pingle over 2 years ago

  • Subject changed from IPSec VTI: Assigned interface firewall rules are never parsed to IPsec VTI: Assigned interface firewall rules are never parsed
  • Description updated (diff)
  • Assignee deleted (Jim Pingle)

Issue #8685 will work around this for now, but we can use this issue to track the longer-term problem of how these rules interact. We may have to wait for FreeBSD to solve this one since it appears to be an issue in how pf and if_ipsec interact, and how traffic shows up both on enc0 and the specific ipsecXXXX interface.

#2 Updated by Jim Pingle 6 months ago

Re-tested this since we have a new base OS on 2.5.0. Unfortunately, this still behaves the same way on 12.1-STABLE:

Adding a pf rule on a VTI interface, it does not function as expected. With no rules on enc0, and a pass all rule on ipsec4000, no traffic is passed.

@145(1528159274) pass in quick on ipsec4000 reply-to (ipsec4000 10.6.106.2) inet all flags S/SA keep state label "USER_RULE: VTI Test Rule" 
  [ Evaluations: 16050     Packets: 0         Bytes: 0           States: 0     ]
  [ Inserted: pid 21034 State Creations: 0     ]

Note that the evaluations counter increases, but it never matches.

tcpdump does not show any packets arriving on the ipsec4000 interface with this rule present.

If you add a rule to enc0 to pass the traffic, it works and then traffic also appears in tcpdump captures on ipsec4000 as it flows.

Packets are always visible in tcpdump on enc0.

#3 Updated by Ari Suutari 5 months ago

Is this related:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232522

filtertunnel sysctls seem to be 0 in pfsense.

#4 Updated by Jim Pingle 5 months ago

That is certainly worth testing but we've had problems flipping that in the past (See #2993, #2636, and several forum threads) so it may not be a general solution.

If it works, we can document it at least. But we'd also have to check for regressions in behavior of tunneled (non-VTI) IPsec, transport mode IPsec, and general IPsec throughput/performance.

#5 Updated by Jim Pingle 5 months ago

It doesn't appear to be related. Setting that sysctl to 1, the traffic still arrives on enc0 and is blocked by pf inbound on enc0.

#6 Updated by Jim Pingle about 1 month ago

I thought it was noted here but I don't see it. There is another FreeBSD issue at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248474 in which they recommend disabling pfil for if_enc and setting filtertunnel similar to the above:

net.enc.out.ipsec_filter_mask=0
net.enc.in.ipsec_filter_mask=0
net.inet.ipsec.filtertunnel=1
net.inet6.ipsec6.filtertunnel=1

However, that cripples policy-based tunnels since there would now be no way to filter their traffic.

There is still no acceptable solution that allows both to work at once.

Also available in: Atom PDF