2

I’m attempting to setup OpenVPN on our server. The server is running Centos 7. After installing and configuring OpenVPN I can successfully connect from a Windows 10 client. But once connected I cannot access the internet. I also cannot ping the host server. Not related to OpenVPN, my server also uses KVM running multiple VM’s on a virtual network. I can also not ping the VM's when connected.

Host connection: 192.168.1.10
VPN network: 10.8.0.0
Virtual network: 10.8.8.0

I confirmed IP forwarding is enabled. I also updated Iptables with:

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

I listed below the OpenVPN server.conf and Ifconfig info.

I've been struggling with this for a week. At this point I'm stuck and not sure what to look at next. Any ideas?

OpenVPN server.conf:

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem

ifconfig-pool-persist ipp.txt

server 10.8.0.0 255.255.255.0
push "route 192.168.1.10 255.255.255.255"
push "route 10.8.8.0 255.255.255.0"

push "redirect-gateway def1"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

keepalive 10 120
user nobody
group nobody

persist-key
persist-tun

status openvpn-status.log
verb 3
client-to-client

explicit-exit-notify 1

Ifconfig:

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.10  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::3bcd:ddd4:4650:6087  prefixlen 64  scopeid 0x20<link>
        ether ac:1f:6b:05:cc:96  txqueuelen 1000  (Ethernet)
        RX packets 454678  bytes 136137391 (129.8 MiB)
        RX errors 36  dropped 37074  overruns 0  frame 36
        TX packets 213347  bytes 80743075 (77.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 91899  bytes 50703642 (48.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 91899  bytes 50703642 (48.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.255  destination 10.8.0.2
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.8.8.1  netmask 255.255.255.0  broadcast 10.8.8.255
        ether 52:54:00:34:2a:4d  txqueuelen 1000  (Ethernet)
        RX packets 2663  bytes 193301 (188.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2582  bytes 226983 (221.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fc54:ff:fe6e:e2f  prefixlen 64  scopeid 0x20<link>
        ether fe:54:00:6e:0e:2f  txqueuelen 1000  (Ethernet)
        RX packets 2663  bytes 230583 (225.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 141674  bytes 7459999 (7.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Update regarding accessing the VM's from a VPN connection:

When the libvirtd virtual bridge starts, iptables need to be modified to route VPN traffic to the VM's. Executing the following two firewall-cmd commands will manually insert the required rules. This will need to be done if firewall-cmd --reload, or any other command that restores firewalld rules, is executed.

Assumptions:

  • Virtual network device created for KVM is named virbr0 with subnet of 10.10.0.0/20 (adjust here and below as needed if virtual network was created under different device name).

  • OpenVPN device is named tun0 with subnet of 10.8.0.0/24

    firewall-cmd --direct --passthrough ipv4 -I FORWARD 3 -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT
    firewall-cmd --direct --passthrough ipv4 -I FORWARD 4 -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT
    

Verify entries by executing iptables -t filter -S your should see the following amongst all the rules listed:

-A FORWARD -d 10.10.0.0/20 -i bridge0 -o virbr0 -j ACCEPT
-A FORWARD -s 10.10.0.0/20 -i virbr0 -o bridge0 -j ACCEPT
-A FORWARD -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT
-A FORWARD -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT

Note: The previous two firewall-cmd commands that were executed added the 3rd and 4th lines shown.

If needed, executing the following two firewall-cmd commands will manually remove the inserted rules.

    firewall-cmd --direct --passthrough ipv4 -D FORWARD -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT
    firewall-cmd --direct --passthrough ipv4 -D FORWARD -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT

Verify entries by executing iptables -t filter -S your should see the following amongst all the rules listed:

-A FORWARD -d 10.10.0.0/20 -i bridge0 -o virbr0 -j ACCEPT
-A FORWARD -s 10.10.0.0/20 -i virbr0 -o bridge0 -j ACCEPT

Note: The previous two firewall-cmd commands that were executed removed the 3rd and 4th lines that were shown above.

Issue: The libvirtd service will overwrite the rules added above on boot or restart. To get around this, add the following two libvirt scripts.

Script # 1: On start or reconnection of any VM associated with virbr0 (this will also execute on boot or by executing systemctl start libvirtd):

vi /etc/libvirt/hooks/qemu and insert the following:

    #!/bin/bash

    # Only execute this script if the opennebula-controller VM is started or reconnected
    if [ "${1}" = "opennebula-controller=" ] ; then

        # Check if vpn input routing rule exists. If not add it.
        iptables -C FORWARD -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT > /dev/null 2>&1
        if [ $? = 1 ] ; then
            if [ "${2}" = "started" ] || [ "${2}" = "reconnect" ]; then
                firewall-cmd --direct --passthrough ipv4 -I FORWARD 3 -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT
            fi
        fi

        # Check if vpn output routing rule exists. If not add it.
        iptables -C FORWARD -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT > /dev/null 2>&1
        if [ $? = 1 ] ; then
            if [ "${2}" = "started" ] || [ "${2}" = "reconnect"  ]; then
                firewall-cmd --direct --passthrough ipv4 -I FORWARD 4 -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT
            fi
        fi

    fi

Write and close

Script # 2: On stop of the libvirtd daemon (this removes the rules so that on restart or by executing systemctl stop libvirtd, duplicate rules will not be inserted)

vi /etc/libvirt/hooks/daemon and insert the following:

    #!/bin/bash

    # Check if vpn input routing rule exists. If it does, remove it.
    iptables -C FORWARD -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT > /dev/null 2>&1
        if [ $? = 0 ] ; then
            if [ "${2}" = "shutdown" ]; then
                firewall-cmd --direct --passthrough ipv4 -D FORWARD -d 10.10.0.0/20 -i tun0 -o virbr0 -j ACCEPT
            fi
        fi

    # Check if vpn output routing rule exists. If it does, remove it.
    iptables -C FORWARD -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT > /dev/null 2>&1
        if [ $? = 0 ] ; then
            if [ "${2}" = "shutdown" ]; then
                firewall-cmd --direct --passthrough ipv4 -D FORWARD -s 10.10.0.0/20 -i virbr0 -o tun0 -j ACCEPT
            fi
        fi

Write and close

  • 1
    It turns out the I had LZO compression (comp-lzo) specified in my client configuration but not the server configuration. Once I corrected that issue I can now access the internet and the rest of the network. Now the only thing I have to solve for is accessing the VM's from a VPN connection. – Bob C. Oct 10 '17 at 15:01
  • Did you ever solve your 2nd problem with communication between the VMs? If not, I suspect the issue is that your systems are really in different networks without a route to talk to each other. I'd be interested to know what solutions you found, if any. – code_dredd Dec 2 '18 at 0:18
  • Please see the update to my original posting above. This addition to my post is from notes that I recorded after solving the issue last year. – Bob C. Dec 5 '18 at 21:33
0

I had LZO compression (comp-lzo) specified in my client configuration but not the server configuration. Once I corrected that issue I can now access the internet and the rest of the network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.