Incorrect matching on OpenVPN Tunnel Interfaces

[Gcon]

I believe I have found a bug in pfSense traffic shaper / match rules, not matching the correct OpenVPN tunnel interface. I have two OpenVPN tunnels between two pfsense firewalls "GT" and "LT":

GT-WAN1 <---> LT-WAN1 (named "TUN_LT1_GT1" - LT is client)
GT-WAN1 <---> LT-WAN2 (named "TUN_LT2_GT1" - LT is client)

OSPF takes care of tunnel selection (when both are up at the same time)

As you can see, GT has a single WAN. GT just has these queues for tunnels:
qWAN1_CorpDefault (default queue for tunnel interface)
qWAN1_CorpRDS (Remote Desktop Session)
qWAN1_OSPF (routing)

For LT I use the same but with queues for both WANs:
qWAN1_CorpDefault
qWAN1_CorpRDS
qWAN1_OSPF
qWAN2_CorpDefault
qWAN2_CorpRDS
qWAN2_OSPF

With just this rule here, the qWAN1_CorpDefault queue on the TUN_LT1_GT1 interface and the LAN interface (LT_DATA) is matching on both and working perfectly.

Alas, with the following rule to match purely against TUN_LT2_GT1, it inexplicably gets matched just for the LAN interface (LT_DATA) even though TUN_LT2_GT1 is for an OpenVPN tunnel which is disabled.

That is that rule which causes the queue on the LAN (LT_DATA) to swap over to qWAN2_CorpDefault instead of the correct qWAN1_CorpDefault.

The direction of both rules is in the inbound direction as a floating rule (match rule). I cannot explain this other than a bug as TUN_LT2_GT1 cannot take any traffic as the OpenVPN tunnel it represents is disabled - nothing should match on that interface! I cloned my lab to pfsense 2.5.0 latest dev release and see it has the same issue.

Here is output of a traffic generator pinging from the GT LAN to the LT LAN. The traffic bizarrely switches from qWAN1_CorpDefault on the tunnel interface to qWAN2_CorpDefault on the LAN

Any ideas? Should I log this to Redmine? I would love to see it resolved for 2.5.0.

EDIT. Did some more testing. when I ping in the other direction (from LT LAN to GT LAN) the "Status / queues" looks pretty much the same, except i am getting hits on this rule which is again on an interface where the OpenVPN tunnel is disabled:

Also what is interesting is that even though only TUN_LT1_GT1 is up (and TUN_LT1_GT1 OpenVPN tunnel is admin disabled), I am getting hits on both the OSPF rules:

this shouldn't match anything as the TUN_LT2_GT1 tunnel is down

proof TUN_LT2_GT1 is down...

[Gcon]

@gcon Post above supposed to say "and TUN_LT2_GT1 OpenVPN tunnel is admin disabled), " but I'm now getting spam blocked from too many edits.