OpenVPN client connects to server, but then I cannot surf the web.

jtetra5

Here is a copy of client.ovpn:

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote [my-public-ip] 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-128-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3

And here is a copy of server.conf:

port 1194
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 209.18.47.61"
push "dhcp-option DNS 209.18.47.62"
keepalive 10 120
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

Again, the client successfully connects to the OpenVPN Server, but I cannot surf the internet. Nothing pings, and when I try to navigate to a web site, I get the following message: Error resolving 'google.com': name or service not known

I have no idea as to why I am encountering this issue. I have Googled the issue but have not found an identical situation. Any help would be greatly appreciated!

TinCanTech

I suggest you report the fault to the writers of the script you used on this post:
https://forums.openvpn.net/viewtopic.php?f=6&t=22324

Or debug the script for them and submit a patch.

Otherwise, please see the Official HOWTO.

jtetra5

I checked out the HOWTO, and found this: https://openvpn.net/index.php/open-source/documentation/howto.html#redirect. As it instructed, I ran the command

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

, but I am still having the same issue.

Here is the results of the command

netstat -nr

when the OpenVPN server is not running:

pi@raspberrypi:~ $ netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Here are the results of the command

netstat -nr

when the OpenVPN server is running and the client is connected:

root@raspberrypi:/home/pi# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG        0 0          0 tun0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun1
[my-public-ip]    192.168.0.1     255.255.255.255 UGH       0 0          0 eth0
128.0.0.0       10.8.0.1        128.0.0.0       UG        0 0          0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

Based on what is said on the HOWTO, I take it the issue of all websites timing out and not loading has to do with client traffic being routed through the VPN tunnel?

TinCanTech

Try ping 8.8.8.8 over the VPN when connected from the client.

jtetra5

TinCanTech wroteTry ping 8.8.8.8 over the VPN when connected from the client.

I did as you recommended, and here was the results (had to cancel the process because it appeared to time out):

root@raspberrypi:/home/pi# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
925 packets transmitted, 0 received, 100% packet loss, time 924005ms

root@raspberrypi:/home/pi#

This makes me wonder if the client indeed connects to the server. However, I seem to get a successful message on both the server and the client side:

root@raspberrypi:/etc/openvpn# openvpn server.conf
Fri Aug 26 11:19:02 2016 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Fri Aug 26 11:19:02 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.08
Fri Aug 26 11:19:02 2016 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Fri Aug 26 11:19:02 2016 Diffie-Hellman initialized with 2048 bit key
Fri Aug 26 11:19:02 2016 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file
Fri Aug 26 11:19:02 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 26 11:19:02 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 26 11:19:02 2016 Socket Buffers: R=[163840->163840] S=[163840->163840]
Fri Aug 26 11:19:02 2016 TUN/TAP device tun0 opened
Fri Aug 26 11:19:02 2016 TUN/TAP TX queue length set to 100
Fri Aug 26 11:19:02 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Aug 26 11:19:02 2016 /sbin/ip link set dev tun0 up mtu 1500
Fri Aug 26 11:19:02 2016 /sbin/ip addr add dev tun0 10.8.0.1/24 broadcast 10.8.0.255
Fri Aug 26 11:19:02 2016 GID set to nogroup
Fri Aug 26 11:19:02 2016 UID set to nobody
Fri Aug 26 11:19:02 2016 UDPv4 link local (bound): [undef]
Fri Aug 26 11:19:02 2016 UDPv4 link remote: [undef]
Fri Aug 26 11:19:02 2016 MULTI: multi_init called, r=256 v=256
Fri Aug 26 11:19:02 2016 IFCONFIG POOL: base=10.8.0.2 size=252, ipv6=0
Fri Aug 26 11:19:02 2016 ifconfig_pool_read(), in='client,10.8.0.2', TODO: IPv6
Fri Aug 26 11:19:02 2016 succeeded -> ifconfig_pool_set()
Fri Aug 26 11:19:02 2016 IFCONFIG POOL LIST
Fri Aug 26 11:19:02 2016 client,10.8.0.2
Fri Aug 26 11:19:02 2016 Initialization Sequence Completed

And the client:

