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

    OpenVPN Server Behind 1:1 NAT

    Scheduled Pinned Locked Moved OpenVPN
    4 Posts 2 Posters 515 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.
    • R
      robpur
      last edited by

      I've set up several OpenVPN connections between Viscosity and pfSense without much trouble but I find myself in a new situation and have not been able to establish a tunnel. The difference with this connection is that although the ISP has provided a static public IP address for their customer the ISP is doing 1:1 NAT to a private IP address. Therefore the pfSense box WAN interface has a private address.

      I went through the OpenVPN configuration as normal using the Wizard and then exported the inline configuration using the package openvpn-client-export as I always do. After importing the configuration into Viscosity I edited the connection to change from the private IP address to the public IP. However, when trying to connect I see TLS errors in the Viscosity log file.

      I tried an alternate method when exporting the client configuration with pfSense. Under Client Connection Behavior I usually select Interface IP Address but in this case I changed it to Other and entered the public IP address into the Host Name box. With this method I didn't have to change the IP in Viscosity but it still failed with TLS errors.

      So is there a flaw in my logic that I should be able to set things up just as I have done when 1:1 NAT is not used, and then change the IP address in Viscosity?

      Thanks,

      Rob

      N 1 Reply Last reply Reply Quote 0
      • N
        netblues @robpur
        last edited by

        @robpur 1:1 nat is not a problem for openvpn.
        tls errors manifest a connectivity problem.
        Check your firewall rules on wan.
        Also verfy if there is another firewall upstream.

        nmap -sU -p 1194 should tell you
        expect to see
        PORT STATE SERVICE
        1194/udp open|filtered openvpn

        or just filtered if its not working

        1 Reply Last reply Reply Quote 0
        • R
          robpur
          last edited by

          Thanks for the help netblues. I learned about nmap and found that I had to move to port 1197. All is working now. I appreciate your assistance.

          Also, I found that if I changed the IP in Under Client Connection Behavior as I described in my first post that it would not connect. I had to export the config from pfSense with the private IP and then change it to the public IP in Viscosity.

          N 1 Reply Last reply Reply Quote 0
          • N
            netblues @robpur
            last edited by

            @robpur There is no reason for the one export method not to work versus the other. Most probably some typo.. Anyway if it works...

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