# OpenVPN Routing Issue [SOLVED]

## gpeangel

I think this is a routing issue. After a recent emerge update from openvpn-2.0.5 to openvpn-2.0.5-r2, I have not been able to access my VPN networks. I can connect without error and the openvpn server (gentoo) assigns an IP address to the client (Windows XP), but I cannot otherwise connect to any other boxes on the network using, for example, ssh, ftp, ping, etc. Can anyone suggest where I might look for the cause of this?

I've tried several things suggested in other posts, such as changing "dev tap" to "dev tap0", but so far nothing has helped.

# cat /etc/openvpn/openvpn.conf

```
dev tap

tls-server

ca keys/ca.crt

cert keys/server.crt

key keys/server.key

dh keys/dh1024.pem

tls-auth keys/ta.key 0

server 10.22.0.0 255.255.255.0

ifconfig-pool-persist ipp.txt

ifconfig 10.22.0.1 255.255.255.0 # openvpn gateway

push "dhcp-option DNS xxx.xxx.xxx.xxx" # push DNS entries to openvpn client

push "dhcp-option DNS xxx.xxx.xxx.xxx"

push "route-gateway 10.22.0.1" # push default gateway

keepalive 10 60

push "ping 10"

push "ping-restart 60"

push "route 10.10.10.0 255.255.255.0"

push "route 10.22.0.0 255.255.255.0"

comp-lzo

status /var/log/openvpn/openvpn-status.log

log         /var/log/openvpn/openvpn.log

log-append  /var/log/openvpn/openvpn.log

verb 6

persist-tun

persist-key

mute 10

user nobody

group nobody

chroot /usr/local/openvpn
```

# Client Config

```
dev tap

remote xxx.xxx.xxx.xxx

tls-client

ca ca.crt

cert client_csgs.crt

key client_csgs.key

tls-auth ta.key 1

tls-remote /C=US/ST=CO/L=Denver/O=Java_Zen/CN=server/emailAddress=webmaster@javazen.com

pull

comp-lzo

verb 6

mute 10
```

# route

```
Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.22.0.0       *               255.255.255.0   U     0      0        0 tap0

10.10.10.0      *               255.255.255.0   U     0      0        0 eth0

loopback        localhost       255.0.0.0       UG    0      0        0 lo

default         10.10.10.1      0.0.0.0         UG    0      0        0 eth0
```

The client log on connect:

