OpenVPN client wrong routes

[tombush]

I'm trying to set up a server which runs Nginx and host a OpenVPN access server, the webserver should be accessable only through the VPN.
So the clients traffic targeted to the webserver should be routed through the tunnel, any access not through the VPN should result in a proper response (403?).

server.conf

Code: Select all

port 1194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
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 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
cipher AES-256-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

client.conf

Code: Select all

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote 35.156.85.171 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3

But seems like all client traffic but the target server goes through the VPN. should be the other way around.


client route table with VPN NOT ACTIVE

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.138      0.0.0.0         UG    102    0        0 enp1s0
10.0.0.0        0.0.0.0         255.255.255.0   U     102    0        0 enp1s0

client route table with VPN ACTIVE

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tun0
0.0.0.0         10.0.0.138      0.0.0.0         UG    102    0        0 enp1s0
10.0.0.0        0.0.0.0         255.255.255.0   U     102    0        0 enp1s0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
35.156.85.171   10.0.0.138      255.255.255.255 UGH   0      0        0 enp1s0
128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tun0

What am I doing wrong?

[novaflash]

You can't force traffic for the public IP where the VPN terminates through the VPN tunnel itself, that creates an endless loop. To illustrate:

You send a packet to 35.156.85.171. If your routing table contained the instruction to send this through the VPN tunnel, then the packet would go into the virtual network adapter on the client side, be encrypted and encapsulated, then that packet would be sent to the VPN server at 35.156.85.171. But oh no, your routing table contains the instruction to send traffic for 35.156.85.171 through the VPN tunnel. So the encrypted and encapsulated packet goes into the virtual network adapter on the client side, is encrypted and encapsulated, and then that packet would be sent to the VPN server at 35.156.85.171. But oh no, your routing table contains the instruction to send traffic for 35.156.85.171 through the VPN tunnel. So the encrypted and encapsulated packet goes into the virtual network adapter on the client side, is encrypted and encapsulated, and then that packet would be sent to the VPN server at 35.156.85.171. But oh no, your routing table contains the instruction to send traffic for 35.156.85.171 through the VPN tunnel. So the encrypted and encapsulated packet goes into the virtual network adapter on the client side, is encrypted and encapsulated, and then that packet would be sent to the VPN server at 35.156.85.171. But oh no, your routing table contains the instruction to send traffic for 35.156.85.171 through the VPN tunnel. So the encrypted and encapsulated packet goes into the virtual network adapter on the client side, is encrypted and encapsulated, and then that packet would be sent to the VPN server at 35.156.85.171. But oh no, your routing table contains the instruction to send traffic for 35.156.85.171 through the VPN tunnel. So the encrypted and encapsulated packet goes into the virtual network adapter on the client side, is encrypted and encapsulated, and then that packet would be sent to the VPN server at 35.156.85.171. But oh no, your routing table contains the instruction to send traffic for 35.156.85.171 through the VPN tunnel. So the encrypted and encapsulated packet goes into the virtual network adapter on the client side, is encrypted and encapsulated, and ---etc

Either install your VPN server on another IP, or run your HTTP server on another IP. For example you could have a private network address on this server that you bind the nginx service to. Since a private IP address can be reached through a VPN tunnel, but not directly over the Internet, then there's your solution.