client sees tun and enp0s3 networks, expecting tun only

techiebiker

Trying to set up my first test VPN and it works. Client and Server can ping each other across the tunnel.

But pings Client to Server and vice versa work regardless whether pinging the tunnel address or the host adapter address.

I didn't expect that because I haven't pushed the local network across the tunnel from the server. I thought using

--push "redirect-gateway def1"

on the server causes OpenVPN to change the client's route table so all IP traffic gets directed across the tunnel.

How do I force the client's IP traffic to use only the tun0 adapter? All help appreciated. Thank you.

Client command line to start the VPN

sudo openvpn --remote 192.168.58.10 --dev tun0 --ifconfig 10.4.0.1 10.4.0.2 --tls-client --ca ca.crt --cert client.crt --key client.key

...and Client routing table after starting the VPN

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.58.1    0.0.0.0         UG    100    0        0 enp0s3
10.4.0.2        *               255.255.255.255 UH    0      0        0 tun0
link-local      *               255.255.0.0     U     1000   0        0 enp0s3
192.168.58.0    *               255.255.255.0   U     100    0        0 enp0s3

Server command line to start the VPN

sudo openvpn --remote 192.168.58.5 --dev tun0 --ifconfig 10.4.0.2 10.4.0.1 --tls-server --dh dh2048.pem --ca ca.crt --cert server.crt --key server.key --push "redirect-gateway def1"

...and Server routing table after starting the VPN

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         192.168.58.1    0.0.0.0         UG    0    0        0 enp0s3
10.4.0.1        *               255.255.255.255 UH    0    0        0 tun0
192.168.58.0    *               255.255.255.0   U     0    0        0 enp0s3

No firewall is enabled on either host

iptables on both hosts are

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

TinCanTech

techiebiker wroteBut pings Client to Server and vice versa work regardless whether pinging the tunnel address or the host adapter address

No they do not.

Try this in your server config:

push "redirect-gateway def1 block-local"

Also, Please see:
HOWTO: Request Help ! {2}

techiebiker

"No they do not."? Um, yeah they do.

As you suggest added "block-local" to the push directive. Same result. Server and client can ping each other on the tun and enp interface addresses.

Routing tables remain exactly as in first post. IPtables still the same too.

Additional info as suggested in HOWTO: Request Help ! (2)

OpenVPN version on Client and Server

$ openvpn --version
OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08

Client OS

uname -a
Linux VPN-client 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Server OS

uname -a
Linux server 4.4.0-83-generic #106-Ubuntu SMP Mon Jun 26 17:54:43 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

Client interfaces

$ ip address list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:35:ac:3e brd ff:ff:ff:ff:ff:ff
    inet 192.168.58.5/24 brd 192.168.58.255 scope global dynamic enp0s3
       valid_lft 877sec preferred_lft 877sec
    inet6 fe80::446:c96c:7a4b:3d47/64 scope link 
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.4.0.1 peer 10.4.0.2/32 scope global tun0
       valid_lft forever preferred_lft forever

Server interfaces

$ ip address list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:f5:47:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.58.10/24 brd 192.168.58.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fef5:4705/64 scope link 
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 10.4.0.2 peer 10.4.0.1/32 scope global tun0
       valid_lft forever preferred_lft forever

TinCanTech

TinCanTech wrote
techiebiker wroteBut pings Client to Server and vice versa work regardless whether pinging the tunnel address or the host adapter address
No they do not.
techiebiker wrote"No they do not."? Um, yeah they do.

Only because your sever and client are on the same LAN.

techiebiker wroteHow do I force the client's IP traffic to use only the tun0 adapter? All help appreciated. Thank you

TinCanTech wroteTry this in your server config:

push "redirect-gateway def1 block-local"

and then go to some other LAN to try it .. local cafe etc.

You cannot do this while your server and client are on the same LAN because the client would route the VPN packets over the VPN .. you can not do this on a remote LAN either but the problem becomes more clear.

techiebiker wroteOpenVPN version on Client and Server

$ openvpn --version
OpenVPN 2.3.10 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Jun 22 2017
library versions: OpenSSL 1.0.2g  1 Mar 2016, LZO 2.08

Try OpenVPN v2.4.3