```
Fri Jan 27 09:48:27 2006 us=479632 MULTI: multi_create_instance called

Fri Jan 27 09:48:27 2006 us=498077 xxx.xxx.xxx.xxx:15055 Re-using SSL/TLS context

Fri Jan 27 09:48:27 2006 us=515008 xxx.xxx.xxx.xxx:15055 LZO compression initialized

Fri Jan 27 09:48:27 2006 us=530697 xxx.xxx.xxx.xxx:15055 Control Channel MTU parms [ L:1574 D:166 EF:66 EB:0 ET:0 EL:0 ]

Fri Jan 27 09:48:27 2006 us=530731 xxx.xxx.xxx.xxx:15055 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]

Fri Jan 27 09:48:27 2006 us=543969 xxx.xxx.xxx.xxx:15055 Local Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 0,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-server'

Fri Jan 27 09:48:27 2006 us=543997 xxx.xxx.xxx.xxx:15055 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1574,tun-mtu 1532,proto UDPv4,comp-lzo,keydir 1,cipher BF-CBC,auth SHA1,keysize 128,tls-auth,key-method 2,tls-client'

Fri Jan 27 09:48:27 2006 us=544044 xxx.xxx.xxx.xxx:15055 Local Options hash (VER=V4): '360696c5'

Fri Jan 27 09:48:27 2006 us=544076 xxx.xxx.xxx.xxx:15055 Expected Remote Options hash (VER=V4): '13a273ba'

Fri Jan 27 09:48:27 2006 us=544157 xxx.xxx.xxx.xxx:15055 UDPv4 READ [42] from xxx.xxx.xxx.xxx:15055: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0

Fri Jan 27 09:48:27 2006 us=544190 xxx.xxx.xxx.xxx:15055 TLS: Initial packet from xxx.xxx.xxx.xxx:15055, sid=76dfa96a f5189fbb

Fri Jan 27 09:48:27 2006 us=544286 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [54] to xxx.xxx.xxx.xxx:15055: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0

Fri Jan 27 09:48:27 2006 us=641427 xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #2 ] [ 0 ]

Fri Jan 27 09:48:27 2006 us=645072 xxx.xxx.xxx.xxx:15055 UDPv4 READ [142] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #3 ] [ ] pid=1 DATA len=100

Fri Jan 27 09:48:27 2006 us=645151 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #2 ] [ 1 ]

Fri Jan 27 09:48:27 2006 us=647772 xxx.xxx.xxx.xxx:15055 UDPv4 READ [44] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #4 ] [ ] pid=2 DATA len=2

Fri Jan 27 09:48:27 2006 us=659230 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [154] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #3 ] [ 2 ] pid=1 DATA len=100

Fri Jan 27 09:48:27 2006 us=659319 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #4 ] [ ] pid=2 DATA len=100

Fri Jan 27 09:48:27 2006 us=659483 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #5 ] [ ] pid=3 DATA len=100

Fri Jan 27 09:48:27 2006 us=659559 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #6 ] [ ] pid=4 DATA len=100

Fri Jan 27 09:48:27 2006 us=755763 xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #5 ] [ 1 ]

Fri Jan 27 09:48:27 2006 us=755829 xxx.xxx.xxx.xxx:15055 NOTE: --mute triggered...

Fri Jan 27 09:48:28 2006 us=952726 xxx.xxx.xxx.xxx:15055 77 variation(s) on previous 10 message(s) suppressed by --mute

Fri Jan 27 09:48:28 2006 us=952818 xxx.xxx.xxx.xxx:15055 VERIFY OK: depth=1, /C=US/ST=CO/L=Denver/O=Java_Zen/CN=Java_Zen_CA/emailAddress=webmaster@javazen.com

Fri Jan 27 09:48:28 2006 us=953125 xxx.xxx.xxx.xxx:15055 VERIFY OK: depth=0, /C=US/ST=CO/L=Denver/O=Java_Zen/CN=client_box/emailAddress=webmaster@javazen.com

Fri Jan 27 09:48:28 2006 us=953203 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #44 ] [ 20 ]

Fri Jan 27 09:48:28 2006 us=953312 xxx.xxx.xxx.xxx:15055 UDPv4 READ [142] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #46 ] [ ] pid=21 DATA len=100

Fri Jan 27 09:48:28 2006 us=953379 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #45 ] [ 21 ]

Fri Jan 27 09:48:28 2006 us=964073 xxx.xxx.xxx.xxx:15055 UDPv4 READ [142] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #47 ] [ ] pid=22 DATA len=100

Fri Jan 27 09:48:28 2006 us=972804 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #46 ] [ 22 ]

Fri Jan 27 09:48:29 2006 us=30360 xxx.xxx.xxx.xxx:15055 UDPv4 READ [142] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #48 ] [ ] pid=23 DATA len=100

Fri Jan 27 09:48:29 2006 us=30978 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [113] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #47 ] [ 23 ] pid=25 DATA len=59

Fri Jan 27 09:48:29 2006 us=123565 xxx.xxx.xxx.xxx:15055 UDPv4 READ [154] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #49 ] [ 25 ] pid=24 DATA len=100

Fri Jan 27 09:48:29 2006 us=123759 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #48 ] [ 24 ]

Fri Jan 27 09:48:29 2006 us=124498 xxx.xxx.xxx.xxx:15055 UDPv4 READ [142] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #50 ] [ ] pid=25 DATA len=100

Fri Jan 27 09:48:29 2006 us=124548 xxx.xxx.xxx.xxx:15055 NOTE: --mute triggered...

Fri Jan 27 09:48:29 2006 us=126660 xxx.xxx.xxx.xxx:15055 4 variation(s) on previous 10 message(s) suppressed by --mute

Fri Jan 27 09:48:29 2006 us=126687 xxx.xxx.xxx.xxx:15055 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key

Fri Jan 27 09:48:29 2006 us=126712 xxx.xxx.xxx.xxx:15055 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Fri Jan 27 09:48:29 2006 us=126795 xxx.xxx.xxx.xxx:15055 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key

Fri Jan 27 09:48:29 2006 us=126827 xxx.xxx.xxx.xxx:15055 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication

Fri Jan 27 09:48:29 2006 us=126908 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [154] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #51 ] [ 27 ] pid=26 DATA len=100

Fri Jan 27 09:48:29 2006 us=126978 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #52 ] [ ] pid=27 DATA len=100

Fri Jan 27 09:48:29 2006 us=127044 xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [124] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #53 ] [ ] pid=28 DATA len=82

Fri Jan 27 09:48:29 2006 us=217799 xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #53 ] [ 26 ]

Fri Jan 27 09:48:29 2006 us=219449 xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #54 ] [ 27 ]

Fri Jan 27 09:48:29 2006 us=234525 xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #55 ] [ 28 ]

Fri Jan 27 09:48:29 2006 us=234662 xxx.xxx.xxx.xxx:15055 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA

Fri Jan 27 09:48:29 2006 us=234712 xxx.xxx.xxx.xxx:15055 [client_box] Peer Connection Initiated with xxx.xxx.xxx.xxx:15055

Fri Jan 27 09:48:30 2006 us=515117 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [132] from xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #56 ] [ ] pid=28 DATA len=90

Fri Jan 27 09:48:30 2006 us=515342 client_box/xxx.xxx.xxx.xxx:15055 PUSH: Received control message: 'PUSH_REQUEST'

Fri Jan 27 09:48:30 2006 us=515423 client_box/xxx.xxx.xxx.xxx:15055 SENT CONTROL [client_box]: 'PUSH_REPLY,dhcp-option DNS xxx.xxx.xxx.xxx,dhcp-option DNS xxx.xxx.xxx.xxx,route-gateway 10.22.0.1,ping 10,ping-restart 60,route 10.10.10.0 255.255.255.0,route 10.22.0.0 255.255.255.0,route-gateway 10.22.0.1,ping 10,ping-restart 60,ifconfig 10.22.0.2 255.255.255.0' (status=1)

Fri Jan 27 09:48:30 2006 us=515472 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #54 ] [ 28 ]

Fri Jan 27 09:48:30 2006 us=515561 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #55 ] [ ] pid=29 DATA len=100

Fri Jan 27 09:48:30 2006 us=515633 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #56 ] [ ] pid=30 DATA len=100

Fri Jan 27 09:48:30 2006 us=515699 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [142] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #57 ] [ ] pid=31 DATA len=100

Fri Jan 27 09:48:30 2006 us=515765 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [72] to xxx.xxx.xxx.xxx:15055: P_CONTROL_V1 kid=0 pid=[ #58 ] [ ] pid=32 DATA len=30

Fri Jan 27 09:48:30 2006 us=621041 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #57 ] [ 29 ]

Fri Jan 27 09:48:30 2006 us=627630 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #58 ] [ 30 ]

Fri Jan 27 09:48:30 2006 us=634475 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #59 ] [ 31 ]

Fri Jan 27 09:48:30 2006 us=703551 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [50] from xxx.xxx.xxx.xxx:15055: P_ACK_V1 kid=0 pid=[ #60 ] [ 32 ]

Fri Jan 27 09:48:36 2006 us=276553 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [77] from xxx.xxx.xxx.xxx:15055: P_DATA_V1 kid=0 DATA len=76

Fri Jan 27 09:48:36 2006 us=276737 client_box/xxx.xxx.xxx.xxx:15055 MULTI: Learn: 00:ff:ef:52:69:8d -> client_box/xxx.xxx.xxx.xxx:15055

Fri Jan 27 09:48:36 2006 us=276778 client_box/xxx.xxx.xxx.xxx:15055 TUN WRITE [42]

Fri Jan 27 09:48:38 2006 us=99331 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [77] from xxx.xxx.xxx.xxx:15055: P_DATA_V1 kid=0 DATA len=76

Fri Jan 27 09:48:38 2006 us=99496 client_box/xxx.xxx.xxx.xxx:15055 TUN WRITE [42]

Fri Jan 27 09:48:38 2006 us=223431 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [77] from xxx.xxx.xxx.xxx:15055: P_DATA_V1 kid=0 DATA len=76

Fri Jan 27 09:48:38 2006 us=223475 client_box/xxx.xxx.xxx.xxx:15055 TUN WRITE [42]

Fri Jan 27 09:48:39 2006 us=301707 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [77] from xxx.xxx.xxx.xxx:15055: P_DATA_V1 kid=0 DATA len=76

Fri Jan 27 09:48:39 2006 us=301877 client_box/xxx.xxx.xxx.xxx:15055 TUN WRITE [42]

Fri Jan 27 09:48:39 2006 us=301963 client_box/xxx.xxx.xxx.xxx:15055 TUN READ [42]

Fri Jan 27 09:48:39 2006 us=302024 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 WRITE [77] to xxx.xxx.xxx.xxx:15055: P_DATA_V1 kid=0 DATA len=76

Fri Jan 27 09:48:39 2006 us=424669 client_box/xxx.xxx.xxx.xxx:15055 UDPv4 READ [149] from xxx.xxx.xxx.xxx:15055: P_DATA_V1 kid=0 DATA len=148

Fri Jan 27 09:48:39 2006 us=424784 client_box/xxx.xxx.xxx.xxx:15055 NOTE: --mute triggered...
```

----------

## nielchiano

first of all, and completely off topic: it's more efficient to use TUN's instead of TAP's, unless you need tap for some reason, which I guess you don't, since you're routing.

 *gpeangel wrote:*   

> but I cannot otherwise connect to any other boxes on the network using, for example, ssh, ftp, ping, etc.

 

The problem is, I think, here:

```
Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.22.0.0       *               255.255.255.0   U     0      0        0 tap0

10.10.10.0      *               255.255.255.0   U     0      0        0 eth0

loopback        localhost       255.0.0.0       UG    0      0        0 lo

default         10.10.10.1      0.0.0.0         UG    0      0        0 eth0          <-----------
```

