Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Incorrect matching on OpenVPN Tunnel Interfaces

    Scheduled Pinned Locked Moved Traffic Shaping
    2 Posts 1 Posters 508 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      Gcon
      last edited by 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.
      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

      G 1 Reply Last reply Reply Quote 0
      • G
        Gcon @Gcon
        last edited by

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

        1 Reply Last reply Reply Quote 0
        • First post
          Last post
        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.