Incorrect matching on OpenVPN Tunnel Interfaces

  • 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:

    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
    Status Queues showing issue.png

    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 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.