Page 1 of 1

Route Addition Failure

Posted: Sat Aug 01, 2015 1:41 pm
by annaconda
Hi. I've configure my raspberry pi as a vpn server from the tutorial on BBC's Click program.
I can get the Initilization sequence completed but the seems to be an error of "Route addition failure" in the openvpn log. I seem to be able to browse the internet with the server running on my laptop and when it's not running. I assume I'm going through the vpn server as when I does a tracert it shows a 10.8.0.1 address and when I disconnect, tracert shows a 192.158.0.1 but maybe I'm wrong. Is the "route addition failure" an issue. I assume it is.

I tried to connect my android phone from an external lan using openvpn but it hangs just "Waiting for server". It sends bits out but nothing comes back.

Here are my logs and config files. Can anyone help?

Client Config

Code: Select all

client
dev tun
proto udp
remote 90.xxx.xxx.xxx 1194 
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20


Server Config

Code: Select all

dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/pymmes.crt
key /etc/openvpn/easy-rsa/keys/pymmes.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.1 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"
push "dhcp-option DNS 8.8.8.8"
push "redirect-gateway def1"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1
Connection Status

Wed Jul 29 15:41:32 2015 OpenVPN 2.3.7 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Jul 9 2015
Wed Jul 29 15:41:32 2015 library versions: OpenSSL 1.0.1p 9 Jul 2015, LZO 2.08
Wed Jul 29 15:41:39 2015 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Wed Jul 29 15:41:39 2015 Control Channel Authentication: tls-auth using INLINE static key file
Wed Jul 29 15:41:39 2015 UDPv4 link local: [undef]
Wed Jul 29 15:41:39 2015 UDPv4 link remote: [AF_INET]90.xxx.xxx.xxx:1194
Wed Jul 29 15:41:39 2015 [pymmes] Peer Connection Initiated with [AF_INET]90.xxx.xxx.xxx:1194
Wed Jul 29 15:41:42 2015 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Wed Jul 29 15:41:42 2015 open_tun, tt->ipv6=0
Wed Jul 29 15:41:42 2015 TAP-WIN32 device [Ethernet 2] opened: \\.\Global\{EE5E04FE-80A7-445E-B0B0-21F906EEE887}.tap
Wed Jul 29 15:41:42 2015 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.8.0.6/255.255.255.252 on interface {EE5E04FE-80A7-445E-B0B0-21F906EEE887} [DHCP-serv: 10.8.0.5, lease-time: 31536000]
Wed Jul 29 15:41:42 2015 Successful ARP Flush on interface [21] {EE5E04FE-80A7-445E-B0B0-21F906EEE887}
Wed Jul 29 15:41:47 2015 ROUTE: route addition failed using CreateIpForwardEntry: The object already exists. [status=5010 if_index=21]
Wed Jul 29 15:41:47 2015 env_block: add PATH=C:\Windows\System32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
Wed Jul 29 15:41:47 2015 Initialization Sequence Completed




Routing table

Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
10.8.0.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0


Ipconfig

root@raspberrypi:/etc/openvpn# ifconfig
eth0 Link encap:Ethernet HWaddr b8:27:eb:1f:47:7e
inet addr:192.168.0.22 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:9304 errors:0 dropped:0 overruns:0 frame:0
TX packets:7411 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:3453535 (3.2 MiB) TX bytes:3548687 (3.3 MiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:2766 errors:0 dropped:0 overruns:0 frame:0
TX packets:3471 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:253322 (247.3 KiB) TX bytes:2706228 (2.5 MiB)




Any help would be most appreciated.

Regards, Mark, an Openvpn noobie

Re: Route Addition Failure

Posted: Sun Aug 02, 2015 8:44 am
by maikcat
please post the output of

netstat -nr

on your client before & after vpn is up.

also are you running openvpn with admin rights?

Michael.

Re: Route Addition Failure

Posted: Sun Aug 02, 2015 4:23 pm
by Traffic
Looks like this old chestnut again ..
  • NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.

Re: Route Addition Failure

Posted: Tue Nov 29, 2016 4:15 pm
by leeph
Old chestnut? Not necessarily...

The instructions provided on BBC Click's article, and also the config used in the default piVPN project have some extraneous
routes pushed to clients that really aren't required at all, and actually cause this error to occur even when someone isn't using
a common private address space at both ends.

Specifically:

# Add route to Client routing table for the OpenVPN Server
push "route 10.8.0.1 255.255.255.255"
# Add route to Client routing table for the OPenVPN Subnet
push "route 10.8.0.0 255.255.255.0"

Those two routes are NOT REQUIRED and one (possibly both) cause the error 'route already exists' as in the OP's question.

On the client end, the server subnet routes are automatically created when the TUN adapter gets configured (as part of the OpenVPN
connection process) regardless of whether the server config has the above 'push route' statements. Comment them out, your VPN will
still work fine, and you won't see that error on the client end anymore.