Notice that the interface is eth0, not tap0, and has the wrong IP

so apparently, your default gateway doesn't get set. In DOES seem to get pushed...

personaly I use

```
push "redirect-gateway"
```

instead of your route-gateway, but according to "man openvpn" the result should be the same.

you might turn on more verbose logging on the client to see why your route isn't changed.

----------

## gpeangel

 *nielchiano wrote:*   

> first of all, and completely off topic: it's more efficient to use TUN's instead of TAP's, unless you need tap for some reason, which I guess you don't, since you're routing.

 

I'll look into this. I have been using tap successfully for the better part of a year. My problems only occurred with this latest update to openvpn.

 *nielchiano wrote:*   

> 
> 
> The problem is, I think, here:
> 
> ```
> ...

 

I think this is correct. The static IP of the openvpn server is 10.10.10.6, so the destination value should be 10.10.10.0 on eth0. The openvpn interface, tap0, should be the vpn destination, 10.22.0.0 - that is if I'm understanding this correctly.

I'll dig deeper into your suggestions when I have more time this evening.

----------

## gpeangel

I may be getting to the problem. I've stripped the config files down to the bare minimum and fiddled with just a few parameters.

Server (gentoo, static IP 10.10.10.6 on eth0) config:

```
port 1194

proto udp

dev tun0

ca keys/ca.crt

cert keys/server.crt

key keys/server.key

dh keys/dh1024.pem

server 10.22.22.0 255.255.255.0

push "route 10.10.10.0"

push "route 10.22.22.0"

mode server

tls-server

duplicate-cn

keepalive 10 60

tls-auth keys/ta.key 0

comp-lzo

user nobody

group nobody

persist-tun

persist-key

status /var/log/openvpn/openvpn-status.log

log  /var/log/openvpn/openvpn.log

verb 6

mute 10

chroot /usr/local/openvpn
```

Client (Windows XP) config:

```
client

dev tun0

dev-node tun_tap_interface

proto udp

remote xxx.xxx.xxx.xxx 1194

nobind

persist-key

persist-tun

ca ca.crt

cert client_csgs.crt

key client_csgs.key

tls-auth ta.key 1

comp-lzo

verb 6

mute 10

pull
```

Client routing table before connect:

```
Active Routes:

Network Destination        Netmask          Gateway       Interface  Metric

          0.0.0.0          0.0.0.0        10.5.42.1     10.5.42.141       20

        10.5.42.0    255.255.255.0      10.5.42.141     10.5.42.141       20

      10.5.42.141  255.255.255.255        127.0.0.1       127.0.0.1       20

   10.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       20

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

    192.168.229.0    255.255.255.0    192.168.229.1   192.168.229.1       20

    192.168.229.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.229.255  255.255.255.255    192.168.229.1   192.168.229.1       20

    192.168.244.0    255.255.255.0    192.168.244.1   192.168.244.1       20

    192.168.244.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.244.255  255.255.255.255    192.168.244.1   192.168.244.1       20

        224.0.0.0        240.0.0.0      10.5.42.141     10.5.42.141       20

        224.0.0.0        240.0.0.0    192.168.229.1   192.168.229.1       20

        224.0.0.0        240.0.0.0    192.168.244.1   192.168.244.1       20

  255.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       1

  255.255.255.255  255.255.255.255    192.168.229.1   192.168.229.1       1

  255.255.255.255  255.255.255.255    192.168.244.1   192.168.244.1       1

  255.255.255.255  255.255.255.255    192.168.244.1               4       1

Default Gateway:         10.5.42.1
```

Client rout after connect:

```
Active Routes:

Network Destination        Netmask          Gateway       Interface  Metric

          0.0.0.0          0.0.0.0        10.5.42.1     10.5.42.141       20

        10.5.42.0    255.255.255.0      10.5.42.141     10.5.42.141       20

      10.5.42.141  255.255.255.255        127.0.0.1       127.0.0.1       20

       10.10.10.0  255.255.255.255       10.22.22.5      10.22.22.6       1

       10.22.22.0  255.255.255.255       10.22.22.5      10.22.22.6       1

       10.22.22.1  255.255.255.255       10.22.22.5      10.22.22.6       1

       10.22.22.4  255.255.255.252       10.22.22.6      10.22.22.6       30

       10.22.22.6  255.255.255.255        127.0.0.1       127.0.0.1       30

   10.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       20

   10.255.255.255  255.255.255.255       10.22.22.6      10.22.22.6       30

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

    192.168.229.0    255.255.255.0    192.168.229.1   192.168.229.1       20

    192.168.229.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.229.255  255.255.255.255    192.168.229.1   192.168.229.1       20

    192.168.244.0    255.255.255.0    192.168.244.1   192.168.244.1       20

    192.168.244.1  255.255.255.255        127.0.0.1       127.0.0.1       20

  192.168.244.255  255.255.255.255    192.168.244.1   192.168.244.1       20

        224.0.0.0        240.0.0.0      10.5.42.141     10.5.42.141       20

        224.0.0.0        240.0.0.0       10.22.22.6      10.22.22.6       30

        224.0.0.0        240.0.0.0    192.168.229.1   192.168.229.1       20

        224.0.0.0        240.0.0.0    192.168.244.1   192.168.244.1       20

  255.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       1

  255.255.255.255  255.255.255.255       10.22.22.6      10.22.22.6       1

  255.255.255.255  255.255.255.255    192.168.229.1   192.168.229.1       1

  255.255.255.255  255.255.255.255    192.168.244.1   192.168.244.1       1

Default Gateway:         10.5.42.1
```

Note the line for the 10.10.10.0 network destination. That doesn't look right. 10.22.22.5 for the gateway?

Client connect log:

```
Thu Feb 02 12:54:48 2006 us=642182 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.22.22.6/255.255.255.252 on interface {EF52698D-BA16-45EE-A419-C5F35957A610} [DHCP-serv: 10.22.22.5, lease-time: 31536000]

Thu Feb 02 12:54:48 2006 us=648592 Successful ARP Flush on interface [4] {EF52698D-BA16-45EE-A419-C5F35957A610}

Thu Feb 02 12:54:48 2006 us=668101 UDPv4 WRITE [50] to xxx.xxx.xxx.xxx:1194: P_ACK_V1 kid=0 pid=[ #58 ] [ 30 ]

Thu Feb 02 12:54:48 2006 us=809427 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down

Thu Feb 02 12:54:48 2006 us=809474 Route: Waiting for TUN/TAP interface to come up...

Thu Feb 02 12:54:49 2006 us=992127 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down

Thu Feb 02 12:54:49 2006 us=992175 Route: Waiting for TUN/TAP interface to come up...

Thu Feb 02 12:54:51 2006 us=172788 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down

Thu Feb 02 12:54:51 2006 us=172837 Route: Waiting for TUN/TAP interface to come up...

Thu Feb 02 12:54:52 2006 us=352383 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down

Thu Feb 02 12:54:52 2006 us=352431 Route: Waiting for TUN/TAP interface to come up...

Thu Feb 02 12:54:53 2006 us=535772 TEST ROUTES: 0/0 succeeded len=3 ret=0 a=0 u/d=down

Thu Feb 02 12:54:53 2006 us=535818 Route: Waiting for TUN/TAP interface to come up...

Thu Feb 02 12:54:54 2006 us=715810 TEST ROUTES: 3/3 succeeded len=3 ret=1 a=0 u/d=up

Thu Feb 02 12:54:54 2006 us=715870 route ADD 10.10.10.0 MASK 255.255.255.255 10.22.22.5

Thu Feb 02 12:54:54 2006 us=725511 Route addition via IPAPI succeeded

Thu Feb 02 12:54:54 2006 us=725568 route ADD 10.22.22.0 MASK 255.255.255.255 10.22.22.5

Thu Feb 02 12:54:54 2006 us=735388 Route addition via IPAPI succeeded

Thu Feb 02 12:54:54 2006 us=735444 route ADD 10.22.22.1 MASK 255.255.255.255 10.22.22.5

Thu Feb 02 12:54:54 2006 us=744646 Route addition via IPAPI succeeded

Thu Feb 02 12:54:54 2006 us=744696 Initialization Sequence Completed
```

I don't know where the 10.22.22.5 IP is coming from.

Server after connect:

```
# ping 10.22.22.6

PING 10.22.22.6 (10.22.22.6) 56(84) bytes of data.

64 bytes from 10.22.22.6: icmp_seq=1 ttl=128 time=95.1 ms

64 bytes from 10.22.22.6: icmp_seq=2 ttl=128 time=92.0 ms

64 bytes from 10.22.22.6: icmp_seq=3 ttl=128 time=93.3 ms

--- 10.22.22.6 ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2011ms

rtt min/avg/max/mdev = 92.034/93.511/95.126/1.290 ms
```

So I can ping the client from the server when openvpn is connected. I couldn't when it was disconnected.

However, what I noticed on the client both before and after connect:

```
ping 10.10.10.1

Pinging 10.10.10.1 with 32 bytes of data:

Reply from 10.10.10.1: bytes=32 time=20ms TTL=250

Reply from 10.10.10.1: bytes=32 time=21ms TTL=250

Reply from 10.10.10.1: bytes=32 time=19ms TTL=250

Reply from 10.10.10.1: bytes=32 time=32ms TTL=250

Ping statistics for 10.10.10.1:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 19ms, Maximum = 32ms, Average = 23ms

    

ping 10.10.10.6

Pinging 10.10.10.6 with 32 bytes of data:

Reply from 10.10.10.6: bytes=32 time=29ms TTL=54

Reply from 10.10.10.6: bytes=32 time=28ms TTL=54

Reply from 10.10.10.6: bytes=32 time=28ms TTL=54

Reply from 10.10.10.6: bytes=32 time=28ms TTL=54

Ping statistics for 10.10.10.6:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 28ms, Maximum = 29ms, Average = 28ms
```

My thinking now is that coincident with the openvpn update, a 10.10.10.x network has been introduced on the client side of the connection and is therefore causing the routing conflict. Both 10.10.10.1 and 10.10.10.6 can be pinged from a different computer on the client network. Would this be accurate?  If so, what are my options? Would I have to re-configure the network on which the openvpn server resides?

----------

## Zeos

If it makes ya feel any better, I've been dealing with the exact same thing here since the last update I took. Fortunatly, it's not vital here so I've stuck it in the "it'll have to wait" todo list  :Sad: 

----------

## nielchiano

ok, I'm a bit confused. (don't worry, my exams are just finished, it's not your fault)

If I understand your config correctly, you have an internal VPN server, 10.10.10.6.

you try to connect to it from a winXP client. WHERE is that client? I suppose somewhere else on the internal network?

On the routing output of the client, I see that it already has 3 IP's assigned. is that how it's supposed to be?

the "push route" lines in the server config are probably wrong: man openvpn tells me: *Quote:*   

> --route network/IP [netmask] [gateway] [metric]
> 
> Add route to routing table after connection is established.  Multiple routes can be specified.  Routes will be automatically torn down in  reverse order prior to TUN/TAP device close.
> 
> This  option  is  intended as a convenience proxy for the route( shell command, while at the same time providing portable semantics across Open-VPN's platform space.
> ...

 

if you only specify an IP the default netmask is 255.255.255.255, which is what I see in the route-output.

the 10.22.22.5 comes from here: *man wrote:*   

> Since the TAP-Win32 driver exports an ethernet interface to Windows, and since TUN devices are point-to-point in nature, it is necessary for the TAP-Win32 driver to impose certain constraints on TUN endpoint address selection.
> 
> Namely, the point-to-point endpoints used in TUN device emulation must be the middle two addresses of a /30 subnet (netmask 255.255.255.252).
> 
> 

 

since you've got 10.22.22.6, the corresponding .1 address is the 10.22.22.5 you see. This is "normal".

try pinging 10.22.22.5 from the client when connected. That has to work, since you could do the ping server to client.

Do you want your VPN-clients to be able to talk to eachother? or only the the network?

next, change your server config. remove all "push routes" and add this one

```

push "route 10.10.10.0 255.255.255.0"

```

What exactly are you trying to VPN? since, if you're able to connect to 10.10.10.1, you'd also be able to connect to 10.10.10.* without the need to VPN.

If you can reach something via 2 ways (i.e. non-VPN'ed and VPN'ed), the routing tables decide which way it will take.

If you give some more info on the questions in this post, I might be able to get you further.

----------

## gpeangel

 *Quote:*   

> If I understand your config correctly, you have an internal VPN server, 10.10.10.6.
> 
> you try to connect to it from a winXP client. WHERE is that client? I suppose somewhere else on the internal network? 

 

Yes some clarification would help. The internal VPN server (gentoo) is 10.10.10.6. The client (WinXP) is on an entirely different network. The client is not on the internal network (although I have the same issue with clients that are on the internal network, VPN connectivity in those cases is a minor concern and will probably be sorted out when I understand what is happening with the remote client.)

 *Quote:*   

> On the routing output of the client, I see that it already has 3 IP's assigned. is that how it's supposed to be? 

 

I don't think so. I had VMWare Player installed on the box which installs two virtual adaptors (VMware Virtual Ethernet Adapter for VMnet8). I've since uninstalled VMWare Player in an effort to simplify the environment. The routing table for the client, before attempting to connect to the VPN server, now shows:

```
===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x4 ...00 ff ef 52 69 8d ...... TAP-Win32 Adapter V8

0x10006 ...00 08 74 aa 9c 9c ...... Intel(R) PRO/1000 MT Network Connection

===========================================================================

===========================================================================

Active Routes:

Network Destination        Netmask          Gateway       Interface  Metric

          0.0.0.0          0.0.0.0        10.5.42.1     10.5.42.141       20

        10.5.42.0    255.255.255.0      10.5.42.141     10.5.42.141       20

      10.5.42.141  255.255.255.255        127.0.0.1       127.0.0.1       20

   10.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       20

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

        224.0.0.0        240.0.0.0      10.5.42.141     10.5.42.141       20

  255.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       1

  255.255.255.255  255.255.255.255      10.5.42.141               4       1

Default Gateway:         10.5.42.1

===========================================================================

Persistent Routes:

  None
```

...and ipconfig /all shows:

```
Windows IP Configuration

        Host Name . . . . . . . . . . . . : user01-xp

        Primary Dns Suffix  . . . . . . . : somewhere.com

        Node Type . . . . . . . . . . . . : Hybrid

        IP Routing Enabled. . . . . . . . : No

        WINS Proxy Enabled. . . . . . . . : No

        DNS Suffix Search List. . . . . . : somewhere.com

                                            somewhere.com

                                            somewhere.com

Ethernet adapter tun_tap_interface:

        Media State . . . . . . . . . . . : Media disconnected

        Description . . . . . . . . . . . : TAP-Win32 Adapter V8

        Physical Address. . . . . . . . . : 00-FF-EF-52-69-8D

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : somewhere.com

        Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection

        Physical Address. . . . . . . . . : 00-08-74-AA-9C-9C

        Dhcp Enabled. . . . . . . . . . . : Yes

        Autoconfiguration Enabled . . . . : Yes

        IP Address. . . . . . . . . . . . : 10.5.42.141

        Subnet Mask . . . . . . . . . . . : 255.255.255.0

        Default Gateway . . . . . . . . . : 10.5.42.1

        DHCP Server . . . . . . . . . . . : 10.5.10.13

        DNS Servers . . . . . . . . . . . : 10.5.10.10

                                            10.10.10.10

        Primary WINS Server . . . . . . . : 10.10.9.13

        Secondary WINS Server . . . . . . : 10.8.12.36

        Lease Obtained. . . . . . . . . . : Monday, February 06, 2006 10:46:31 AM

        Lease Expires . . . . . . . . . . : Friday, February 10, 2006 10:46:31 AM
```

And on the server, openvpn not started and before the client attempts to connect:

```
# route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.10.10.0      *               255.255.255.0   U     0      0        0 eth0

loopback        localhost       255.0.0.0       UG    0      0        0 lo

default         10.10.10.1      0.0.0.0         UG    0      0        0 eth0
```

```
# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:50:2C:A5:B9:70

          inet addr:10.10.10.6  Bcast:10.10.10.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:23513145 errors:0 dropped:0 overruns:0 frame:6

          TX packets:19688929 errors:0 dropped:0 overruns:0 carrier:0

          collisions:724101 txqueuelen:1000

          RX bytes:3005974241 (2866.7 Mb)  TX bytes:1327212854 (1265.7 Mb)

          Interrupt:17 Base address:0x2000

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:1774552 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1774552 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:662142054 (631.4 Mb)  TX bytes:662142054 (631.4 Mb)
```

On the server after starting openvpn:

```
# openvpn.conf

port 1194

proto udp

dev tun0

ca keys/ca.crt

cert keys/server.crt

key keys/server.key

dh keys/dh1024.pem

server 10.22.22.0 255.255.255.0

mode server

tls-server

push "route 10.10.10.0"

push "route 10.22.22.0"

duplicate-cn

keepalive 10 60

tls-auth keys/ta.key 0

comp-lzo

user nobody

group nobody

persist-tun

persist-key

status /var/log/openvpn/openvpn-status.log

log  /var/log/openvpn/openvpn.log

verb 6

mute 10

chroot /usr/local/openvpn
```

```
# route

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

10.22.22.2      *               255.255.255.255 UH    0      0        0 tun0

10.22.22.0      10.22.22.2      255.255.255.0   UG    0      0        0 tun0

10.10.10.0      *               255.255.255.0   U     0      0        0 eth0

loopback        localhost       255.0.0.0       UG    0      0        0 lo

default         10.10.10.1      0.0.0.0         UG    0      0        0 eth0
```

```
# ifconfig

eth0      Link encap:Ethernet  HWaddr 00:50:2C:A5:B9:70

          inet addr:10.10.10.6  Bcast:10.10.10.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:23515882 errors:0 dropped:0 overruns:0 frame:6

          TX packets:19690667 errors:0 dropped:0 overruns:0 carrier:0

          collisions:724101 txqueuelen:1000

          RX bytes:3006221038 (2866.9 Mb)  TX bytes:1327361674 (1265.8 Mb)

          Interrupt:17 Base address:0x2000

lo        Link encap:Local Loopback

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1

          RX packets:1774752 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1774752 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:662159782 (631.4 Mb)  TX bytes:662159782 (631.4 Mb)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

          inet addr:10.22.22.1  P-t-P:10.22.22.2  Mask:255.255.255.255

          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  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:100

          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
```

Now I try and connect the client:

```
# client config

client

dev tun0

dev-node tun_tap_interface

proto udp

remote xxx.xxx.xxx.xxx 1194

nobind

persist-key

persist-tun

ca ca.crt

cert client_csgs.crt

key client_csgs.key

tls-auth ta.key 1

comp-lzo

verb 6

mute 10

pull
```

```
===========================================================================

Interface List

0x1 ........................... MS TCP Loopback interface

0x4 ...00 ff ef 52 69 8d ...... TAP-Win32 Adapter V8

0x10006 ...00 08 74 aa 9c 9c ...... Intel(R) PRO/1000 MT Network Connection

===========================================================================

===========================================================================

Active Routes:

Network Destination        Netmask          Gateway       Interface  Metric

          0.0.0.0          0.0.0.0        10.5.42.1     10.5.42.141       20

        10.5.42.0    255.255.255.0      10.5.42.141     10.5.42.141       20

      10.5.42.141  255.255.255.255        127.0.0.1       127.0.0.1       20

       10.22.22.1  255.255.255.255       10.22.22.5      10.22.22.6       1

       10.22.22.4  255.255.255.252       10.22.22.6      10.22.22.6       30

       10.22.22.6  255.255.255.255        127.0.0.1       127.0.0.1       30

   10.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       20

   10.255.255.255  255.255.255.255       10.22.22.6      10.22.22.6       30

        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1

        224.0.0.0        240.0.0.0      10.5.42.141     10.5.42.141       20

        224.0.0.0        240.0.0.0       10.22.22.6      10.22.22.6       30

  255.255.255.255  255.255.255.255      10.5.42.141     10.5.42.141       1

  255.255.255.255  255.255.255.255       10.22.22.6      10.22.22.6       1

Default Gateway:         10.5.42.1

===========================================================================

Persistent Routes:

  None
```

```
Windows IP Configuration

        Host Name . . . . . . . . . . . . : user01-xp

        Primary Dns Suffix  . . . . . . . : somewhere.com

        Node Type . . . . . . . . . . . . : Hybrid

        IP Routing Enabled. . . . . . . . : No

        WINS Proxy Enabled. . . . . . . . : No

        DNS Suffix Search List. . . . . . : somewhere.com

                                            somewhere.com

                                            somewhere.com

Ethernet adapter tun_tap_interface:

        Connection-specific DNS Suffix  . :

        Description . . . . . . . . . . . : TAP-Win32 Adapter V8

        Physical Address. . . . . . . . . : 00-FF-EF-52-69-8D

        Dhcp Enabled. . . . . . . . . . . : Yes

        Autoconfiguration Enabled . . . . : Yes

        IP Address. . . . . . . . . . . . : 10.22.22.6

        Subnet Mask . . . . . . . . . . . : 255.255.255.252

        Default Gateway . . . . . . . . . :

        DHCP Server . . . . . . . . . . . : 10.22.22.5

        Lease Obtained. . . . . . . . . . : Tuesday, February 07, 2006 10:36:57 AM

        Lease Expires . . . . . . . . . . : Wednesday, February 07, 2007 10:36:57 AM

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : somewhere.com

        Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Network Connection

        Physical Address. . . . . . . . . : 00-08-74-AA-9C-9C

        Dhcp Enabled. . . . . . . . . . . : Yes

        Autoconfiguration Enabled . . . . : Yes

        IP Address. . . . . . . . . . . . : 10.5.42.141

        Subnet Mask . . . . . . . . . . . : 255.255.255.0

        Default Gateway . . . . . . . . . : 10.5.42.1

        DHCP Server . . . . . . . . . . . : 10.5.10.13

        DNS Servers . . . . . . . . . . . : 10.5.10.10

                                            10.10.10.10

        Primary WINS Server . . . . . . . : 10.10.9.13

        Secondary WINS Server . . . . . . : 10.8.12.36

        Lease Obtained. . . . . . . . . . : Monday, February 06, 2006 10:46:31 AM

        Lease Expires . . . . . . . . . . : Friday, February 10, 2006 10:46:31 AM
```

 *Quote:*   

> try pinging 10.22.22.5 from the client when connected. That has to work, since you could do the ping server to client. 

 

While I can ping the client from the server...

```
# ping 10.22.22.6

PING 10.22.22.6 (10.22.22.6) 56(84) bytes of data.

64 bytes from 10.22.22.6: icmp_seq=1 ttl=128 time=93.4 ms

64 bytes from 10.22.22.6: icmp_seq=2 ttl=128 time=91.5 ms

64 bytes from 10.22.22.6: icmp_seq=3 ttl=128 time=91.8 ms

64 bytes from 10.22.22.6: icmp_seq=4 ttl=128 time=90.8 ms

--- 10.22.22.6 ping statistics ---

4 packets transmitted, 4 received, 0% packet loss, time 3017ms

rtt min/avg/max/mdev = 90.860/91.927/93.456/0.949 ms
```

...pinging 10.22.22.5 fails on the client.

```
Pinging 10.22.22.5 with 32 bytes of data:

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Ping statistics for 10.22.22.5:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
```

 *Quote:*   

> Do you want your VPN-clients to be able to talk to eachother? or only the the network? 

 

I only want the clients to have access to the network (and the VPN server) and not each other.

 *Quote:*   

> What exactly are you trying to VPN? since, if you're able to connect to 10.10.10.1, you'd also be able to connect to 10.10.10.* without the need to VPN.
> 
> If you can reach something via 2 ways (i.e. non-VPN'ed and VPN'ed), the routing tables decide which way it will take. 

 

Not sure what you are asking with the first question. Prior to this upgrade, I would set up a VPN between the remote client and the openvpn server which allowed me ssh and ftp connections. As I mentioned before, since the client is on a completely separate network, the fact I can ping a 10.10.10.1 address when disconnected from the openvpn server suggests there is another box somewhere on the remote connection with the same static IP address as the openvpn server (again, on a completely separate network.) I definitely do not want to connect to any 10.10.10.* boxes on the remote (client) network. After connecting to the openvpn server, I cannot ping the 10.10.10.1 server using the route line you suggested (push "route 10.10.10.0 255.255.255.0" )

I still don't understand the 10.22.22.4 address that shows up in the client route table after connecting to the openvpn server.

I'll keep plugging away at finding an answer...

----------

## nielchiano

 *gpeangel wrote:*   

>  *Quote:*   If I understand your config correctly, you have an internal VPN server, 10.10.10.6.
> 
> you try to connect to it from a winXP client. WHERE is that client? I suppose somewhere else on the internal network?  
> 
> Yes some clarification would help. The internal VPN server (gentoo) is 10.10.10.6. The client (WinXP) is on an entirely different network. The client is not on the internal network (although I have the same issue with clients that are on the internal network, VPN connectivity in those cases is a minor concern and will probably be sorted out when I understand what is happening with the remote client.)

 

 *Quote:*   

>  *Quote:*   
> 
> What exactly are you trying to VPN? since, if you're able to connect to 10.10.10.1, you'd also be able to connect to 10.10.10.* without the need to VPN.
> 
> If you can reach something via 2 ways (i.e. non-VPN'ed and VPN'ed), the routing tables decide which way it will take. Not sure what you are asking with the first question. Prior to this upgrade, I would set up a VPN between the remote client and the openvpn server which allowed me ssh and ftp connections. As I mentioned before, since the client is on a completely separate network, the fact I can ping a 10.10.10.1 address when disconnected from the openvpn server suggests there is another box somewhere on the remote connection with the same static IP address as the openvpn server (again, on a completely separate network.) I definitely do not want to connect to any 10.10.10.* boxes on the remote (client) network. After connecting to the openvpn server, I cannot ping the 10.10.10.1 server using the route line you suggested (push "route 10.10.10.0 255.255.255.0" ) 

 

Ok, I was a bit confused because both the client and the server had non-routable IP-addresses. I asumed (wrong) that they should be on the same network.

I suppose that all NAT-issues are solved, since you can connect.

You are aware that when you have overlapping IP's, you have to choose which ones you route: as you say, if both the "client-network" and the "server-network" have a machine with IP 10.11.12.13, you'll have to decide which one you want.

 *Quote:*   

> I still don't understand the 10.22.22.4 address that shows up in the client route table after connecting to the openvpn server.

 

I can explain that: *man page wrote:*   

> Since the TAP-Win32 driver exports an ethernet interface to Windows, and since TUN devices are point-to-point in nature, it is necessary for the TAP-Win32 driver to impose certain constraints on TUN endpoint address selection.
> 
> Namely, the point-to-point endpoints used in TUN device emulation must be the middle two addresses of a /30 subnet (netmask 255.255.255.252).

 

Apparently, you've got IP 10.22.22.6, which is part of the network 10.22.22.4/30 (containing 10.22.22.4, .5, .6 and .7; .4 is the network address, .7 the broadcast address, .5 and .6 the only 2 usable addresses).

The routing table specifies that you can reach this network (i.e. the one other host on it = the server) via the tunnel device, directly.

Things to try:

* remove the "push route ..." for now, we'll add them later

* try to ping from the client to 10.22.22.1 (I tried this at home, it should work)

* decide what IP-ranges should stay mapped the the "client network" and what IP-ranges should be VPN'ed to the server network. If I understand you right, you only want 10.10.10.* to be VPN'ed, and the rest not. Am I correct?

If I am, add the following line to the server:

```

push "route 10.10.10.0 255.255.255.0"
```

that should tell the client to alter it's routing table so that 10.10.10.* will be routed through the tunnel.

* Try to ping your server's IP on that network 10.10.10.6

* try to ping another machine on that network (eg 10.10.10. :Cool: 

let me know how it worked out

----------

## gpeangel

I took out all "push" commands from the server config and connected. Client log shows:

```
Tue Feb 07 15:48:53 2006 us=314540 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up

Tue Feb 07 15:48:53 2006 us=314597 route ADD 10.22.22.1 MASK 255.255.255.255 10.22.22.5

Tue Feb 07 15:48:53 2006 us=322114 Route addition via IPAPI succeeded

Tue Feb 07 15:48:53 2006 us=322161 Initialization Sequence Completed
```

 *Quote:*   

> 
> 
> * try to ping from the client to 10.22.22.1 (I tried this at home, it should work) 

 

Yes, I can ping 10.22.22.1 from the client.

 *Quote:*   

> * decide what IP-ranges should stay mapped the the "client network" and what IP-ranges should be VPN'ed to the server network. If I understand you right, you only want 10.10.10.* to be VPN'ed, and the rest not. Am I correct? 

 

You are correct.

 *Quote:*   

> If I am, add the following line to the server:
> 
> ```
> push "route 10.10.10.0 255.255.255.0"
> ```
> ...

 

Added the line to the server config, restarted openvpn, reconnected client. Client log reports:

```
Tue Feb 07 15:53:41 2006 us=883936 Route: Waiting for TUN/TAP interface to come up...

Tue Feb 07 15:53:43 2006 us=46343 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up

Tue Feb 07 15:53:43 2006 us=46396 route ADD 10.10.10.0 MASK 255.255.255.0 10.22.22.5

Tue Feb 07 15:53:43 2006 us=54164 Route addition via IPAPI succeeded

Tue Feb 07 15:53:43 2006 us=54215 route ADD 10.22.22.1 MASK 255.255.255.255 10.22.22.5

Tue Feb 07 15:53:43 2006 us=61606 Route addition via IPAPI succeeded

Tue Feb 07 15:53:43 2006 us=61656 Initialization Sequence Completed
```

I can ping 10.22.22.6 (client) from the VPN server. I can ping 10.22.22.1 from the client and I can ping 10.10.10.6. But how do I know I'm pinging the VPN server and not some other 10.10.10.6 that's on the same network as the client. As I mentioned before, I can ping 10.10.10.6 whether I'm connected to the VPN server or not.

I cannot connect to 10.10.10.6 either by ssh or ftp.

Since my previous post, I tried shutting down the dhcp and proxy servers running on the VPN server just as a test. This didn't help and seemed to make the routing more confusing to me. Besides, both these services had been running successfully aside OpenVPN prior to the emerge upgrade.

Thanks...

----------

## nielchiano

 *gpeangel wrote:*   

> I can ping 10.22.22.6 (client) from the VPN server. I can ping 10.22.22.1 from the client and I can ping 10.10.10.6. But how do I know I'm pinging the VPN server and not some other 10.10.10.6 that's on the same network as the client. As I mentioned before, I can ping 10.10.10.6 whether I'm connected to the VPN server or not.

 

you could use traceroute (or tracert under windows) to find out which route the packet takes. that way you can see if the first router is the VPN server, or the default GW of the "client-network".

let me know

----------

## gpeangel

Here's the trace route information. From the remote client and before connecting to VPN server:

```
>ping 10.10.10.6

Pinging 10.10.10.6 with 32 bytes of data:

Reply from 10.10.10.6: bytes=32 time=27ms TTL=54

Reply from 10.10.10.6: bytes=32 time=32ms TTL=54

Reply from 10.10.10.6: bytes=32 time=29ms TTL=54

Reply from 10.10.10.6: bytes=32 time=28ms TTL=54

Ping statistics for 10.10.10.6:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 27ms, Maximum = 32ms, Average = 29ms
```

```
>tracert 10.10.10.6

Tracing route to snpsf05.somewhere.com [10.10.10.6]

over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.5.42.2

  2    <1 ms    <1 ms    <1 ms  10.5.3.3

  3    <1 ms    <1 ms    <1 ms  10.5.4.2

  4    <1 ms    <1 ms    <1 ms  192.168.10.213

  5     1 ms    <1 ms    <1 ms  10.8.2.6

  6    19 ms    19 ms    19 ms  192.168.10.53

  7    19 ms    20 ms    19 ms  10.10.100.10

  8    26 ms    28 ms    28 ms  snpsf05.somewhere.com [10.10.10.6]

Trace complete.
```

From the remote client and after connecting to VPN server:

```
>ping 10.10.10.6

Pinging 10.10.10.6 with 32 bytes of data:

Reply from 10.10.10.6: bytes=32 time=130ms TTL=64

Reply from 10.10.10.6: bytes=32 time=83ms TTL=64

Reply from 10.10.10.6: bytes=32 time=85ms TTL=64

Reply from 10.10.10.6: bytes=32 time=83ms TTL=64

Ping statistics for 10.10.10.6:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 83ms, Maximum = 130ms, Average = 95ms
```

```
>tracert 10.10.10.6

Tracing route to snpsf05.somewhere.com [10.10.10.6]

over a maximum of 30 hops:

  1    85 ms    83 ms    84 ms  snpsf05.somewhere.com [10.10.10.6]

Trace complete.
```

Note the path to the remote client 10.10.10.6 box is shorter - no hops - when connected to the VPN server. From the remote client and after disconnecting to VPN server:

```
>tracert 10.10.10.6

Tracing route to snpsf05.somewhere.com [10.10.10.6]

over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.5.42.2

  2    <1 ms    <1 ms    <1 ms  10.5.3.3

  3    <1 ms    <1 ms    <1 ms  10.5.4.2

  4    <1 ms    <1 ms    <1 ms  192.168.10.213

  5     1 ms    <1 ms    <1 ms  10.8.2.6

  6    20 ms    19 ms    19 ms  192.168.10.53

  7    19 ms    19 ms    19 ms  10.10.100.10

  8    27 ms    28 ms    28 ms  snpsf05.somewhere.com [10.10.10.6]

Trace complete.
```

So it would appear the VPN server routing is not overriding the routing on the remote client network. Is there a way to accomplish this? I do not need access to the 10.10.10.X addresses on the remote client network while connected to the VPN server. Worst case, I suppose I'll have to change the address space of the network on which the VPN server resides. Ouch.

----------

## nielchiano

 *gpeangel wrote:*   

> So it would appear the VPN server routing is not overriding the routing on the remote client network. Is there a way to accomplish this? I do not need access to the 10.10.10.X addresses on the remote client network while connected to the VPN server. Worst case, I suppose I'll have to change the address space of the network on which the VPN server resides. Ouch.

 

well, to me it looks like it DOES!

since you've reached 10.10.10.6 in 1 hop, it means you are directly connected to it: i.e. you have an interface (the tunnel) that directly brings you there. (yes, the tunnel itself is more hops, but since you're "in a tunnel", you can't see these hops)

So it looks like your tunnel is indeed set up correctly, and the routes are pushed as they should; unless I'm misunderstanding something?

----------

## gpeangel

Maybe it is I who is foggy on the concepts. As I understand it, there are three (at least) boxes in play.

My VPN server with a static IP of 10.10.10.6 (named "STEEL") on NETWORK 1.

A client (WinXP) with a dynamic IP on NETWORK 2.

Some mystery box with a static IP of 10.10.10.6 (named "snpsf05.somewhere.com") on NETWORK 2.

Once I connect to the VPN server (STEEL), I would expect tracert to not hop across any of the boxes on NETWORK 2 if it is properly routed, via the VPN, to NETWORK 1. In otherwords, I shouldn't see it hop across snpsf05.somewhere.com (10.10.10.6 on NETWORK 2)

I have no idea what's installed on snpsf05.somewhere.com and it is not the box I wish to connect to. I want to ssh, for exampe, to 10.10.10.6 (STEEL) on NETWORK 1, not 10.10.10.6 (snpsf05.somewhere.com) on NETWORK 2.

What am I missing?

----------

## nielchiano

 *gpeangel wrote:*   

> 
> 
> ```
> >tracert 10.10.10.6
> 
> ...

 

I think I get your problem:

The thing you'd expect to see is the traceroute WITHOUT "snpsf05.somewhere.com", right?

Well, don't bother: you ARE connected to YOUR server "STEEL", only the client tries to do a reverse lookup on the IP to get a name. And the DNS-server on NETWORK 2 tells your client that, according to his database (which is NETWORK2's database) 10.10.10.6 has the name of "snpsf05.somewhere.com".

