0

I have a small network in Azure that I need to grant access to. Because most of the people in my office use Macbooks, the Microsoft VPN gateway is not going to work.

To enable a VPN connection, I have created a VM running the pfSense image.

I am able to connect to the Web Server exposed by this VM and configure the pfSense OpenVPN server.

However, I am unable to connect to the OpenVPN server to make a connection. In the Open VPN connect screen I get the following:

Wed Aug 31 15:49:00 2016 TCP: connect to [AF_INET]nnn.nnn.nnn.nnn:1194 failed, will try again in 5 seconds: Connection timed out (WSAETIMEDOUT)

I have:

  • Verified that the nnn.nnn.nnn.nnn is the public IP address of the pfSense VM
  • SSH'd into the VM and verified that it is listening on port 1194 USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root openvpn 3403 6 tcp4 *:1194 *:* root nginx 23708 6 tcp4 *:443 *:* root nginx 23708 8 tcp4 *:80 *:* root sshd 13231 5 tcp4 *:22 *:*
  • Checked the Network Security Group for the VM's subnet. Confirmed that it allows any protocol, any source to pass over 1194
  • Checked the Network Security Group for the VM's network interface. Confirmed that it is set to 'None'
  • Verified that I can locally connect to port 1194
  • Verified that I can remotely connect on port 443 (remember that I can connect to the VM's web server)
  • From an AppServices console (has a connection configured to the VNET), I can connect to 80 & 443, but not 1194 (connection timeout).
  • I see no indications in the pfSense logs that a connection attempt was made.
  • Running pfTop when SSH'd to the VM shows connection attempts for 80 & 443, but not for 1194.

I believe that something in my Virtual Network setup is blocking traffic on 1194, but I'm not sure where else to check.

Andy Davis
  • 101
  • 4

2 Answers2

1

Please try to connect to the TCP 1194 locally. This test will avoid the influence of firewall.

If the connection fails, it suggests that there is something wrong in the server side.

If the connection success, to narrow down the scope of this issue, I would suggest you perform a network capture on the server to check if the connect from the client has reached the network adaptor of the server.

If the adaptor receives the packets from client, it means that something on the server block the connection. The most common cause is the misconfigured firewall. (Iptables)

If the adaptor doesn't receive the packets, then you should double-check the NSG. Or try to recreate them. If issue persists and you are sure about the NSG inbound rules. Then you may need to open a ticket with Azure support, so that they are able to perform the network capture on the host level to find out what drops the packets.

Steven Lee - MSFT
  • 713
  • 4
  • 8
  • Thanks. I have updated the question to reflect that I can connect to 1194 locally and that pftop does not show the connection attempt on 1194 (but does on 80 and 443). – Andy Davis Sep 07 '16 at 13:27
0

The issue was the packet filter on pfSense denying the connection. One thing that I had forgotten to mention was that we're running OpenVPN over TCP (to mirror the configuration of a different pfSense box).

When you configure the OpenVPN to connect over TCP, it does not update the pfSense firewall rule that admits traffic on 1194. That rule is set to UDP. Changing the rule to allow TCP clears the issue.

Useful Information

One thing that isn't terribly obvious from the docs is that when you create the pfsense box from the official image, it will automatically create an 'admin' user. This user will be set up with the same password/public key that you supply for the user at instance creation.

With this information, you can ssh to the box and get a nice little console menu that allows root access.

From that root console, you can toggle the packet filter off and on:

pfctl -d <disables>
pfctl -e <enables>

Temporarily disabling the packet filter allowed me to rule out all things Azure as the source of my trouble.

Andy Davis
  • 101
  • 4