Project

General

Profile

Actions

Bug #11230

closed

Firewall match rules incorrectly matching multiple OpenVPN tunnel interfaces

Added by Gavin Owen over 3 years ago. Updated over 3 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
Traffic Shaper (ALTQ)
Target version:
-
Start date:
01/07/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.5-p1
Affected Architecture:

Description

It would seem that that the firewall match rules match any OpenVPN tunnel rather than just the tunnel interface which is specified in the match rule.

I have two OpenVPN tunnels between Firewall "A" and "B" via different WANs:
FW-A (WAN1) <--> (WAN1) FW-B
FW-B (WAN2) <--> (WAN2) FW-B

Place two floating tab match rules on FW-B in the "in" direction:
1) first one is for the WAN1 tunnel interace matching source subnet-A, destination subnet-B, protocol "any", hitting queue "qTun1"
2) second one is for the WAN2 tunnel interface matching source subnet-A, destination subnet-B, protocol "any", hitting queue "qTun2"

Start an ICMP traffic generator on subnet-A over the WAN1 tunnel. on FW-B, ICMP echo replies are seen against qTun1" on the tunnel interace, but it shows "qTun2" being used for the LAN instead of the correct "qTun1".

If I shut the WAN2 tunnel the issue still remains. Have verified qTun1 is only for the WAN1 tunnel and likewise qTun2 is only for the WAN2 tunnel. There is no asymmetric routing.... especially so when shutting the WAN2 tunnel so there is only a single set of WANs, single tunnel, and single LANs on both sides.
States reset. Firewalls rebooted - same issue.

Another test this time with OSPFv2, just sharing routes over both the WAN1 and WAN2 tunnels. If I have two match rules named "qTun1_OSPF" and "qTun2_OSPF", I see that both match rules accumulate hits even after disabling the WAN2 tunnel (and clearing states and reloading both firewalls).

I first saw this production on Intel CPU running 2.4.5p1. Gigabit 82583V Ethernet NICs (em* interfaces). I have replicated in a lab environment with 2.4.5p1 and then upgraded the lab to 2.5.0 latest development - same result. I am at your total disposal in order to resolve this issue - please let me know what i can do to help. Thank you kindly.

Actions

Also available in: Atom PDF