OpenVPN Server Behind 1:1 NAT
-
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
-
@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 openvpnor just filtered if its not working
-
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.
-
@robpur There is no reason for the one export method not to work versus the other. Most probably some typo.. Anyway if it works...