0

After connection to openvpn i can not ping even vpn address (172.16.0.1) here is my vpn config:

##protocol port

port 1194

proto tcp

dev tun



##ip server client

server 172.16.0.0 255.255.0.0



##key

ca /etc/openvpn/ca.crt

cert /etc/openvpn/server.crt

key /etc/openvpn/server.key

dh /etc/openvpn/dh2048.pem



##option

persist-key

persist-tun

keepalive 5 60

reneg-sec 432000



##option authen.

comp-lzo

user nobody

#group nogroup

client-to-client

username-as-common-name

client-cert-not-required

auth-user-pass-verify /etc/openvpn/scripts/login.sh via-env



##push to client

max-clients 50

push "persist-key"

push "persist-tun"

push "redirect-gateway local def1"

push "explicit-exit-notify 1"

#push "route 172.16.1.0 255.255.255.0 172.16.1.1"
#push "route-gateway 172.16.1.1"

#push "route add 10.123.0.0 255.255.0.0 172.16.1.1"



##DNS-Server

push "dhcp-option DNS 10.96.0.10"



##script connect-disconnect

script-security 2

##client-connect /etc/openvpn/scripts/connect.sh

client-disconnect /etc/openvpn/scripts/disconnect.sh



##log-status

##status /etc/openvpn/log/tcp_443.log

##log-append /etc/openvpn/log/openvpn.log

verb 3

after connection i see some strange routes are created:

default via 172.16.0.5 dev tun0 proto static metric 50 
default via 192.168.10.1 dev enp5s0 proto dhcp metric 100 
172.16.0.0/16 via 172.16.0.5 dev tun0 proto static metric 50 
172.16.0.5 dev tun0 proto kernel scope link src 172.16.0.6 metric 50 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.10.0/24 dev enp5s0 proto kernel scope link src 192.168.10.181 metric 100 
192.168.10.1 dev enp5s0 proto static scope link metric 100 
194.177.28.83 via 192.168.10.1 dev enp5s0 proto static metric 100 

why it is adding 172.16.0.5 instead of 172.16.0.1? Such address even does not exist.

EDIT:

Like mentioned in comment, yes it is peer ip and after i removed "#push "redirect-gateway local def1" it started to ping VPN ip but i can not still connect to my services behind vpn. My firewall rules are:

iptables -A FORWARD -i tun0 -o eth0 -s 172.16.0.0/24 -d 10.0.0.0/8 -m conntrack --ctstate NEW -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -s 172.16.0.0/24 -j MASQUERADE
5
  • Guess, 172.16.0.5 is the client tun interface ip. Can you post the output of ifconfig?
    – Diamond
    Aug 3, 2018 at 9:45
  • Yes You have right i updated original post Aug 3, 2018 at 10:46
  • For each VPN connection the server uses two IP addresses, one that is given to the client (172.16.0.6 in your case) and one point to point address that is used to reach the Server via the tunnel (172.16.0.5). Basically the routing table looks OK. 172.16.0.5 is your tunnel endpoint (where you need to send packets if you want to use the tunnel). There is a new default gateway (first line of the routes) with a lower metric (i.e. higher priority). First thing to test, after the VPN is up, try if you can reach 172.16.0.5 via ping. If that is OK the tunnel is up and working. Aug 3, 2018 at 11:41
  • In which ip is your services running? can you ping it? do you have a route to it?
    – Diamond
    Aug 3, 2018 at 11:44
  • Services are in 10.0.0.0/8 network im adding routeing to it manually (push is not working: "route parameter network/IP 'add' must be a valid address" I can not ping 172.16.0.5 but i can ping 172.16.0.1 which is ip of openvpn server (tun0 interface on server) Aug 3, 2018 at 12:18

1 Answer 1

0

I find out solution. I thought:

sysctl -w net.ipv4.ip_forward=1

is taken from node settings, but i find out pod have its own namespace so this setting is needed. But..

there was problem with setup it as they are read only in containers. So i try to set it up with this beta feature from kubernetes but it did not work for me so i used privilaged container setting and set up sysctls from start script.

Thanks to it i can connect to my k8s services ClusterIPs directly from clients

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .