Bug #11230
closed
Firewall match rules incorrectly matching multiple OpenVPN tunnel interfaces
0%
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.
Updated by Gavin Owen over 3 years ago
correcting obvious typo:
FW-A (WAN1) <--> (WAN1) FW-B
FW-A (WAN2) <--> (WAN2) FW-B
Updated by Jim Pingle over 3 years ago
- Status changed from New to Not a Bug
- Target version deleted (
2.5.0)
Sounds more like a problem with your testing methodology than the way match rules work. Start a forum thread for more detailed discussion and analysis. If a specific bug can be definitively identified, then open a fresh issue with more complete and accurate information.
Updated by Gavin Owen over 3 years ago
Hi Jim I started a thread already but there are currently no responses
https://forum.netgate.com/topic/159662/incorrect-matching-on-openvpn-tunnel-interfaces
It is perhaps too much for people to get their heads around?
I can explain the issue more succinctly like this - if I only have one match rule that references "queue X", and that match rule is configured against an OpenVPN tunnel interface which is disabled/down, then surely that queue X should never see any matches? But queue X is seeing hits, when it shouldn't be - even after a full reboot at both ends.
Match rules seem to be broken in some edge cases invovlving OpenVPN tunnels. I suspect not many are using queues in this way - splitting up OpenVPN tunnel queues based on both traffic type and WAN link (rather than just traffic type) - but that doesn't mean the issue doesn't exist.