However, this DOES NOT mean that you are CONNECTED to that computer!

Does this make things more clear?

----------

## gpeangel

 *nielchiano wrote:*   

> I think I get your problem:
> 
> The thing you'd expect to see is the traceroute WITHOUT "snpsf05.somewhere.com", right?

 

That's right.

 *nielchiano wrote:*   

> Well, don't bother: you ARE connected to YOUR server "STEEL", only the client tries to do a reverse lookup on the IP to get a name. And the DNS-server on NETWORK 2 tells your client that, according to his database (which is NETWORK2's database) 10.10.10.6 has the name of "snpsf05.somewhere.com".
> 
> However, this DOES NOT mean that you are CONNECTED to that computer!
> 
> Does this make things more clear?

 

OK, this makes sense. However, after I've connected and I attempt to connect to STEEL via ssh, ftp or http I get no response from STEEL. Looking at STEEL's logs, I see no evidence of any type of attempt to connect - nothing in the http logs, nothing in the syslogs, nothing from SNORT - nothing. Coming straight into STEEL from the Internet via the remote client machine, my logs still show http activity and attempts at trying to connect via ssh in both the syslogs and SNORT. This suggests that, appearences to the contrary, I'm actually not routed correctly to STEEL from the remote client machine. That I can ping the remote client from STEEL suggests that part of the routing works.

