0

I have OpenVPN configured on an Ubuntu 16.04 server. I am able to use this VPN service from one network but not from others and would appreciate any help.

Home Network
Everything works fine. I am able to connect to the VPN and browse webpages from different devices (macbook and android phone).

Work Network
VPN client connects but I am unable to browse webpages on any device.
Pinging hostname works so it may not be a DNS issue.
Browser pages get stuck on connecting till they timeout.
Slack client does not connect however the Dropbox client does report being connected.

Mobile Data
Same as work network.

Server Config

port 443
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

Client Config

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote x.x.x.x 443  #My Server's IPAddress
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3

Although this config uses port 443 I had the same problem while using the default port 1194.
I have also experimented by changing the DNS push configuration and using Google DNS servers but this does not make any difference.

Hoping someone can help.

12
  • Do you know if a corporate firewall exists at work that could be blocking requests? Does this happen on other networks than at work?
    – harrymc
    Commented Feb 25, 2017 at 8:36
  • From the fact that you are using block-outside-dns I guess that your client is on Windows. You might try to remove that directive. I remark that ping may work in spite of DNS problems, because ping on Windows uses the DNS Client service while the browser opens a connection on the DNS port and issues a DNS query. You could try and stop this service and see whether this makes a difference. nslookup is a better test for DNS than ping because it doesn't use the service.
    – harrymc
    Commented Feb 26, 2017 at 9:28
  • I would check the routes: try to do a traceroute and see whether the packets are forwarded through the VPN.
    – simlev
    Commented Feb 28, 2017 at 8:45
  • @harrymc The device I am using is a Macbook running OS X. (although I have tried from a windows 10 laptop and encounter the same issue). I have tried removing block-outside-dns from the client config and I still face the same issue. I am unsure if there is a firewall, however the fact that I am able to ping after being connected to the VPN should indicate that there is no firewall.
    – Anomaly211
    Commented Feb 28, 2017 at 9:05
  • @simlev traceroute and ping both work through the vpn. Its just the browsers (firefox, chrome) and some apps (slack) that don't connect.
    – Anomaly211
    Commented Feb 28, 2017 at 9:06

2 Answers 2

0

I suggest trying port 443 with TCP protocol. Since this is the HTTPS port most firewalls don't probe the packets over TCP 443 as they are expected to be encrypted. So this makes VPN data packets to have better chance to survive through the firewall:

proto udp
port 1194

My second suggestion, having a HTTP proxy such as Squid running on the same server with the OpenVPN and configure it to listen on port 443. Make sure secure that server. With proxy, you can make your Openvpn server listening on the local IP and default port as only proxy service running on the localhost will actually connect to it. No need to change the default server config :

# SERVER
proto udp
port 1194

# You can easily change the client. On the client, you can configure it to 
# connect to the VPN over proxy by adding changing a couple of lines :

# CLIENT
proto udp
http-proxy <SERVER IP> 443
remote <SERVER IP> 1194

Last, if none of the above work, you may try finding a better MTU.

0
0

Can you check your server logs to confirm the connection is really completing?

Also, is that your full client conf?

If so, I am not sure how this is working at all, considering the server has tls-auth ta.key 0 - you would need this configured on both ends (with the client end using a 1 instead of 0) to be able to actually connect.

I would start by validating your premises, and as other have suggested, then start obsessing about routing tables and firewalls at work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .