1

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)

0

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?

  • Is the metric field similar to nice for processes where the lower number is given a higher priority? If nice applies to the cpu resources given to a process, what does metric apply to? Preferred routing of packets? – iyrin Feb 4 '15 at 19:22
  • Confirmed, that's about what it does. Cool solution! Would like to know if it solved this problem. en.wikipedia.org/wiki/Metrics_(networking) – iyrin Feb 4 '15 at 19:24
  • Tried sudo route add default gw 10.8.0.5, it worked in local network, will try remote vpn session. – zais Feb 5 '15 at 16:30
  • I've added push "redirect-gateway" to server config. And tried to connect from remote location. But it doesn't work :( netstat -nr shows default gateway just ok: 0.0.0.0 10.8.0.5 0.0.0.0 UG 0 0 0 tun0 – zais Feb 6 '15 at 6:25
  • 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. – Ricardo Feb 6 '15 at 16:01

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.