root@raspberrypi:~# openvpn client.ovpn
Fri Aug 26 11:19:13 2016 Unrecognized option or missing parameter(s) in client.ovpn:14: block-outside-dns (2.3.4)
Fri Aug 26 11:19:13 2016 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Fri Aug 26 11:19:13 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.08
Fri Aug 26 11:19:13 2016 Control Channel Authentication: tls-auth using INLINE static key file
Fri Aug 26 11:19:13 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 26 11:19:13 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 26 11:19:13 2016 Socket Buffers: R=[163840->163840] S=[163840->163840]
Fri Aug 26 11:19:13 2016 UDPv4 link local: [undef]
Fri Aug 26 11:19:13 2016 UDPv4 link remote: [AF_INET][[my-public-ip]:1194
Fri Aug 26 11:19:13 2016 TLS: Initial packet from [AF_INET][my-public-ip]:1194, sid=b6657b3a 45cd6c17
Fri Aug 26 11:19:13 2016 VERIFY OK: depth=1, CN=ChangeMe
Fri Aug 26 11:19:13 2016 Validating certificate key usage
Fri Aug 26 11:19:13 2016 ++ Certificate has key usage  00a0, expects 00a0
Fri Aug 26 11:19:13 2016 VERIFY KU OK
Fri Aug 26 11:19:13 2016 Validating certificate extended key usage
Fri Aug 26 11:19:13 2016 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Fri Aug 26 11:19:13 2016 VERIFY EKU OK
Fri Aug 26 11:19:13 2016 VERIFY OK: depth=0, CN=server
Fri Aug 26 11:19:13 2016 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Fri Aug 26 11:19:13 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 26 11:19:13 2016 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key
Fri Aug 26 11:19:13 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Fri Aug 26 11:19:13 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Fri Aug 26 11:19:13 2016 [server] Peer Connection Initiated with [AF_INET][my-public-ip]:1194
Fri Aug 26 11:19:16 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Fri Aug 26 11:19:16 2016 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 209.18.47.61,dhcp-option DNS 209.18.47.62,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0'
Fri Aug 26 11:19:16 2016 OPTIONS IMPORT: timers and/or timeouts modified
Fri Aug 26 11:19:16 2016 OPTIONS IMPORT: --ifconfig/up options modified
Fri Aug 26 11:19:16 2016 OPTIONS IMPORT: route options modified
Fri Aug 26 11:19:16 2016 OPTIONS IMPORT: route-related options modified
Fri Aug 26 11:19:16 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Aug 26 11:19:16 2016 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:1c:cb:ba
Fri Aug 26 11:19:16 2016 TUN/TAP device tun1 opened
Fri Aug 26 11:19:16 2016 TUN/TAP TX queue length set to 100
Fri Aug 26 11:19:16 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Fri Aug 26 11:19:16 2016 /sbin/ip link set dev tun1 up mtu 1500
Fri Aug 26 11:19:16 2016 /sbin/ip addr add dev tun1 10.8.0.2/24 broadcast 10.8.0.255
Fri Aug 26 11:19:16 2016 /sbin/ip route add [my-public-ip]/32 via 192.168.0.1
Fri Aug 26 11:19:16 2016 /sbin/ip route add 0.0.0.0/1 via 10.8.0.1
Fri Aug 26 11:19:16 2016 /sbin/ip route add 128.0.0.0/1 via 10.8.0.1
Fri Aug 26 11:19:16 2016 Initialization Sequence Completed

I've read that if you can ping 8.8.8.8 it is a DNS problem, but if you can't then the client is not actually connecting to the server properly, but it appears to have done so, although I could be wrong...

TinCanTech

jtetra5 wroteThis makes me wonder if the client indeed connects to the server

Your client log shows you are connected to the server. FYI: Your server log does not show the client connection, probably because you copy/pasted it before you tried to connect ..

jtetra5 wroteI've read that if you can ping 8.8.8.8 it is a DNS problem, but if you can't then the ...

If you can ping 8.8.8.8 but not google.com then it is a DNS related problem .. if you can not ping 8.8.8.8 then you have done something else wrong, most likely you have not setup iptables nat correctly or have not made it permanent and then rebooted your server and lost your setting.

But your VPN is working .. so you are almost there. 😃

Work thru the HOWTO again:
HOWTO: Routing all client traffic (including web-traffic) through the VPN
* Carefully *

Also,

NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.

:arrow: Never use 192.168.0.0/24 or 192.168.1.0/24 (or other common subnets) for your OpenVPN Server LAN :!:

You are advised to change your server LAN to a more unique RFC1918 compliant subnet. f.e 192.168.143.0/24

:arrow: Also, ensure IP forwarding is enabled on your server.

jtetra5

Routing all client traffic (including web-traffic) through the VPN
Overview

By default, when an OpenVPN client is active, only network traffic to and from the OpenVPN server site will pass over the VPN. General web browsing, for example, will be accomplished with direct connections that bypass the VPN.

In certain cases this behavior might not be desirable -- you might want a VPN client to tunnel all network traffic through the VPN, including general internet web browsing. While this type of VPN configuration will exact a performance penalty on the client, it gives the VPN administrator more control over security policies when a client is simultaneously connected to both the public internet and the VPN at the same time.
Implementation

Add the following directive to the server configuration file:

push "redirect-gateway def1"

If your VPN setup is over a wireless network, where all clients and the server are on the same wireless subnet, add the local flag:

push "redirect-gateway local def1"

Pushing the redirect-gateway option to clients will cause all IP network traffic originating on client machines to pass through the OpenVPN server. The server will need to be configured to deal with this traffic somehow, such as by NATing it to the internet, or routing it through the server site's HTTP proxy.

On Linux, you could use a command such as this to NAT the VPN client traffic to the internet:

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

This command assumes that the VPN subnet is 10.8.0.0/24 (taken from the server directive in the OpenVPN server configuration) and that the local ethernet interface is eth0.

When redirect-gateway is used, OpenVPN clients will route DNS queries through the VPN, and the VPN server will need handle them. This can be accomplished by pushing a DNS server address to connecting clients which will replace their normal DNS server settings during the time that the VPN is active. For example:

push "dhcp-option DNS 10.8.0.1"

will configure Windows clients (or non-Windows clients with some extra server-side scripting) to use 10.8.0.1 as their DNS server. Any address which is reachable from clients may be used as the DNS server address.
Caveats

Redirecting all network traffic through the VPN is not entirely a problem-free proposition. Here are some typical gotchas to be aware of:

Many OpenVPN client machines connecting to the internet will periodically interact with a DHCP server to renew their IP address leases. The redirect-gateway option might prevent the client from reaching the local DHCP server (because DHCP messages would be routed over the VPN), causing it to lose its IP address lease.
Issues exist with respect to pushing DNS addresses to Windows clients.
Web browsing performance on the client will be noticably slower.

For more information on the mechanics of the redirect-gateway directive, see the manual page.

I followed the instructions shown above to the tee. I updated my server.conf file:

port 1194
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"
push "dhcp-option DNS 10.8.0.1"
keepalive 10 120
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem

I ran this command once more before restarting the server and client:

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

After starting the server and connecting the client, I was able to miraculously navigate to www.google.com, and then make the following search inquiry: "What is my IPv4?" which furnish actual search engine results! I was so excited! But then, when I went to actually click on the result I wanted to view, it timed out with the same 'Error resolving google.com: Name or service not known'. I really have no explanation for this. The changes I made to server.conf were exactly according to the HOWTO....

TinCanTech

Remove this from your server config:

push "dhcp-option DNS 10.8.0.1"

and restart the server.

Remove this from your client config:

setenv opt block-outside-dns

and try again.

jtetra5

TinCanTech wroteRemove this from your server config:

push "dhcp-option DNS 10.8.0.1"

and restart the server.

Remove this from your client config:

setenv opt block-outside-dns

and try again.

I have made your recommended changes, so that server.conf looks like this:

port 1194
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"
keepalive 10 120
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4
crl-verify crl.pem

And client.ovpn looks like this:

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 24.59.211.11 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-128-CBC
comp-lzo
key-direction 1
verb 4

The same issue occurred, including not being able to ping 8.8.8.8. I have compared my configuration to other set-ups online, and it appears that it is correct...

TinCanTech

jtetra5 wroteThe same issue occurred, including not being able to ping 8.8.8.8

Check your server firewall rules.

Then use tcpdump to figure out where the client pings to 8.8.8.8 are dropped.

jtetra5

TinCanTech wrote
jtetra5 wroteThe same issue occurred, including not being able to ping 8.8.8.8
Check your server firewall rules.

Then use tcpdump to figure out where the client pings to 8.8.8.8 are dropped.

I located the file named firewall-openvpn-rules.sh in /etc, and the contents are as follows:

#!/bin/sh

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to source 192.168.0.2 # my device's IP address

Does this look correct to you?

TinCanTech

It could be correct .. but is it actually executed ?

I would move it to a safe place and then carry on with the official howto.

jtetra5

TinCanTech wroteIt could be correct .. but is it actually executed ?

I would move it to a safe place and then carry on with the official howto.

I entered the following command:

root@raspberrypi:/etc# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

So it looks like there are no firewalls in place...

TinCanTech

As it is the nat table you want to see, you need

iptables -L -t nat

jtetra5

TinCanTech wroteAs it is the nat table you want to see, you need

iptables -L -t nat

I think I may have found the source of this pesky problem. As you can see, all traffic as it stands now gets routed back to 192.168.0.5, which is a non-existent device.

root@raspberrypi:/etc/openvpn# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
SNAT       all  --  10.8.0.0/24          anywhere             to:192.168.0.5
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere

It should be 192.168.0.2! How do I change it to the correct IP?

jtetra5

Okay, I completely uninstalled OpenVPN and everything associated with it. I reinstalled it and followed the HOWTO, to the tee, no pun intended, to set everything up. Both the good news and the bad, is that I got myself to the same point that I did with the OpenVPN I installed via GitHub, that is, I can connect the client to the server, but I can't surf the web. I will now post both the server and the client configuration files, taken directly from the HOWTO (I deleted the comments to shorten it):

server.conf

port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ip.text
push "redirect-gateway-def1"
push "dhcp-option DNS 10.8.0.1"
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3

And client.conf

client
dev tun
proto udp
remote [my-public-ip] 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/client1.crt
key /etc/openvpn/easy-rsa/keys/client1.key
ns-cert-type server
comp-lzo
verb 3

After starting the server and connecting the client, this is what the server end looks like:

root@raspberrypi:/usr/share/doc/openvpn/examples/sample-config-files# openvpn server.conf
Sat Aug 27 19:06:02 2016 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Sat Aug 27 19:06:02 2016 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Sat Aug 27 19:06:02 2016 NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x.  Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.
Sat Aug 27 19:06:02 2016 Diffie-Hellman initialized with 2048 bit key
Sat Aug 27 19:06:02 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sat Aug 27 19:06:02 2016 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:1c:cb:ba
Sat Aug 27 19:06:02 2016 TUN/TAP device tun0 opened
Sat Aug 27 19:06:02 2016 TUN/TAP TX queue length set to 100
Sat Aug 27 19:06:02 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Aug 27 19:06:02 2016 /sbin/ip link set dev tun0 up mtu 1500
Sat Aug 27 19:06:02 2016 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Sat Aug 27 19:06:02 2016 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Sat Aug 27 19:06:02 2016 GID set to nogroup
Sat Aug 27 19:06:02 2016 UID set to nobody
Sat Aug 27 19:06:02 2016 UDPv4 link local (bound): [undef]
Sat Aug 27 19:06:02 2016 UDPv4 link remote: [undef]
Sat Aug 27 19:06:02 2016 MULTI: multi_init called, r=256 v=256
Sat Aug 27 19:06:02 2016 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Sat Aug 27 19:06:02 2016 ifconfig_pool_read(), in='client1,10.8.0.4', TODO: IPv6
Sat Aug 27 19:06:02 2016 succeeded -> ifconfig_pool_set()
Sat Aug 27 19:06:02 2016 IFCONFIG POOL LIST
Sat Aug 27 19:06:02 2016 client1,10.8.0.4
Sat Aug 27 19:06:02 2016 Initialization Sequence Completed
Sat Aug 27 19:07:07 2016 [my-public-ip]:54836 TLS: Initial packet from [AF_INET][my-public-ip]:54836, sid=c8e4b66a 85fcb73c
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 VERIFY OK: depth=1, C=US, ST=CA, L=Fort-Funston, O=Fort-Funston, OU=MyOrganizationalUnit, CN=OpenVPN, name=EasyRSA, emailAddress=me@myhost.mydomain
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 VERIFY OK: depth=0, C=US, ST=CA, L=Fort-Funston, O=Fort-Funston, OU=MyOrganizationalUnit, CN=client1, name=EasyRSA, emailAddress=me@myhost.mydomain
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Aug 27 19:07:08 2016 [my-public-ip]:54836 [client1] Peer Connection Initiated with [AF_INET][my-public-ip]:54836
Sat Aug 27 19:07:08 2016 client1/[my-public-ip]:54836 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Sat Aug 27 19:07:08 2016 client1/[my-public-ip]:54836 MULTI: Learn: 10.8.0.6 -> client1/[my-public-ip]:54836
Sat Aug 27 19:07:08 2016 client1/[my-public-ip]:54836 MULTI: primary virtual IP for client1/[my-public-ip]:54836: 10.8.0.6
Sat Aug 27 19:07:10 2016 client1/[my-public-ip]:54836 PUSH: Received control message: 'PUSH_REQUEST'
Sat Aug 27 19:07:10 2016 client1/[my-public-ip]:54836 send_push_reply(): safe_cap=940
Sat Aug 27 19:07:10 2016 client1/[my-public-ip]:54836 SENT CONTROL [client1]: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.8.0.1,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)

