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:
    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.
    94bce10f-077a-4ed1-a916-7d6c97547efe-image.png

    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.
    4ff23989-4584-4f84-aa03-25d2e290a633-image.png

    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:
    0770c497-d792-490e-8610-fbbda5add54c-image.png

    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:
    fa1af5bf-a9aa-4b90-b96b-22a51b1da4a1-image.png

    this shouldn't match anything as the TUN_LT2_GT1 tunnel is down
    c9c505f8-afb1-40a7-8939-89d3723f9cd2-image.png

    proof TUN_LT2_GT1 is down...
    74624576-5023-4674-8b0e-1f4d516a4c94-image.png
    cc3dc250-6605-493b-bd77-fa0ba90df0a5-image.png


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