I don't have access to the mystery 10.10.10.6 box on the remote network (the same network as the remote client), or I would check the logs on that box for connection attempts.

----------

## nielchiano

 *gpeangel wrote:*   

> However, after I've connected and I attempt to connect to STEEL via ssh, ftp or http I get no response from STEEL. Looking at STEEL's logs, I see no evidence of any type of attempt to connect - nothing in the http logs, nothing in the syslogs, nothing from SNORT - nothing. Coming straight into STEEL from the Internet via the remote client machine, my logs still show http activity and attempts at trying to connect via ssh in both the syslogs and SNORT. This suggests that, appearences to the contrary, I'm actually not routed correctly to STEEL from the remote client machine. That I can ping the remote client from STEEL suggests that part of the routing works.

 

Hmm... The fact that you can ping to it, show that the routing is OK. If you want to be sure, run tcpdump (or SNORT or ...) on STEEL to confirm that.

The fact that you can't connect to the computer is strange. First make sure that the services are listening on ALL interfaces (i.e.: not only on 10.10.10.6).

Next: Are you trying to connect to 10.10.10.6? or to 10.22.22.1? or to the (internet)IP of STEEL? or using some DNS name?

I suggest trying one of the 2 IP's. Normaly both should work.

Check the firewall on STEEL (if any, and I hope there is) to see if he allows it? I'm not sure where SNORT is in this, but it might be possible to drop the packet even before SNORT sees it.