And the client end:

root@raspberrypi:/usr/share/doc/openvpn/examples/sample-config-files# openvpn client.conf
Sat Aug 27 19:07:02 2016 OpenVPN 2.3.4 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jan 23 2016
Sat Aug 27 19:07:02 2016 library versions: OpenSSL 1.0.1k 8 Jan 2015, LZO 2.08
Enter Private Key Password: *********
Sat Aug 27 19:07:07 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sat Aug 27 19:07:07 2016 Socket Buffers: R=[163840->131072] S=[163840->131072]
Sat Aug 27 19:07:07 2016 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Sat Aug 27 19:07:07 2016 UDPv4 link local: [undef]
Sat Aug 27 19:07:07 2016 UDPv4 link remote: [AF_INET][my-public-ip]:1194
Sat Aug 27 19:07:07 2016 TLS: Initial packet from [AF_INET][my-public-ip]:1194, sid=62e38e4f 9d3791fa
Sat Aug 27 19:07:08 2016 VERIFY OK: depth=1, C=US, ST=CA, L=Fort-Funston, O=Fort-Funston, OU=MyOrganizationalUnit, CN=OpenVPN, name=EasyRSA, emailAddress=me@myhost.mydomain
Sat Aug 27 19:07:08 2016 VERIFY OK: nsCertType=SERVER
Sat Aug 27 19:07:08 2016 VERIFY OK: depth=0, C=US, ST=CA, L=Fort-Funston, O=Fort-Funston, OU=MyOrganizationalUnit, CN=server, name=EasyRSA, emailAddress=me@myhost.mydomain
Sat Aug 27 19:07:08 2016 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 27 19:07:08 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 27 19:07:08 2016 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Aug 27 19:07:08 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Aug 27 19:07:08 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Aug 27 19:07:08 2016 [server] Peer Connection Initiated with [AF_INET][my-public-ip]:1194
Sat Aug 27 19:07:10 2016 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sat Aug 27 19:07:10 2016 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 10.8.0.1,route 10.8.0.0 255.255.255.0,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Sat Aug 27 19:07:10 2016 OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 27 19:07:10 2016 OPTIONS IMPORT: --ifconfig/up options modified
Sat Aug 27 19:07:10 2016 OPTIONS IMPORT: route options modified
Sat Aug 27 19:07:10 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Aug 27 19:07:10 2016 ROUTE_GATEWAY 192.168.0.1/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:1c:cb:ba
Sat Aug 27 19:07:10 2016 TUN/TAP device tun1 opened
Sat Aug 27 19:07:10 2016 TUN/TAP TX queue length set to 100
Sat Aug 27 19:07:10 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Aug 27 19:07:10 2016 /sbin/ip link set dev tun1 up mtu 1500
Sat Aug 27 19:07:10 2016 /sbin/ip addr add dev tun1 local 10.8.0.6 peer 10.8.0.5
Sat Aug 27 19:07:10 2016 /sbin/ip route add [my-public-ip]/32 via 192.168.0.1
RTNETLINK answers: File exists
Sat Aug 27 19:07:10 2016 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Aug 27 19:07:10 2016 /sbin/ip route add 0.0.0.0/1 via 10.8.0.5
Sat Aug 27 19:07:10 2016 /sbin/ip route add 128.0.0.0/1 via 10.8.0.5
Sat Aug 27 19:07:10 2016 /sbin/ip route add 10.8.0.0/24 via 10.8.0.5
RTNETLINK answers: File exists
Sat Aug 27 19:07:10 2016 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Aug 27 19:07:10 2016 GID set to nogroup
Sat Aug 27 19:07:10 2016 UID set to nobody
Sat Aug 27 19:07:10 2016 Initialization Sequence Completed

