Unix & Linux
Internet is not working when VPN is up
I'd like to redirect all trafic through VPN, but it doesn't work at all.
server: RT-N16 [TomatoUSB v1.28.0000 MIPSR2-112 K26 USB AIO]
client: Ubuntu 14.04.1
server config:
# Automatically generated configuration daemon server 10.8.0.0 255.255.255.0 proto tcp-server port 9999 dev tun21 cipher AES-256-CBC comp-lzo no keepalive 15 60 verb 3 push "route 192.168.1.0 255.255.255.0" push "dhcp-option DNS 192.168.1.1" push "redirect-gateway def1" ca ca.crt dh dh.pem cert server.crt key server.key status-version 2 status status # Custom Configuration (these section appears to be main FIX): client-to-client push "comp-lzo" push "redirect-gateway"
server: iptables -L -t nat -n (just POSTROUTING chain of output)
Chain POSTROUTING (policy ACCEPT) target prot opt source destination MASQUERADE all -- 0.0.0.0/0 0.0.0.0/0 SNAT all -- 192.168.1.0/24 192.168.1.0/24 to:192.168.1.1
server log:
Feb 4 21:19:38 r daemon.notice openvpn[1072]: TCP connection established with [AF_INET]192.168.1.4:58170 Feb 4 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 TLS: Initial packet from [AF_INET]192.168.1.4:58170, sid=00fe6a02 33820233 Feb 4 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 VERIFY OK: XXXXXXXXXXXXXXXX Feb 4 21:19:39 r daemon.notice openvpn[1072]: 192.168.1.4:58170 VERIFY OK: XXXXXXXXXXXXXXXX Feb 4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Feb 4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Feb 4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key Feb 4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Feb 4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA Feb 4 21:19:40 r daemon.notice openvpn[1072]: 192.168.1.4:58170 [client] Peer Connection Initiated with [AF_INET]192.168.1.4:58170 Feb 4 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI_sva: pool returned IPv4=10.8.0.6, IPv6=(Not enabled) Feb 4 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: Learn: 10.8.0.6 -> client/192.168.1.4:58170 Feb 4 21:19:40 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 MULTI: primary virtual IP for client/192.168.1.4:58170: 10.8.0.6 Feb 4 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 PUSH: Received control message: 'PUSH_REQUEST' Feb 4 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 send_push_reply(): safe_cap=940 Feb 4 21:19:43 r daemon.notice openvpn[1072]: client/192.168.1.4:58170 SENT CONTROL [client]: 'PUSH_REPLY,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.1.1,redirect-gateway def1,route 10.8.0.1,topology net30,ping 15,ping-restart 60,ifconfig 10.8.0.6 10.8.0.5' (status=1)
client config:
client remote 192.168.1.1 9999 ca ca.crt cert client.crt key client.key cipher AES-256-CBC dev tun proto tcp nobind auth-nocache script-security 2 persist-key persist-tun user nobody group nogroup
client: netstat -nr (with vpn up):
Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 0.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0 10.8.0.1 10.8.0.5 255.255.255.255 UGH 0 0 0 tun0 10.8.0.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 128.0.0.0 10.8.0.5 128.0.0.0 UG 0 0 0 tun0 192.168.1.0 10.8.0.5 255.255.255.0 UG 0 0 0 tun0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 192.168.1.1 192.168.1.1 255.255.255.255 UGH 0 0 0 wlan0
client log:
Wed Feb 4 21:32:24 2015 OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Dec 1 2014 Wed Feb 4 21:32:24 2015 WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Wed Feb 4 21:32:24 2015 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay Wed Feb 4 21:32:24 2015 Attempting to establish TCP connection with [AF_INET]192.168.1.1:9999 [nonblock] Wed Feb 4 21:32:25 2015 TCP connection established with [AF_INET]192.168.1.1:9999 Wed Feb 4 21:32:25 2015 TCPv4_CLIENT link local: [undef] Wed Feb 4 21:32:25 2015 TCPv4_CLIENT link remote: [AF_INET]192.168.1.1:9999 Wed Feb 4 21:32:26 2015 [zais.dnsd.me] Peer Connection Initiated with [AF_INET]192.168.1.1:9999 Wed Feb 4 21:32:29 2015 TUN/TAP device tun0 opened Wed Feb 4 21:32:29 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Wed Feb 4 21:32:29 2015 /sbin/ip link set dev tun0 up mtu 1500 Wed Feb 4 21:32:29 2015 /sbin/ip addr add dev tun0 local 10.8.0.6 peer 10.8.0.5 Wed Feb 4 21:32:29 2015 GID set to nogroup Wed Feb 4 21:32:29 2015 UID set to nobody Wed Feb 4 21:32:29 2015 Initialization Sequence Completed Wed Feb 4 21:32:43 2015 write to TUN/TAP : Invalid argument (code=22) Wed Feb 4 21:32:58 2015 write to TUN/TAP : Invalid argument (code=22) Wed Feb 4 21:33:13 2015 write to TUN/TAP : Invalid argument (code=22) Wed Feb 4 21:33:28 2015 write to TUN/TAP : Invalid argument (code=22)
UPDATE: thanks for help. VPN is working now (not sure way but i need to wait about 5mins after connection to actually get it to working state, may be it's limits of my router, like not enough CPU/MEM)
Solution
For some reason your client is unable to delete the current default route when the tunnel opens, thereby causing two default routes to exist in the routing table.
What you are going to have to do is give the current route a lower metric (higher number) before the tunnel comes up. You can see the metric with the route -n command:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.3.0 10.8.1.2 255.255.255.0 UG 0 0 0 tun0
9.15.64.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
0.0.0.0 9.15.64.1 0.0.0.0 UG 0 0 0 eth0
So for example give your wlan interface a metric of 20 and let the tunnel route come up with a metric of zero. Your traffic will all be sent down the tunnel route.
In order to configure the metric on the interface just open the wlan interface file in the /etc/sysconfig/network-scripts directory and add a parameter called METRIC=20.
That should do it. Make sure you verify it afterwards with the route -n command.
UPDATE:
Now that you have the proper default route, its time to troubleshoot with tcpdump and pings. For example try the below command and perform some ping to the remote network.
# tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:59:13.591764 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 4, length 64
09:59:13.681290 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 4, length 64
09:59:14.592829 IP 192.168.4.190 > 192.168.3.1: ICMP echo request, id 3154, seq 5, length 64
09:59:14.680878 IP 192.168.3.1 > 192.168.4.190: ICMP echo reply, id 3154, seq 5, length 64
My guess is you will see the echo request but not the echo reply. This means that the remote endpoint is not routing the packets back. You need to fix the routes there too in the server config file.
UPDATE2
From your tcpdump it is clear that your client is routing the packets via the tunnel, your problem therefore lies at the remote end because it is not rounting the packets back.
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
09:19:28.964361 IP 10.8.0.6.57394 > 192.168.1.1.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964382 IP 10.8.0.6.57394 > 8.8.8.8.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
09:19:28.964398 IP 10.8.0.6.57394 > 8.8.4.4.domain: 60317+ A? daisy.ubuntu.com.localdomain. (46)
You must examine every hop to see what the routing table looks like. Start with 192.168.1.1. Does it know where to route packets sent to 10.8.0.6?
Comments (5)
- +0 – Is the metric field similar to
nicefor processes where the lower number is given a higher priority? Ifniceapplies to the cpu resources given to a process, what does metric apply to? Preferred routing of packets? — Feb 04, 2015 at 19:22 - +0 – Confirmed, that's about what it does. Cool solution! Would like to know if it solved this problem. en.wikipedia.org/wiki/Metrics_(networking) — Feb 04, 2015 at 19:24
- +0 – Tried
sudo route add default gw 10.8.0.5, it worked in local network, will try remote vpn session. — Feb 05, 2015 at 16:30 - +0 – I've added
push "redirect-gateway"to server config. And tried to connect from remote location. But it doesn't work :(netstat -nrshows default gateway just ok:0.0.0.0 10.8.0.5 0.0.0.0 UG 0 0 0 tun0— Feb 06, 2015 at 06:25 - +0 – what about the other default gateway via wlan? Is it still there (meaning two simlultaneous default gateways)? If it is then you need to modify the metric as I explained above. — Feb 06, 2015 at 16:01