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

    VPN rules do nothing

    Scheduled Pinned Locked Moved Firewalling
    7 Posts 2 Posters 976 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.
    • A
      Alex Atkin UK
      last edited by Alex Atkin UK

      I have a strange issue I can't figure out.

      I have one specific host on the network routed via an OpenVPN client with a LAN rule and that same host has some incoming port forwards from the WAN (ZEN) which also work fine. The trouble is, port forwards for the VPN are not working. Incoming connections on the VPN public IP just timeout.

      I have had the VPN provider (AirVPN) check things their side and also done some tests on a VPN endpoint I have control over and indeed it seems the port forwards simply do not work. I'm seeing evaluations on the VPN rules but no state creations or traffic, nothing in the firewall logs either.

      I double-checked my floating rules only apply to LAN and WAN, I even had the entire LAN routing over the OpenVPN connection for a while to no avail.

      Is there anything else that might be blocking this? It seems very odd that WAN port forwards work while VPN ones do not.

      My configuration seems to match several guides I have seen for VPNs and even AirVPN specifically on pfSense.

      alt text
      alt text

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

        If you are port forwarding into an OpenVPN connection from arbitrary addresses:

        1. There must be an assigned interface on the OpenVPN client or server receiving the connections
        2. The traffic must be passed on the OpenVPN assigned interface
        3. The traffic MUST NOT also match any rules on the OpenVPN group tab.

        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
        • A
          Alex Atkin UK
          last edited by Alex Atkin UK

          1. Doesn't the above show the interface assigned or am I missing something?

          2. Am I correct in this is the right way to be passing the traffic to the OpenVPN interface?

          alt text

          1. I had pass all on the OpenVPN tab. I removed it and I'm seeing a little traffic and state matches but nothing making it to the host the ports are pointing to as far as I can tell. AirVPN test still reports timeout.
          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            1. Yes. I still listed all of the required elements.

            2. That has nothing to do with connections coming in from the outside. Those policy-route connections originating from the inside out the VPN.

            3. How about you post the "state matches" you are seeing? Maybe they are not what you think they are.

            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)

            A 1 Reply Last reply Reply Quote 0
            • A
              Alex Atkin UK @Derelict
              last edited by Alex Atkin UK

              @derelict I must be misunderstand something as surely that interface is the VPN endpoint, nothing can be coming from outside that?

              AirVPN reported the iptables rules on their end and clearly that side must be working as surely no traffic would be hitting the port forwarding rules otherwise?

              The HTTP test is curious as no state matching is occurring there and I have tested it from a web browser and it times out.

              alt text

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

                Why are you setting a gateway on those rules to be the gateway of the interface the traffic is coming in on? You are forcing that traffic back out the way it came. Remove the gateways from those rules. Nobody nowhere said that is what you needed to do.

                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)

                A 1 Reply Last reply Reply Quote 1
                • A
                  Alex Atkin UK @Derelict
                  last edited by Alex Atkin UK

                  @derelict Oops, I did that while desperately throwing things at the wall trying to see what would stick and forgot to revert it back. ;)

                  Switched it back to how it was in the first post and that seems to have done the trick. Thanks for your help.

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