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

    OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2)

    Scheduled Pinned Locked Moved OpenVPN
    26 Posts 3 Posters 3.4k 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.
    • DerelictD
      Derelict LAYER 8 Netgate
      last edited by

      Yeah. The port forward traffic cannot match that, which it does.

      That means you do not get reply-to on the states.

      I would assign an interface to the road warrior instance, put the pass any rule there, and put no rules on the OpenVPN tab and it will work.

      Chattanooga, Tennessee, USA
      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
      Do Not Chat For Help! NO_WAN_EGRESS(TM)

      S 1 Reply Last reply Reply Quote 1
      • S
        Steven SL @Derelict
        last edited by

        @derelict said in OpenVPN, AirVPN and port forwarding no longer works (2.4.4relp2):

        Yeah. The port forward traffic cannot match that, which it does.

        That means you do not get reply-to on the states.

        I would assign an interface to the road warrior instance, put the pass any rule there, and put no rules on the OpenVPN tab and it will work.

        Thank you so much, I am i awe that you figured this out with the little bit I gave you. It is working now! I am so impressed!

        I don't fully understand why, but I did as you said - I created a new interface for what my setup has as "ovpns2", removed the allow all rule under OpenVPN and tested again. Success. Why would the default OpenVPN interface interfere?

        New Interface
        0_1548643703519_877877de-4f1b-4d70-88e1-2919b21dcd05-image.png

        Road warrior rules:
        0_1548643777793_a20b41dd-b62a-48ec-b856-323df7149a36-image.png

        OpenVPN (removed the only rule)
        0_1548643823964_ae44ef42-2e01-437b-af16-d0c5e30401ed-image.png

        1 Reply Last reply Reply Quote 0
        • DerelictD
          Derelict LAYER 8 Netgate
          last edited by Derelict

          Because the OpenVPN tab really represents an interface group of all OpenVPN instances both server and client.

          When a connection arrives into that it is impossible for pf to know which one it will arrive on so it cannot apply reply-to to the rules there. When you are accepting connections in from locations that your local OpenVPN knows about (has specific routes to), like in a remote access or typical site-to-site configuration, this does not matter because the routing table (and openvpn) will route the reply traffic where it needs to go.

          When you are accepting connections from arbitrary source addresses, you need reply-to on the rules or the routing table will direct the reply traffic which, to an arbitrary destination on the internet, will probably mean it tries to send it out to its default gateway.

          And, like most everywhere else in pfSense, first match wins and stops rule processing and interface group rules are processed before interface rules so traffic that needs reply-to cannot match rules there.

          Chattanooga, Tennessee, USA
          A comprehensive network diagram is worth 10,000 words and 15 conference calls.
          DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
          Do Not Chat For Help! NO_WAN_EGRESS(TM)

          1 Reply Last reply Reply Quote 1
          • G
            g4m3r7ag
            last edited by

            Just want to add I was having this exact same problem and this was also the solution for me. My remote VPN access however was not working after I moved it to it's own interface and added the new FW rule for that interface. I had to reboot pfSense for it to work. I could connect but no traffic would flow back to remote device. I believe a state just got hung up somewhere and the reboot cleared it.

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              The OpenVPN instance has to be restarted after an interface is assigned. This is in all of our documentation related to assigning OpenVPN interfaces. A system reboot was likely not necessary.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • G
                g4m3r7ag
                last edited by

                Your right, I recall that now, that's what I get for troubleshooting at 5AM.

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