[Solved] OpenVPN - Can only connect to server

universal · 2018-04-28 21:46:13

Hey everyone,

I decided to setup my own OpenVPN server, so I got a vserver which is running Debian 7 with OpenVPN 2.2.1 (Old but should be compatible).

When I connect to the server this is the output of OpenVPN (full log):

Sat Apr 28 22:57:00 2018 OpenVPN 2.4.6 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 24 2018
Sat Apr 28 22:57:00 2018 library versions: OpenSSL 1.1.0h  27 Mar 2018, LZO 2.10
Sat Apr 28 22:57:03 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]{Server IP}:1194
Sat Apr 28 22:57:03 2018 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 28 22:57:03 2018 UDP link local: (not bound)
Sat Apr 28 22:57:03 2018 UDP link remote: [AF_INET]{Server IP}:1194
Sat Apr 28 22:57:03 2018 TLS: Initial packet from [AF_INET]{Server IP}:1194, sid=03827789 88708f23
Sat Apr 28 22:57:04 2018 Control Channel: TLSv1, cipher SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Apr 28 22:57:04 2018 [changeme] Peer Connection Initiated with [AF_INET]{Server IP}:1194
Sat Apr 28 22:57:05 2018 SENT CONTROL [changeme]: 'PUSH_REQUEST' (status=1)
Sat Apr 28 22:57:05 2018 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1 bypass-dhcp,dhcp-option DNS 8.8.8.8,dhcp-option DNS 8.8.4.4,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5'
Sat Apr 28 22:57:05 2018 Outgoing Data Channel: Cipher 'BF-CBC' initialized with 128 bit key
Sat Apr 28 22:57:05 2018 ROUTE_GATEWAY 192.168.2.1/255.255.255.0 IFACE=enp5s0 HWADDR=4c:cc:6a:0d:2f:3e
Sat Apr 28 22:57:05 2018 TUN/TAP device tun0 opened
Sat Apr 28 22:57:05 2018 TUN/TAP TX queue length set to 100
Sat Apr 28 22:57:05 2018 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Apr 28 22:57:05 2018 /usr/bin/ip link set dev tun0 up mtu 1500
Sat Apr 28 22:57:05 2018 /usr/bin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5
Sat Apr 28 22:57:05 2018 /usr/bin/ip route add {Server IP}/32 via 192.168.2.1
Sat Apr 28 22:57:05 2018 /usr/bin/ip route add 0.0.0.0/1 via 10.8.0.5
Sat Apr 28 22:57:05 2018 /usr/bin/ip route add 128.0.0.0/1 via 10.8.0.5
Sat Apr 28 22:57:05 2018 /usr/bin/ip route add 10.8.0.1/32 via 10.8.0.5
Sat Apr 28 22:57:05 2018 Initialization Sequence Completed
# Then I pressed CTRL+C
Sat Apr 28 22:57:25 2018 SIGINT[hard,] received, process exiting

The connection is successful, but if I try to ping anything I get no response:

usr@arch $ ping startpage.com                                                                                                                                                                                                            
PING startpage.com (37.0.87.47) 56(84) bytes of data.
^C
--- startpage.com ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

As you can see resolving the domain is not an issue so I guess DNS stuff is more or less working.

Some other information:

ip route and ip addr, before connection:

$ ip route
default via 192.168.2.1 dev enp5s0 proto dhcp src 192.168.2.130 metric 202 
192.168.2.0/24 dev enp5s0 proto kernel scope link src 192.168.2.133 metric 100 
192.168.2.0/24 dev enp5s0 proto kernel scope link src 192.168.2.130 metric 100 
192.168.2.0/24 dev enp5s0 proto dhcp scope link src 192.168.2.130 metric 202

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    [...]
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4c:cc:6a:0d:2f:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.133/24 brd 192.168.2.255 scope global dynamic noprefixroute enp5s0
       valid_lft 83947sec preferred_lft 83947sec
    inet 192.168.2.130/24 brd 192.168.2.255 scope global secondary noprefixroute enp5s0
       valid_lft forever preferred_lft forever
    inet6 fe80::77d2:8453:462c:d42a/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::16dd:e3c:4cd5:369b/64 scope link 
       valid_lft forever preferred_lft forever