Again, to be sure, run tcpdump on STEEL, on the tun device and see if connection requests enter.

----------

## gpeangel

 *nielchiano wrote:*   

> Hmm... The fact that you can ping to it, show that the routing is OK. If you want to be sure, run tcpdump (or SNORT or ...) on STEEL to confirm that.

 

I think this shows the routing on STEEL is good, but not on the remote client side of the connection.

 *nielchiano wrote:*   

> The fact that you can't connect to the computer is strange. First make sure that the services are listening on ALL interfaces (i.e.: not only on 10.10.10.6).

 

They are. Sticking with ssh as an example (the only service on really want to connect to on STEEL from the remote client), sshd_config is set to the default: 0.0.0.0

 *nielchiano wrote:*   

> Next: Are you trying to connect to 10.10.10.6? or to 10.22.22.1? or to the (internet)IP of STEEL? or using some DNS name?
> 
> I suggest trying one of the 2 IP's. Normaly both should work.

 

Trying to connect to ssh on 10.10.10.6 and 10.22.22.1 both fail. I can connect to ssh from the Internet IP (public). Haven't tried DNS name, usually prefer to use the IP.

 *nielchiano wrote:*   

> Check the firewall on STEEL (if any, and I hope there is) to see if he allows it? I'm not sure where SNORT is in this, but it might be possible to drop the packet even before SNORT sees it.

 

