Websites won't load after attempted openvpn setup

snovosel112811 · 01-15-2017, 02:04 PM

Hello everyone,

I hope someone here can help me, if this is not the correct location for this question please redirect me to the appropriate place.

I am attempting to set up an openvpn connection. I'm running Ubuntu 16.04 on both client and server.

I have the connection set up. However, I wanted to enable IP forwarding so I ran the following command (per the HOWTO section of openvpn.net):

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

This made my internet connection act a little strange. I would load google searches without a problem, however trying to connect to specific websites would just sit on "connecting", without anything actually loading. I am NOT connected to the VPN at this time, and only my local network.

I tried to revert back to whatever setting was before I ran this command, so I ran the following command:

iptables --flush

The problem still occurs. I cannot load web pages, and only google searches.

I have a few questions:

What logs will help me find out what exactly is going on with my internet connection?

How can I revert my network settings back to default?

What documentation can I read to learn about how this is working/not working and to ensure that this does not happen again?

Thank you for your help.

dlb101010 · 01-15-2017, 06:15 PM

Hello snovosel112811,

To test if your firewall is completely open, you could try something like:

Code:

        /sbin/iptables --policy INPUT   ACCEPT
        /sbin/iptables --policy OUTPUT  ACCEPT
        /sbin/iptables --policy FORWARD ACCEPT
        /sbin/iptables           --flush
        /sbin/iptables -t nat    --flush
        /sbin/iptables -t mangle --flush
        /sbin/iptables           --delete-chain
        /sbin/iptables -t nat    --delete-chain
        /sbin/iptables -t mangle --delete-chain

These are the commands executed when I run '/etc/rc.d/init.d/iptables clear' on my computer.

HTH,
Dave

sundialsvcs · 01-15-2017, 11:06 PM

You need to provide us with details of your OpenVPN configuration. It may also help to post the output of the route command before and after you successfully connect OpenVPN.

Once successfully connected (in tunnel mode ...), OpenVPN basically acts like a TCP/IP router. There are several ways that it can be set up (e.g. do you want "everything" to go through the tunnel?). So, we can't speculate what applies in your case.

snovosel112811 · 01-16-2017, 11:28 AM

sundialsvcs, the output of the routes command (my VPN connection continues to time out now) is below:

Quote:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface

default 10.8.0.5 128.0.0.0 UG 0 0 0 tun0

default 10.0.0.1 0.0.0.0 UG 600 0 0 wlp58s0

10.0.0.0 * 255.255.255.0 U 600 0 0 wlp58s0

10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0

10.8.0.5 * 255.255.255.255 UH 0 0 0 tun0

128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0

link-local * 255.255.0.0 U 1000 0 0 wlp58s0

I'm not currently connected to the VPN, and I can't connect to the internet. It's such a strange situation, I can google search and pull up the results, but clicking on any link will hang on "connecting" without loading any HTML. I'm wondering if I should just reinstall ...

sundialsvcs · 01-16-2017, 02:07 PM

Your "default route" sends everything to OpenVPN, thus expecting the host on the other side of the link to know how to NAT this traffic out to the Internet.

This appears to be the use-case described by the OpenVPN documentation in: Routing all client traffic (including web-traffic) through the VPN.

Is this how you have your configuration set up?

If you were to "trace your route to Google" with traceroute 216.58.217.228, with OpenVPN connected, you should ... first of all, "see that the route exists." (Although I daresay that it doesn't.) Therefore, you should instead expect to see that "traceroute drops dead," printing a row of asterisks, at some particular "hop."

This "hop" is most likely to be "the other side of the OpenVPN link," and the routing problem will most likely turn out to be that "the traffic that you have sent, from your internal IP-address, doesn't know how to make it home to you."

In spite of the presence of "an encrypted router," this is actually "a fundamental TCP/IP routing problem, irrespective of(!) encryption." Therefore, this is how you should go about diagnosing it. Happy to help further.

rtmistler · 01-16-2017, 02:39 PM

Moved: This thread is more suitable in Linux - Networking and has been moved accordingly to help your thread/question get the exposure it deserves.

snovosel112811 · 01-16-2017, 06:37 PM

sundialsvcs,

Thank you again for your reply. Apologies as I still am trying to understand how to fix this problem.

I ran a traceroute as you said and the asterisks commenced, hopping from point to point until finally the command ended.

I'm not sure where to go from here, as in how to fix this connection problem. The link you added, how to route all traffic through the VPN is correct, in fact I followed that exact command to get to where I am now, except I'm not connected to the VPN at this time and cannot (the connection times out and the syslog says that there is a TLS handshake issue, which I'll have to address once I can actually connect to the internet).

Where should I go from here? How can I begin to route my traffic directly to the internet and have pages load? And finally, why do google searches load but specific webpages time out?

Thank you again for your help with this.

sundialsvcs · 01-17-2017, 09:08 AM

Your route statements are such that do indicate that you are connected to OpenVPN. There is an active tun0 device and traffic is being routed through it.

- - - - -

"Rows of asterisks from traceroute" usually indicate that a return ping was not received. This is the point where the routing is broken.

Quote:

Originally Posted by man traceroute:

The Internet is a large and complex aggregation of network hardware, connected together by gateways. Tracking the route one's packets follow (or finding the miscreant gateway that's discarding your packets) can be difficult. traceroute utilizes the IP protocol `time to live' field and attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.

The man traceroute page is very descriptive and includes several relevant examples.

If you are running the VPN client yourself, then your traffic (when it comes out the other end of the tunnel) will probably carry a 10.8.0.x IP-address. If the machine "where the asterisks start" does not know how to route traffic bearing this IP-address ... it must be sent to the OpenVPN server ... then they will be discarded. It may well be the case that the traffic is making it all the way to the web, but isn't making it back at some critical step, as indicated by traceroute.