after connection:

$ ip route
0.0.0.0/1 via 10.8.0.5 dev tun0 
default via 192.168.2.1 dev enp5s0 proto dhcp src 192.168.2.130 metric 202 
10.8.0.1 via 10.8.0.5 dev tun0 
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6 
{Server IP} via 192.168.2.1 dev enp5s0 
128.0.0.0/1 via 10.8.0.5 dev tun0 
192.168.2.0/24 dev enp5s0 proto kernel scope link src 192.168.2.133 metric 100 
192.168.2.0/24 dev enp5s0 proto kernel scope link src 192.168.2.130 metric 100 
192.168.2.0/24 dev enp5s0 proto dhcp scope link src 192.168.2.130 metric 202

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    [...]
2: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 4c:cc:6a:0d:2f:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.133/24 brd 192.168.2.255 scope global dynamic noprefixroute enp5s0
       valid_lft 84049sec preferred_lft 84049sec
    inet 192.168.2.130/24 brd 192.168.2.255 scope global secondary noprefixroute enp5s0
       valid_lft forever preferred_lft forever
    inet6 fe80::77d2:8453:462c:d42a/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::16dd:e3c:4cd5:369b/64 scope link 
       valid_lft forever preferred_lft forever
8: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none 
    inet 10.8.0.6 peer 10.8.0.5/32 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::4420:a9a1:2d0c:a562/64 scope link stable-privacy 
       valid_lft forever preferred_lft forever

cat /etc/resolv.conf

# Generated by resolvconf
nameserver 192.168.2.1

iptables is currently empty, although I found multiple sources online to run the following commands to fix the issue:

# Allow TUN interface connections to OpenVPN server
iptables -A INPUT -i tun+ -j ACCEPT
# Allow TUN interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tun+ -j ACCEPT
# Allow TAP interface connections to OpenVPN server
iptables -A INPUT -i tap+ -j ACCEPT
# Allow TAP interface connections to be forwarded through other interfaces
iptables -A FORWARD -i tap+ -j ACCEPT

The frustrating thing is that I had it working yesterday and even a couple of times today, but only after fiddling around for hours.
Then when I got it working I wasn't sure which method was the reason it started to work, so after rebooting I lost my progress.
And now I'm at the point where I can't get it to work at all anymore.

I'm pretty sure that iptables needs some additional configuring but I have no clue what to do. The method above was something I
tried but on its own it's not enough to get it working again. Also because I had it working a couple of times I'm pretty sure that
my server configuration is correct.

Still here's the server configurations:
iptables
/etc/openvpn/server.conf/

So yeah long story short I'm frustrated, because I got it working and now it doesn't anymore so any help is highly appreciated.
Thanks in advance!

(Also I wasn't sure whether to put this in Networking, Server, and Protection or in the Newbie Corner, but while searching the former already had some topics like this one)

Last edited by universal (2018-04-29 22:20:52)

universal · 2018-04-29 19:10:52

I might've found a solution for the issue. As it seems it was the firewall blocking the connection.
I found a post on superuse which used the following commands to clear all rules:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

I thought, that I didn't have any rules in iptables but as it seems I did.
So I was able to connect successfully, but it also seems like the server provider
is down right now (oops ), so I'll see if this really fixed it.

I also tried switching from tun to tap, which resulted in the following error when pining:

$ ping google.de
PING google.de (172.217.16.163) 56(84) bytes of data.
From arch (10.8.0.4) icmp_seq=1 Destination Host Unreachable
From arch (10.8.0.4) icmp_seq=2 Destination Host Unreachable
From arch (10.8.0.4) icmp_seq=3 Destination Host Unreachable

Which is at least a little more info.

So yeah I'll update this once I can connect to the vserver again.
Edit: Looks like it's working now. Also apparently NetworkManager was
causing the misconfiguration, because when I used NM to connect
it stopped working again.

Last edited by universal (2018-04-29 22:20:36)

Arch Linux

#1 2018-04-28 21:46:13

[Solved] OpenVPN - Can only connect to server

#2 2018-04-29 19:10:52

Re: [Solved] OpenVPN - Can only connect to server

Board footer