There are actually two firewalls   :Very Happy:  . One on an intervening wireless gateway and one on STEEL. Both ssh and openvpn are allowed on each firewall. Neither of these firewall settings have changed since this problem occured and openvpn had been working for close to year prior to this issue.

 *nielchiano wrote:*   

> Again, to be sure, run tcpdump on STEEL, on the tun device and see if connection requests enter.

 

Neither tcpdump or SNORT register any connection attempt on ssh via the tun interface.

I still believe the client is trying to connect ssh to the 10.10.10.6 box on its remote network. Again, since I don't have access to that box, I don't even know where it is located, I cannot confirm that.

I have a second gentoo server (BRONZE) on the same network as STEEL with a different private IP, an IP that so far doesn't exist on the remote client network. This weekend, I'll try setting up openvpn on that box and try a remote connection to BRONZE. I've tried building the server and client config files up from scratch in the process of trying to connect to STEEL and everything I've been able to read says I have the configurations set correctly so I've run out of things to try.

----------

## nielchiano

currently I'm also out of ideas... try that BRONZE-thing... I'll think about other things that can go wrong.

----------

## gpeangel

After sifting through bunches of tcpdump and trace files I believe the problems I was having were ultimately related to a firewall issue. It was only after I basically rebuilt my firewall rules that I managed to get OpenVPN running again. I can now connect to the OpenVPN server via the tap0 interface.

----------