This is the result of ifconfig while everything is connected:

root@raspberrypi:/home/pi# ifconfig
eth0      Link encap:Ethernet  HWaddr b8:27:eb:1c:cb:ba  
          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::6a9a:7646:96c:9f2/64 Scope:Link
          inet6 addr: 2604:6000:a200:4500:b569:7894:b2b0:c32b/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:89770 errors:0 dropped:16379 overruns:0 frame:0
          TX packets:74897 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:17289834 (16.4 MiB)  TX bytes:11155554 (10.6 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1444 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1444 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:138858 (135.6 KiB)  TX bytes:138858 (135.6 KiB)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.1  P-t-P:10.8.0.2  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:33 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:2508 (2.4 KiB)  TX bytes:0 (0.0 B)

tun1      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.8.0.6  P-t-P:10.8.0.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:74 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:6360 (6.2 KiB)

wlan0     Link encap:Ethernet  HWaddr b8:27:eb:49:9e:ef  
          inet6 addr: fe80::8870:2834:ec34:f063/64 Scope:Link
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:14929 errors:0 dropped:14929 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6803593 (6.4 MiB)  TX bytes:0 (0.0 B)

And also iptables -L -t nat:

root@raspberrypi:/home/pi# iptables -L -t nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere            
MASQUERADE  all  --  10.8.0.0/24          anywhere

At this point, the only thing I can think of is, maybe it has to do with the fact that this client is on the same machine as the server (Raspberry Pi 3)? Other than that, I have no idea why I cannot surf the web while connected...

jtetra5

Still having the same issue; the client successfully connects to the server, but I cannot surf the web. Additionally, I get the following output on the server end, which repeats itself until I close the connection down:

Sat Sep  3 15:59:09 2016 us=957683 client1/[my-public-ip]:48158 MULTI: bad source address from client [192.168.0.2], packet dropped

Here is the firewall.sh file that is found in /usr/share/doc/openvpn/examples/sample-config-files:

#!/bin/sh

# A Sample OpenVPN-aware firewall.

# eth0 is connected to the internet.
# eth1 is connected to a private subnet.

# Change this subnet to correspond to your private
# ethernet subnet.  Home will use HOME_NET/24 and
# Office will use OFFICE_NET/24.
PRIVATE=10.0.0.0/24

# Loopback address
LOOP=127.0.0.1

# Delete old iptables rules
# and temporarily block all traffic.
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -F

# Set default policies
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Prevent external packets from using loopback addr
iptables -A INPUT -i eth0 -s $LOOP -j DROP
iptables -A FORWARD -i eth0 -s $LOOP -j DROP
iptables -A INPUT -i eth0 -d $LOOP -j DROP
iptables -A FORWARD -i eth0 -d $LOOP -j DROP

# Anything coming from the Internet should have a real Internet address
iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A FORWARD -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP

# Block outgoing NetBios (if you have windows machines running
# on the private subnet).  This will not affect any NetBios
# traffic that flows over the VPN tunnel, but it will stop
# local windows machines from broadcasting themselves to
# the internet.
iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP

# Check source address validity on packets going out to internet
iptables -A FORWARD -s ! $PRIVATE -i eth1 -j DROP

# Allow local loopback
iptables -A INPUT -s $LOOP -j ACCEPT
iptables -A INPUT -d $LOOP -j ACCEPT

# Allow incoming pings (can be disabled)
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Allow services such as www and ssh (can be disabled)
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

# Allow incoming OpenVPN packets
# Duplicate the line below for each
# OpenVPN tunnel, changing --dport n
# to match the OpenVPN UDP port.
#
# In OpenVPN, the port number is
# controlled by the --port n option.
# If you put this option in the config
# file, you can remove the leading '--'
#
# If you taking the stateful firewall
# approach (see the OpenVPN HOWTO),
# then comment out the line below.

iptables -A INPUT -p udp --dport 1194 -j ACCEPT

# Allow packets from TUN/TAP devices.
# When OpenVPN is run in a secure mode,
# it will authenticate packets prior
# to their arriving on a tun or tap
# interface.  Therefore, it is not
# necessary to add any filters here,
# unless you want to restrict the
# type of packets which can flow over
# the tunnel.

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

# Allow packets from private subnets
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -j ACCEPT

# Keep state of connections from local machine and private subnets
iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Masquerade local subnet
iptables -t nat -A POSTROUTING -s $PRIVATE -o eth0 -j MASQUERADE

jtetra5

jtetra5 wroteStill having the same issue; the client successfully connects to the server, but I cannot surf the web. Additionally, I get the following output on the server end, which repeats itself until I close the connection down:

Sat Sep  3 15:59:09 2016 us=957683 client1/[my-public-ip]:48158 MULTI: bad source address from client [192.168.0.2], packet dropped

Here is the firewall.sh file that is found in /usr/share/doc/openvpn/examples/sample-config-files:

#!/bin/sh

# A Sample OpenVPN-aware firewall.

# eth0 is connected to the internet.
# eth1 is connected to a private subnet.

# Change this subnet to correspond to your private
# ethernet subnet.  Home will use HOME_NET/24 and
# Office will use OFFICE_NET/24.
PRIVATE=10.0.0.0/24

# Loopback address
LOOP=127.0.0.1

# Delete old iptables rules
# and temporarily block all traffic.
iptables -P OUTPUT DROP
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -F

# Set default policies
iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Prevent external packets from using loopback addr
iptables -A INPUT -i eth0 -s $LOOP -j DROP
iptables -A FORWARD -i eth0 -s $LOOP -j DROP
iptables -A INPUT -i eth0 -d $LOOP -j DROP
iptables -A FORWARD -i eth0 -d $LOOP -j DROP

# Anything coming from the Internet should have a real Internet address
iptables -A FORWARD -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A FORWARD -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A FORWARD -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP

# Block outgoing NetBios (if you have windows machines running
# on the private subnet).  This will not affect any NetBios
# traffic that flows over the VPN tunnel, but it will stop
# local windows machines from broadcasting themselves to
# the internet.
iptables -A FORWARD -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A FORWARD -p udp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p tcp --sport 137:139 -o eth0 -j DROP
iptables -A OUTPUT -p udp --sport 137:139 -o eth0 -j DROP

# Check source address validity on packets going out to internet
iptables -A FORWARD -s ! $PRIVATE -i eth1 -j DROP

# Allow local loopback
iptables -A INPUT -s $LOOP -j ACCEPT
iptables -A INPUT -d $LOOP -j ACCEPT

# Allow incoming pings (can be disabled)
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Allow services such as www and ssh (can be disabled)
iptables -A INPUT -p tcp --dport http -j ACCEPT
iptables -A INPUT -p tcp --dport ssh -j ACCEPT

# Allow incoming OpenVPN packets
# Duplicate the line below for each
# OpenVPN tunnel, changing --dport n
# to match the OpenVPN UDP port.
#
# In OpenVPN, the port number is
# controlled by the --port n option.
# If you put this option in the config
# file, you can remove the leading '--'
#
# If you taking the stateful firewall
# approach (see the OpenVPN HOWTO),
# then comment out the line below.

iptables -A INPUT -p udp --dport 1194 -j ACCEPT

# Allow packets from TUN/TAP devices.
# When OpenVPN is run in a secure mode,
# it will authenticate packets prior
# to their arriving on a tun or tap
# interface.  Therefore, it is not
# necessary to add any filters here,
# unless you want to restrict the
# type of packets which can flow over
# the tunnel.

iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

# Allow packets from private subnets
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A FORWARD -i eth1 -j ACCEPT

# Keep state of connections from local machine and private subnets
iptables -A OUTPUT -m state --state NEW -o eth0 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state NEW -o eth0 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# Masquerade local subnet
iptables -t nat -A POSTROUTING -s $PRIVATE -o eth0 -j MASQUERADE

Here is the Kernel IP Routing Table while the server is running and the client is connected:

root@raspberrypi:/home/pi# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.5        128.0.0.0       UG    0      0        0 tun1
0.0.0.0         192.168.0.1     0.0.0.0         UG    202    0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.8.0.1        10.8.0.5        255.255.255.255 UGH   0      0        0 tun1
10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.8.0.5        0.0.0.0         255.255.255.255 UH    0      0        0 tun1
[my-public-ip]    192.168.0.1     255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.0.5        128.0.0.0       UG    0      0        0 tun1
192.168.0.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0

TinCanTech

jtetra5 wroteAt this point, the only thing I can think of is, maybe it has to do with the fact that this client is on the same machine as the server

That will be the reason ..