1

I am using openvpn. I can connect to the server as a client without hiccups but I can't use the internet. Here's how the config file looks like on the server:

**The server is a Raspberry Pi in my home network and the client is my main computer, also in my home network.

Main computer running Debian Buster w/ Gnome

Raspberry Pi running Raspbian

port 1194
proto udp4
dev tun
ca ca.crt
cert servervpn.crt
key servervpn.key
dh dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
key-direction 0
cipher AES-256-CBC
auth SHA256
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1

This is the output of "sudo openvpn servervpn.conf"

$ sudo openvpn servervpn.conf
Sat Jan 12 21:35:45 2019 OpenVPN 2.4.0 arm-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Sat Jan 12 21:35:45 2019 library versions: OpenSSL 1.0.2q  20 Nov 2018, LZO 2.08
Sat Jan 12 21:35:45 2019 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 Jan 12 21:35:45 2019 Diffie-Hellman initialized with 2048 bit key
Sat Jan 12 21:35:45 2019 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Jan 12 21:35:45 2019 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Sat Jan 12 21:35:45 2019 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=eth0 HWADDR=b8:27:eb:c4:c6:49
Sat Jan 12 21:35:45 2019 TUN/TAP device tun0 opened
Sat Jan 12 21:35:45 2019 TUN/TAP TX queue length set to 100
Sat Jan 12 21:35:45 2019 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Jan 12 21:35:45 2019 /sbin/ip link set dev tun0 up mtu 1500
Sat Jan 12 21:35:45 2019 /sbin/ip addr add dev tun0 local 10.8.0.1 peer 10.8.0.2
Sat Jan 12 21:35:45 2019 /sbin/ip route add 10.8.0.0/24 via 10.8.0.2
Sat Jan 12 21:35:45 2019 Socket Buffers: R=[163840->163840] S=[163840->163840]
Sat Jan 12 21:35:45 2019 UDPv4 link local (bound): [AF_INET][undef]:1194
Sat Jan 12 21:35:45 2019 UDPv4 link remote: [AF_UNSPEC]
Sat Jan 12 21:35:45 2019 GID set to nogroup
Sat Jan 12 21:35:45 2019 UID set to nobody
Sat Jan 12 21:35:45 2019 MULTI: multi_init called, r=256 v=256
Sat Jan 12 21:35:45 2019 IFCONFIG POOL: base=10.8.0.4 size=62, ipv6=0
Sat Jan 12 21:35:45 2019 ifconfig_pool_read(), in='totothetoro,10.8.0.4', TODO: IPv6
Sat Jan 12 21:35:45 2019 succeeded -> ifconfig_pool_set()
Sat Jan 12 21:35:45 2019 IFCONFIG POOL LIST
Sat Jan 12 21:35:45 2019 anotherdeb,10.8.0.4
Sat Jan 12 21:35:45 2019 Initialization Sequence Completed

Here's how the client file looks like:

client
dev tun
proto udp4
remote mydomain.net 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA256
key-direction 1
verb 3
script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
<ca>
stuff
</ca>
<cert>
more stuff
</cert>
<key>
guess what?
</key>
<tls-auth>
oh yeah, more stuff
</tls-auth>

When I connect the client to the server this is what I see in addition to what "sudo openvpn servervpn.conf" already outputs:

Sat Jan 12 21:48:29 2019 X.X.X.X:36283 TLS: Initial packet from [AF_INET]X.X.X.X:36283, sid=ad84ab34 82ec9433
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 VERIFY OK: depth=1, C=US, ST=NY, L=New York City, O=Fort-Funston, OU=Comm, CN=Fort-Funston CA, name=servervpn, emailAddress=me@me.me
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 VERIFY OK: depth=0, C=US, ST=NY, L=New York City, O=Fort-Funston, OU=Comm, CN=superkitty, name=server, emailAddress=me@me.me
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_VER=2.4.6
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_PLAT=linux
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_PROTO=2
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_NCP=2
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_LZ4=1
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_LZ4v2=1
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_LZO=1
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_COMP_STUB=1
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_COMP_STUBv2=1
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 peer info: IV_TCPNL=1
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sat Jan 12 21:48:29 2019 X.X.X.X:36283 [superkitty] Peer Connection Initiated with [AF_INET]X.X.X.X:36283
Sat Jan 12 21:48:29 2019 superkitty/X.X.X.X:36283 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled)
Sat Jan 12 21:48:29 2019 superkitty/X.X.X.X:36283 MULTI: Learn: 10.8.0.6 -> superkitty/X.X.X.X:36283
Sat Jan 12 21:48:29 2019 superkitty/X.X.X.X:36283 MULTI: primary virtual IP for superkitty/X.X.X.X:36283: 10.8.0.6
Sat Jan 12 21:48:30 2019 superkitty/X.X.X.X:36283 PUSH: Received control message: 'PUSH_REQUEST'
Sat Jan 12 21:48:30 2019 superkitty/X.X.X.X:36283 SENT CONTROL [superkitty]: 'PUSH_REPLY,dhcp-option DNS 208.67.222.222,dhcp-option DNS 208.67.220.220,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5,peer-id 0,cipher AES-256-GCM' (status=1)
Sat Jan 12 21:48:30 2019 superkitty/X.X.X.X:36283 Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Sat Jan 12 21:48:30 2019 superkitty/X.X.X.X:36283 Data Channel Decrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

closed as unclear what you're asking by Rui F Ribeiro, Thomas, RalfFriedl, Mr Shunz, Networker Jan 14 at 8:43

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • If your client is on the same LAN as the server it's quite likely the routing tables are getting confused. Have you got a MASQUERADE (or SNAT) rule on your server for traffic from the VPN that's outbound to the rest of the world? (If not, you'll need one in this scenario.) – roaima Jan 13 at 14:44
  • I haven't*. I haven't set anything like that up so the answer is most likely no. How would I go about doing that? Any sites or tutorials you recommend? Why are the routing tables getting confused? – superkitty Jan 13 at 18:52