opvnvpn: addressing nodes in LAN-behinds

Question

I've setup an openvpn server which i can access remotely, once it is connected, it creates a tun0 device on both server and client with virtual ip 10.15.119.x. the openvpn server is itself 10.15.119.1.

Question: how do i address other nodes in the lan behind the openvpn server? i can access services on the openvpn server itself with the address 10.15.119.1:(port), but i don't know how to address other nodes not partaking in the openvpn connection that are in the same LAN as the openvpn server: I would hope that such nodes can be addressed from the client node with some other virtual ip in the 10.15.119.x range, and if that is the case, i would only need a way to know what those ip are

i very well could create some iptables and route commands to forward ports to other specific nodes, but i'm sure there has to be a nicer way to do it, addressing directly the nodes

server.conf:

dev tun
server 10.15.119.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
up ./office.up 
tls-server
dh /home/lurscher/keys/dh1024.pem
ca /home/lurscher/keys/ca.crt
cert /home/lurscher/keys/vpnCh8TestServer.crt
key /home/lurscher/keys/vpnCh8TestServer.key
status openvpn-status.log
log         openvpn.log
comp-lzo
verb 3

the office.up script has:

#!/bin/sh
#route 10.15.119.0 255.255.255.0
route add -net 10.15.119.0 netmask 255.255.255.0 gw $5 #fixed the wrong 10.15.0.0 address

client.conf instead has:

dev tun
remote my.server.com
tls-client
pull 
ca /home/chuckq/keys/ca.crt
cert /home/chuckq/keys/vpnCh8TestClient.crt
key /home/chuckq/keys/vpnCh8TestClient.key
ns-cert-type server
; port 1194
; user nobody
; group nogroup
status openvpn-status.log
log         openvpn.log
comp-lzo
verb 3

New relevant logs from server:

Thu May 26 16:59:59 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 PUSH: Received control message: 'PUSH_REQUEST'
Thu May 26 16:59:59 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 SENT CONTROL [vpnCh8TestClient]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5' (status=1)
Thu May 26 17:02:17 2011 vpnCh8TestClient/Y.Y.Y.Y:1194 Replay-window backtrack occurred [1]

relevant logs from client:

Thu May 26 16:53:30 2011 [vpnCh8TestServer] Peer Connection Initiated with [AF_INET]X.X.X.X:1194
Thu May 26 16:53:32 2011 SENT CONTROL [vpnCh8TestServer]: 'PUSH_REQUEST' (status=1)
Thu May 26 16:53:32 2011 PUSH: Received control message: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5'
Thu May 26 16:53:32 2011 OPTIONS IMPORT: --ifconfig/up options modified
Thu May 26 16:53:32 2011 OPTIONS IMPORT: route options modified
Thu May 26 16:53:32 2011 ROUTE default_gateway=10.21.2.254
Thu May 26 16:53:32 2011 TUN/TAP device tun0 opened
Thu May 26 16:53:32 2011 TUN/TAP TX queue length set to 100
Thu May 26 16:53:32 2011 /sbin/ifconfig tun0 10.15.119.6 pointopoint 10.15.119.5 mtu 1500
Thu May 26 16:53:32 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.15.119.5
Thu May 26 16:53:32 2011 /sbin/route add -net 10.15.119.1 netmask 255.255.255.255 gw 10.15.119.5
Thu May 26 16:53:32 2011 Initialization Sequence Completed

EDIT thanks to wolfgangsz which noticed a typo in the office.up, i tried again tracepath with no improvements:

$ tracepath 192.168.0.100
 1:  10.15.119.6                                              0.261ms pmtu 1500
 1:  10.15.119.1                                             88.989ms 
 1:  10.15.119.1                                             58.752ms 
 2:  no reply

note how different is the result when the ip is the one from the openvpn server

$ tracepath 192.168.0.101
 1:  10.15.119.6                                              0.308ms pmtu 1500
 1:  192.168.0.101                                       115.713ms reached
 1:  192.168.0.101                                        65.064ms reached
     Resume: pmtu 1500 hops 1 back 64

routing entries at the client:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.15.119.5     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.15.119.1     10.15.119.5     255.255.255.255 UGH   0      0        0 tun0
192.168.0.0     10.15.119.5     255.255.255.0   UG    0      0        0 tun0
10.21.2.0       0.0.0.0         255.255.255.0   U     1      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
0.0.0.0         10.21.2.254     0.0.0.0         UG    0      0        0 eth0

and routing entries at the (openvpn) server:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.15.119.2     0.0.0.0         255.255.255.255 UH    0      0        0 tun0
10.15.119.0     10.15.119.2     255.255.255.0   UG    0      0        0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 vboxnet0
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth1
0.0.0.0         0.0.0.0         0.0.0.0         U     1002   0        0 eth0
0.0.0.0         0.0.0.0         0.0.0.0         U     1004   0        0 vboxnet0

EDIT 2: i've checked that ip forwarding is enabled

$ cat /proc/sys/net/ipv4/ip_forward
1

here is the output of the iptables in the server:

$ sudo iptables -nv -L
Chain INPUT (policy DROP 1 packets, 52 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  eth0   *       127.0.0.1            0.0.0.0/0           
    0     0 DROP       all  --  eth0   *       0.0.0.0/0            127.0.0.1           
    0     0 DROP       all  --  eth0   *       192.168.0.0/16       0.0.0.0/0           
    0     0 DROP       all  --  eth0   *       172.16.0.0/12        0.0.0.0/0           
    0     0 DROP       all  --  eth0   *       10.0.0.0/8           0.0.0.0/0           
    8   416 ACCEPT     all  --  *      *       127.0.0.1            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            127.0.0.1           
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
   91  8915 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
  293 28499 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    1  1500 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tap+   *       0.0.0.0/0            0.0.0.0/0           
   18  2010 ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all  --  eth0   *       127.0.0.1            0.0.0.0/0           
    0     0 DROP       all  --  eth0   *       0.0.0.0/0            127.0.0.1           
    0     0 DROP       all  --  eth0   *       192.168.0.0/16       0.0.0.0/0           
    0     0 DROP       all  --  eth0   *       172.16.0.0/12        0.0.0.0/0           
    0     0 DROP       all  --  eth0   *       10.0.0.0/8           0.0.0.0/0           
    0     0 DROP       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0           tcp spts:137:139 
    0     0 DROP       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0           udp spts:137:139 
    0     0 DROP       all  --  eth1   *      !10.0.0.0/24          0.0.0.0/0           
   38 57000 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tap+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  eth1   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           state NEW 
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 

Chain OUTPUT (policy ACCEPT 306 packets, 34543 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0           tcp spts:137:139 
    0     0 DROP       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0           udp spts:137:139 
    0     0 ACCEPT     all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           state NEW

EDIT 3

i think i've left an important piece of information out, i didn't thought it might be relevant, but a recent answer made me tought it might; the openvpn is directly connected to the router, and in the router configuration (at 192.168.0.1) i've enabled port forwarding for openvpn port 1194 to the openvpn server, this is how i'm currently connecting remotely

EDIT 4

I've tried to run the following on the 192.168.0.100 (secondary server) machine, in order to see if i can solve this by giving it a route to the 10.15.119.x route:

sudo route add -net 10.15.119.0 netmask 255.255.255.0 gw 192.168.0.101

(the 192.168.0.101 is the openvpn server address, 192.168.0.100 is the secondary server i want to reach from outside)

i tried this and ping 10.15.119.1 works to reach out to the openvpn server, but ping 10.15.119.6 (my client ip) just fails

EDIT 5

i've added the results of tcpdump on the openvpn server when trying to ping 192.168.0.100 from the client:

$ sudo tcpdump -v -i any host 192.168.0.100
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
11:10:43.675915 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 1, length 64
11:10:43.675932 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 1, length 64
11:10:43.676149 IP (tos 0x0, ttl 64, id 40127, offset 0, flags [none], proto ICMP (1), length 84)
    services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 1, length 64
11:10:43.778583 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 103)
    services-host-1.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 100.0.168.192.in-addr.arpa. (Cache flush) PTR services-host-1.local. (75)
11:10:43.778588 IP (tos 0x0, ttl 255, id 0, offset 0, flags [DF], proto UDP (17), length 103)
    services-host-1.local.mdns > 224.0.0.251.mdns: 0*- [0q] 1/0/0 100.0.168.192.in-addr.arpa. (Cache flush) PTR services-host-1.local. (75)
11:10:44.681801 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 2, length 64
11:10:44.681809 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 2, length 64
11:10:44.682007 IP (tos 0x0, ttl 64, id 40128, offset 0, flags [none], proto ICMP (1), length 84)
    services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 2, length 64
11:10:45.689926 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 3, length 64
11:10:45.689933 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 3, length 64
11:10:45.690121 IP (tos 0x0, ttl 64, id 40129, offset 0, flags [none], proto ICMP (1), length 84)
    services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 3, length 64
11:10:46.698990 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 4, length 64
11:10:46.698997 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 4, length 64
11:10:46.699190 IP (tos 0x0, ttl 64, id 40130, offset 0, flags [none], proto ICMP (1), length 84)
    services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 4, length 64
11:10:47.706870 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 5, length 64
11:10:47.706878 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 5, length 64
11:10:47.707067 IP (tos 0x0, ttl 64, id 40131, offset 0, flags [none], proto ICMP (1), length 84)
    services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 5, length 64
11:10:48.680540 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has services-host-1.local tell openvpnServer, length 28
11:10:48.680737 ARP, Ethernet (len 6), IPv4 (len 4), Reply services-host-1.local is-at 08:00:27:a4:e2:01 (oui Unknown), length 28
11:10:48.684812 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dfdlinkrouter tell services-host-1.local, length 28
11:10:48.685338 ARP, Ethernet (len 6), IPv4 (len 4), Reply dfdlinkrouter is-at 00:26:5a:ae:90:88 (oui Unknown), length 46
11:10:48.716100 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 6, length 64
11:10:48.716107 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > services-host-1.local: ICMP echo request, id 2494, seq 6, length 64
11:10:48.716347 IP (tos 0x0, ttl 64, id 40132, offset 0, flags [none], proto ICMP (1), length 84)
    services-host-1.local > 10.15.119.6: ICMP echo reply, id 2494, seq 6, length 64

so it seems the ping are reaching the server and he replies back, but the packets are dropped before going into the vpn, so i added a line in iptables to log all INPUT and FORWARD packets dropped or rejected and here are what is being filtered in /var/log/syslog

May 30 10:59:24 openvpnServer kernel: [40433.898392] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=98 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=78 
May 30 10:59:24 openvpnServer kernel: [40434.001003] iptables INPUT denied: IN=eth1 OUT= MAC=01:00:5e:00:00:fb:08:00:27:a4:e2:01:08:00 SRC=192.168.0.100 DST=224.0.0.251 LEN=62 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=42 
May 30 10:59:24 openvpnServer kernel: [40434.001102] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=72 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=52 
May 30 11:03:28 openvpnServer kernel: [40677.329586] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=67 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=47 
May 30 11:03:29 openvpnServer kernel: [40678.330065] iptables INPUT denied: IN=eth1 OUT= MAC= SRC=192.168.0.101 DST=224.0.0.251 LEN=67 TOS=0x00 PREC=0x00 TTL=255 ID=0 DF PROTO=UDP SPT=5353 DPT=5353 LEN=47

i've commented out most DROP and REJECT commands from iptables to see if that works, but i'm still getting the same problem, here is my iptables after removing all the drops

$ sudo iptables -L -nv
Chain INPUT (policy ACCEPT 88 packets, 15209 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 3404 3162K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
    0     0 REJECT     all  --  !lo    *       0.0.0.0/0            127.0.0.0/8         reject-with icmp-port-unreachable 
 2950  249K ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
12881 6906K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
  162  9696 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
    1    42 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 8 
   60 10407 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables INPUT denied: ' 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   30  2448 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpt:1194 
    0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables FORWARD denied: ' 

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 2826  857K ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0           
17443 5842K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

EDIT 6

as suggested by Steven, i've added 3 tcpdumps, 2 at the server and one at the client, while from the client, running

$ ping 192.168.0.100
PING 192.168.0.100 (192.168.0.100) 56(84) bytes of data.
^C
--- 192.168.0.100 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4024ms

but first i flushed al iptables rules at the openvpn server:

$ sudo iptables -L -nv
Chain INPUT (policy ACCEPT 206 packets, 26537 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 50 packets, 7781 bytes)
 pkts bytes target     prot opt in     out     source               destination

here is the output of the first tcpdump at the openvpn server

$ sudo tcpdump -vn -i tun0 '(host 192.168.0.100 or host 10.15.119.6)' and icmp
tcpdump: listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
13:54:30.871403 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 1, length 64
13:54:31.870534 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 2, length 64
13:54:32.879562 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 3, length 64

a second tcpdump on the server:

$ sudo tcpdump -vn -i eth1 '(host 192.168.0.100 or host 10.15.119.6)' and icmp
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
13:54:30.871429 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 1, length 64
13:54:30.875508 IP (tos 0x0, ttl 64, id 28969, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.100 > 10.15.119.6: ICMP echo reply, id 3145, seq 1, length 64
13:54:31.870544 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    10.15.119.6 > 192.168.0.100: ICMP echo request, id 3145, seq 2, length 64
13:54:31.870760 IP (tos 0x0, ttl 64, id 28970, offset 0, flags [none], proto ICMP (1), length 84)
    192.168.0.100 > 10.15.119.6: ICMP echo reply, id 3145, seq 2, length 64

and a third tcpdump, this time on the client:

$ sudo tcpdump -vn -i eth0 host 192.168.0.100 and icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

IMPORTANT here is something else whch might be helpful, at the client i've run ip route show

$ sudo ip route show
10.15.119.5 dev tun0  proto kernel  scope link  src 10.15.119.6 
10.15.119.1 via 10.15.119.5 dev tun0 
192.168.0.0/24 via 10.15.119.5 dev tun0 
10.21.2.0/24 dev eth0  proto kernel  scope link  src 10.21.2.118  metric 1 
169.254.0.0/16 dev eth0  scope link  metric 1000 
default via 10.21.2.254 dev eth0  proto static

same command at the openvpn server

$ sudo ip route show
10.15.119.2 dev tun0  proto kernel  scope link  src 10.15.119.1 
10.15.119.0/24 via 10.15.119.2 dev tun0 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.101  metric 1 
169.254.0.0/16 dev eth1  scope link  metric 1000 
default via 192.168.0.1 dev eth1  proto static

openvpn version:

$ openvpn --version OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 12 2010 Originally developed by James Yonan Copyright (C) 2002-2009 OpenVPN Technologies, Inc.

operating system is Ubuntu 10.10 x86_64

Why do i get on the client log:

ue May 31 14:45:41 2011 /sbin/ifconfig tun0 10.15.119.6 pointopoint 10.15.119.5 mtu 1500

Tue May 31 14:45:41 2011 /sbin/route add -net 192.168.0.0 netmask 255.255.255.0 gw 10.15.119.5

Tue May 31 14:45:41 2011 /sbin/route add -net 10.15.119.1 netmask 255.255.255.255 gw 10.15.119.5

whats that about a 255.255.255.255 mask for the virtual network?

@skrewler, this is the result of netstat:

first, from the client when the openvpn is running:

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.15.119.5     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.15.119.1     10.15.119.5     255.255.255.255 UGH       0 0          0 tun0
192.168.0.0     10.15.119.5     255.255.255.0   UG        0 0          0 tun0
10.21.2.0       0.0.0.0         255.255.255.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
0.0.0.0         10.21.2.254     0.0.0.0         UG        0 0          0 eth0


$ ifconfig -a
eth0      Link encap:Ethernet  HWaddr 08:00:27:0c:86:1c  
          inet addr:10.21.2.118  Bcast:10.21.2.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fe0c:861c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:22701 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12806 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2855655 (2.8 MB)  TX bytes:1224261 (1.2 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:480 (480.0 B)  TX bytes:480 (480.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.15.119.6  P-t-P:10.15.119.5  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)

and the client.conf:

dev tun0
remote my.server.com
tls-client
pull
ca keys/ca.crt
cert keys/client.crt
key keys/client.key
ns-cert-type server
status logs/openvpn-status.log
log         logs/openvpn.log
comp-lzo
verb 4

second, from the openvpn server

$ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.15.119.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
10.15.119.0     10.15.119.2     255.255.255.0   UG        0 0          0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 eth1

server.conf

dev tun
server 10.15.119.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.0.0 255.255.255.0"
tls-server
dh keys/dh1024.pem
ca keys/ca.crt
cert keys/openvpn-server-key.crt
key keys/openvpn-server-key.key
user nobody
group nogroup
status openvpn-status.log
log         logs/openvpn.log
comp-lzo
verb 4

with the above setup i am able to:

1) ping from the client to 192.168.0.101 (the openvpn server) 2) ping from the openvpnserver to 10.15.119.6 (the client)

what i am not able to do is ping 192.168.0.100 (secondary LAN server) from the client.

192.168.0.100 actually does reply to the client as tcpdump at the openserver shows, but somehow those packets does not make it back to the client

Hmm, your current OpenVPN config is still missing. I could try to take a guess from your other posts, but I'd prefer to *see* it. — the-wabbit, May 21 '11 at 19:02
OpenVPN config is critical. Also, you need to reveal what network is behind the openvpn server (is it 10.15.119/24 or is it something else?) — Seth Robertson, May 21 '11 at 20:37
in theory, if the openvpn server is at 192.168.0.101 in the server network and the secondary server i want to reach (from client) is at 192.168.0.105, i could create iptables rules (on the openvpn server) for port forwarding to 192.168.0.105 and i sort of know how to do this, my goal in this question is know how to get to a secondary server in the server network (all ip in the 192.168.0.x range) from the client connected with the tun interface — lurscher, May 25 '11 at 21:18
Can you add a network diagram of how you want the setup to look? Are boxes acting as the OpenVPN endpoints the routers for this network? — Zoredache, May 26 '11 at 21:13

score 2 · Answer 1 · answered May 21 '11 at 20:24

2

You will need to push a route through to the clients. This is done using the "push" option in the server config file.

By default the OpenVPN server will only push a route to itself.

In general, when setting up a VPN server, it is a good idea to have the VPN working on a separate subnet, so that you make your routing easier, and also to make your firewall setup easier. Example:

The server running the OpenVPN server has an internal IP address of 10.15.119.1. Its public IP address is 123.1.2.3. And your entire internal network is on 10.15.119.0/24. You would then set up the OpenVPN server to run on 10.15.120.0/24, which will give you up to 63 possible client connections (each connection requires a small subnet of 4 IP addresses). The first client that connects will get IP address 10.15.120.5. If you now push the route to 10.15.119.0/24 , the client will add a route to its routing table so that all traffic for this subnet goes into the tunnel. The OpenVPN server will then fro3ward this traffic into its private ethernet connection.

Read the man page of OpenVPN (or the documentation on the internet) for the exact details of how to push a route.

answered May 21 '11 at 20:24

wolfgangsz

8,767
3
29
34

how do i put the openvpn server in its own subnet 10.15.120.0/24?, do i need an additional router for that? (yes, i'm this ignorant) – lurscher May 21 '11 at 22:36
i'm already pushing a route to the network where the openvpn and all other nodes live: 192.168.0.0, see my server.conf – lurscher May 21 '11 at 22:39
Looks like we have a misunderstanding here. The LAN connected to the OpenVPN server is on 192.168.0.y/24, correct? And the OpenVPN server has subnet 10.15.119.0/24 for its connections to clients, correct? Once a client has connected (with above config) it should be able to ping other computers on 192.168.0.y/24. If you want the client to be able to see other connected clients (which would live on 10.15.119.o/24), you must use the client-to-client option, which tells the server to enable internal routing, so that all clients can see each other. – wolfgangsz May 25 '11 at 15:04
The relevant section of the man page says: --client-to-client Because the OpenVPN server mode handles multiple clients through a single tun or tap interface, it is effectively a router. The --client-to-client flag tells OpenVPN to internally route client-to-client traffic rather than pushing all client-originating traffic to the TUN/TAP interface. When this option is used, each client will "see" the other clients which are currently connected. Otherwise, each client will only see the server. Don’t use this option if you want to firewall tunnel traffic using custom, per-client rules – wolfgangsz May 25 '11 at 15:11
@wolfgangsz, 1) *The LAN connected to the OpenVPN server is on 192.168.0.y/24:* correct, the openVPN server is in 192.168.0.101 and i want to connect to another server at 192.168.0.105 2) *the OpenVPN server has subnet 10.15.119.0/24 for its connections to clients:* when the client is connected to the openVPN, i will ssh from client to the vpn server with ssh lurscher@10.15.119.1, OTOH i will ssh from vpn server to client with ssh lurcher@10.15.119.5. I don't want my client to connect to other clients, just other machines in the openvpn LAN; – lurscher May 25 '11 at 15:50
for example, i try to ping 192.168.0.105 from client to secondary server and it says there is no route to host. from client i can only ping to 10.15.119.1 (which is also 192.168.0.101 from the LAN of the side of the server) – lurscher May 25 '11 at 15:51
If your other server is on 192.168.0.105, then why do you need a VPN? They are on the same subnet! – wolfgangsz May 25 '11 at 16:13
Sorry, ignore my previous comment, that was a moment of mental absenteism. What's the output of a traceroute to 192.168.0.105 from the client? – wolfgangsz May 25 '11 at 16:19
i will show you as soon as the server is again online, currently it has connectivity problems, thanks! – lurscher May 25 '11 at 16:49
`traceroute: unknown host 192.168.0.105` – lurscher May 26 '11 at 21:54
OK, you're on Ubuntu. Use tracepath instead. – wolfgangsz May 26 '11 at 22:02
`$ tracepath 192.168.0.105 1: 10.15.119.6 0.274ms pmtu 1500 1: 10.15.119.1 17.308ms 1: 10.15.119.1 18.516ms 2: no reply 3: no reply 4: no reply 5: no reply` – lurscher May 26 '11 at 22:06
@wolfgangsz, i've also added the relevant portions of both logs – lurscher May 26 '11 at 22:18
Looking again at your office.up script, it hit me: you are adding a route for 10.15.0.0/24. But your target isn't on that network, it's on the 10.15.119.0/24 network. Therefore the OpenVPN server will route these out through it's default gateway (where they get dropped). This route needs to be either 10.15.119.0/24 or 10.15.0.0/16 (depending on how that network is set up). – wolfgangsz May 26 '11 at 22:37
hi @wolfgangsz, thanks for noticing that error! i made the tracepath command again and added it to the end of the original question, i've also added the routing entries from both client and server to help indentifying the problem – lurscher May 27 '11 at 16:28
Your OpenVPN server has 3 default routes. Although 2 of them have higher metrics, this is less than optimal. 2 of these come from self-assigned IP addresses on interfaces vboxnet0 and eth0. That is definitely something to fix. Either configure these interfaces statically or disable them or make sure they get proper IP addresses from a DHCP server. Next thing to check: is the ip_forward flag set on the OpenVPN server? – wolfgangsz May 27 '11 at 16:38
Once you've checked this, then tell me whether there is a firewall on the OpenVPN server of any kind. If there is, add the output of "iptables -nv -L" to your post. – wolfgangsz May 27 '11 at 16:40
@wolfgangsz, done, i've edited the question with the result – lurscher May 27 '11 at 17:03
I still cannot quite see where the packets get lost. Your firewall setup is a bit unusual, but should work. I think we need to have a traffic dump. On the VPN server run "tcpdump -i any host 192.168.0.100", and then ping 192.168.0.100 from the client, then post the output of the tcpdump here. – wolfgangsz May 28 '11 at 11:49
hi @wolfgangsz, i've added the result of tcpdump, and as you suspected, the packets are being dropped for some reason, even after i commented all DROP or REJECT commands in iptables – lurscher May 30 '11 at 16:16
I think what's missing is a "route 10.15.119.0 255.255.255.0" directive in your server config file. Add that, restart the service, then start the VPN connection and see whether it helps. – wolfgangsz May 31 '11 at 09:52
i tried adding a `push "route 10.15.119.0 255.255.255.0` on the server configuration, restarted, but still no ping replies to the secondary server get back to the client – lurscher May 31 '11 at 16:46
No, not a push route, just the line as I typed it between double quotes. This tells the OpenVPN server to route packets for this subnet into the relevant tunnels. – wolfgangsz May 31 '11 at 16:51
ok, still nothing – lurscher May 31 '11 at 17:06
It must be something in the OpenVPN configuration. The packets come back to the OpenVPN server, but then disappear. If they were dropped by the firewall, you would see it in the logs. The simply don't get routed properly. TBH, I am quite puzzled here. What version of OpenVPN do you use? and what is the OS? – wolfgangsz May 31 '11 at 17:23
openvpn 2.1.0 x86_64-pc-linux-gnu built on jul 12 2010, install from apt-get in ubuntu 10.10 x86_64 – lurscher May 31 '11 at 17:26

score 2 · Answer 2 · answered May 27 '11 at 18:04

2

Perhaps I'm not understanding properly, but does the equipment that you're trying to reach behind the VPN server have a configured route that points to the OpenVPN client subnet?

If you're running OpenVPN on a system that's not your default gateway and requires a separate route, those servers wouldn't be able to get packets back to your clients.

The pings originating from your OpenVPN server are being sent from an interface that the equipment can route to, but perhaps the pings going back to the clients have no route to get back if the other servers don't know about that route.

This might be irrelevant if you're NAT'ing your client traffic at the server, but I haven't seen anything to indicate that in the configs you posted.

answered May 27 '11 at 18:04

Magellan

4,431
3
29
53

well, it might be related to this, i don't know; i suppose my router is the actual gateway (192.168.0.1) and i'm port forwarding the 1194 port from the router to the openvpn server, this is how i'm connecting – lurscher May 27 '11 at 18:27
So what kind of response do you get when you try to ping TO a VPN client that successfully connected to the openvpn server FROM one of your 192.168.0.x servers? It should show up as traffic in the 3rd from last iptables statement in your FORWARD chain. – Magellan May 27 '11 at 20:09
nothing, all packets are lost with running `ping 10.15.119.6` (my client ip) on all machines on the LAN **except on the VPN server**, where it pings and connects (to the client) with ssh without a hitch – lurscher May 27 '11 at 20:19
@AdrianK, i've tried adding a route on the secondary server to reach out the vpn network but it only works to reach the openvpn server again, the details are on the question – lurscher May 27 '11 at 20:40
@lurscher If the default gateway is the OpenVPN server, it shouldn't matter on your other servers. The problem is probably on your OpenVPN server. Do keep in mind that you OpenVPN server has multiple IPs. It should be helpful to see which of those IPs are pingable from the other LAN servers. If the VPN Server's OpenVPN IP (10.15.119.1) isn't pingable, there's a problem on your server. Also, you really ought to use the 'ccd' scripts & push your client VPN IP out using 'ipconfig-push'. Your IPs are hopping around and making this issue much more clouded than it should be. – Magellan May 31 '11 at 17:32
only 192.168.0.101 IP is pingable from other LAN servers, in fact 10.15.199.1 is not pingable. You gave an idea; i don't really need the 10.15.199.x virtual network at all, what if i just push the 192.168.0.x network instead?? if that fails, i'll try using ccd scripts, thanks – lurscher May 31 '11 at 19:32
that didn't work either, i guess i should look at setting up ccd scripts. – lurscher May 31 '11 at 19:47
I'd venture that further OpenVPN changes will only add another layer of confusion and frustration right now. If you can't ping the VPN Server's VPN subnet IP from your main network, you most likely have a problem with your underlying server's network config and not OpenVPN. When that particular ping test fails, I always have my techs check the routing and firewall settings. – Magellan May 31 '11 at 20:15
@AdrianK, the strange thing here is that doing the tcpdump experiment at the openvpn server we found that the 192.168.0.100 server is actually replying to the client, just the reply packets does not make it back to the client, i really don't have any iptables rules at this moment, so i don't really understand what is causing the problem – lurscher May 31 '11 at 20:22
1

And you're sure that 192.168.0.100's default gateway is 192.168.0.101? If not, whatever router is in between needs to know about that VPN subnet with a `route add -net 10.15.119.0 gw 192.168.0.101 netmask 255.255.255.0`. Also, trying `ping -B -I 192.168.0.101 10.15.119.1` from the OpenVPN server might be interesting. That combination sets the initial ping source interface and locks it so it can't switch dynamically, which means it has to traverse your routing and iptables as configured. – Magellan May 31 '11 at 22:23
no in fact 192.168.0.100 default gateway is the same default gateway of 192.168.0.101; which is 192.168.0.1 (the common router to which both machines are connected) – lurscher May 31 '11 at 22:29
great suggestion, i'll add that route to the router, and see what happens – lurscher May 31 '11 at 22:30
i've added in the router configuration a static routing rule: WAN -> Destination (10.15.199.0) Mask (255.255.255.0) Gateway (192.168.0.101), tried pinging, but still nothing – lurscher May 31 '11 at 22:37
the router has port forwarding enabled for 1194 to my 192.168.0.101 (this is how i'm able to connect remotely), i'm saying just in case it matters – lurscher May 31 '11 at 22:40
`ping -B -I 192.168.0.101 10.15.119.1` works without problems on the openvpn server – lurscher May 31 '11 at 22:41

skrewler · Accepted Answer · 2011-05-31T23:00:35.383

2

I went through the responses and I think I'm savvy to where you're at with all this.

Lets do some simple checks to narrow down the issue:

From one of the OpenVPN clients that is unable to ping a 192.168.0.x host: netstatn -rn Also give us ifconfig -a for *nix or ipconfig /all ping <openvpn server external 10.21.x address> ping <openvpn 10.15.x address

From the openvpn server: netstatn -rn ping <a 192.168.0.x host> ping <a 10.15.x host> ping <a 10.21.x host>

Also, your current openvpn server config and client config probably at /etc/openvpn/server.conf and on the client machine /etc/openvpn/<hostname>.conf or c:\program files\openvpn\config\<hostname.conf> or .ovpn

I have a similar setup. On my OpenVPN server I have the equiv of this iptables rule (changed hostmask/interface to what your values should be):

# Generated by iptables-save v1.4.4 
*nat
:PREROUTING ACCEPT [5:332]
:POSTROUTING ACCEPT [5:740]
:OUTPUT ACCEPT [5:740]
-A POSTROUTING -s 10.15.119.0/2 -o eth1 -j MASQUERADE
COMMIT

Looks like your problem is most definately because you're missing iptable_nat.

# lsmod | grep nat
iptable_nat             5011  1 
nf_nat                 19101  2 ipt_MASQUERADE,iptable_nat
nf_conntrack_ipv4      12548  3 iptable_nat,nf_nat
nf_conntrack           72270  4 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4
ip_tables              17942  2 iptable_nat,iptable_filter
x_tables               21613  3 ipt_MASQUERADE,iptable_nat,ip_tables

modprobe iptable_nat or try with the -a parameter.

edited May 31 '11 at 23:00

answered May 31 '11 at 19:58

skrewler

308
1
3
13

i'm not sure i follow what you mean exactly that i should do with the ping commands, i've updated the question with most of the information you requested – lurscher May 31 '11 at 20:24
my mistake. editing my question. i wanted you to ping the 10.15.x address and 10.28.x addresses on the openvpn server – skrewler May 31 '11 at 22:09
what is the 10.28.x address for? i don't see any host or IP in that range – lurscher May 31 '11 at 22:12
Should have been 10.21.x. Added some iptables rules for you to try. – skrewler May 31 '11 at 22:19
the 10.21.x address is the eth0 IP of my ISP in the client machine, would it make sense to ping on that in the openvpn server? what are the [5:332] and [5:740] after the ACCEPT commnads? – lurscher May 31 '11 at 22:25
Oh, those should be set to [0:0] .. they're the initial values of the counters. Ok, so it seems was a bit confused with your setup.. I've edited my answer to reflect my goof. I should also note that I have nearly the exact same setup as you. If adding the iptables rule didn't work, lets check that if you add one of the 192.168.0.x hosts to be an OpenVPN client that you can ping it from anywhere. – skrewler May 31 '11 at 22:44
also, `lsmod | grep nat` does not return iptables_nat module – lurscher May 31 '11 at 22:48
in any case, i get this error: `Bad argument `*nat' Error occurred at line: 49 Try `iptables-restore -h' or 'iptables-restore --help' for more information. ` – lurscher May 31 '11 at 22:50
Oh. Well that is surely your problem. What happens if you `modprobe iptables_nat` – skrewler May 31 '11 at 22:51
Lemme know if you can get iptable_nat enabled. I've pasted the output of lsmod | grep nat in my answer. NOTE: it should be `modprobe iptable_nat` not plural – skrewler May 31 '11 at 22:58

score 2 · Answer 4 · answered May 31 '11 at 23:08

Try this:

Add an iptables SNAT rule on your server.

iptables -t nat -A POSTROUTING -s 10.15.119.0/24 -o eth0 -j SNAT --to-source 10.21.2.118

This will give any VPN client IP connections to your other servers in that network a working/routed NAT to go back to.

score 1 · Answer 5 · answered May 30 '11 at 17:09

Why don't you flush the iptables rules completely, to get that possibility out of the way. What about iptables on the client? Flush those too.

iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables -P FORWARD ACCEPT
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT

Then run a cleaner tcpdump on the openvpn server, while pinging from the client to 192.168.0.100:

tcpdump -vn -i tun0 '(host 192.168.0.100 or host 10.15.119.6)' and icmp

Also run a second dump on the server at the same time:

tcpdump -vn -i eth1 '(host 192.168.0.100 or host 10.15.119.6)' and icmp

A third dump on your client:

tcpdump -vn -i eth0 host 192.168.0.100 and icmp

It does look like the ping reaches 192.168.0.100, the reply reaches openvpn, but not your client. But are you sure the client isn't dropping the reply? The first and third tcpdump will verify that.

the client does not have any rules on its iptables (already flushed) — lurscher, May 30 '11 at 17:40
@lurscher: I left an answer with a working config, tried that? — Bart De Vos, May 30 '11 at 18:28
i've edited the question with a new edit (#6) with the output of the several tcpdump commands on server and client — lurscher, May 30 '11 at 19:04

score 0 · Answer 6 · answered May 25 '11 at 20:57

The setup you're trying to accomplish is a somewhat esoteric request, and is addressed by a feature of OpenVPN which is not very well known.

Most VPN setups are configured in such a way whereby the client connecting to the VPN server is the last link in the chain, and there are no other computers or networks behind it which need to be accessible on the VPN. In your scenario, there are networks behind the VPN server as well as the VPN clients, and these networks need to be able to talk to one another directly. There are a number of ways to accomplish this:

Option 1: Configure source NAT at each client. This is not the preferred option, as it adds overhead on the client-side, as well as requiring each client to be individually set up for source NAT. Maintaining such a setup on a large number of networks will be a nightmare.

Option 2: Use the iroutes feature provided by OpenVPN. Using iroutes you are able to explicitly specify the networks behind each node on the network, and thus enable the various networks to talk to one another through OpenVPN's internal routing. The primary benefit of using iroutes over source NAT is that there is no client overhead, and the configuration is all performed on the VPN server only. Bear in mind that you are still required to specify routes to be pushed on the VPN server - adding iroutes must be performed in addition to this and serves the sole purpose of defining the network ranges behind each VPN node.

Since iroutes are not a trivial topic, I advise reading the following pages. If you have specific problems with setting up iroutes, please ask those questions here.

http://www.secure-computing.net/wiki/index.php/OpenVPN/Routing http://backreference.org/2009/11/15/openvpn-and-iroute

sorry, let me clarify; i don't want any "computers or networks behind it (the client)" to be accessible to the VPN, what i'm asking is to get to "computers or networks behind it (the openvpn server)" to be accessible to the client. I hardly can imagine this is an esoteric request, in fact i think its the norm to all vpn deployments, sorry if something in my questions is making this point poorly — lurscher, May 25 '11 at 21:06
We do both - full tunnels (clients behind both ends), clients tunnels (single client to full network), and even multiple vpns (from my laptop, I can ping a remote client, traversing three openvpn instances). Nothing esoteric. — Steven, May 30 '11 at 17:07

score 0 · Answer 7 · answered May 27 '11 at 22:58

I did what you are asking for, I did some things different. For one, I used a tap-device.

Take a look below:

server.conf

port 1194
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key  # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.220.1 255.255.255.0 192.168.220.90 192.168.220.100  # GATEWAY - NETMASK - START DHCP - END DHCP
push "route 192.168.220.0 255.255.255.0"
client-to-client
keepalive 10 120
comp-lzo
max-clients 20
persist-key
persist-tun
status openvpn-status.log
verb 3

client.conf

remote xxx.xxx.xxx.xxx 1194 udp
pull
tls-client
persist-key
ca ca.crt
nobind
persist-tun
cert cert.crt
comp-lzo
dev tap
key key.key
resolv-retry infinite

sorry for not answering earlier @TiZon, i really need this to use tun/routing as bridging might conflict with performance and security requirements. Also, i would say that 90% sure the problem is that the routes are being found but the packets somehow do not make it back to the client, so it seems the problem sits at a lower-level than openvpn — lurscher, May 30 '11 at 18:33

score 0 · Answer 8 · answered May 31 '11 at 15:35

0

Try removing the "up ./office.up" from your server configuration file and restarting OpenVPN. It is not necessary (the openvpn daemon will create the routes for the network defined by the "server" directive anyway) and some screwup might prevent the packets to your clients from being routed correctly.

answered May 31 '11 at 15:35

the-wabbit

40,319
13
105
169

just tried commenting the up office.up, restarted but still no ping replies to the secondary server get back to the client – lurscher May 31 '11 at 16:45
Anything in the logs from the openvpn daemon about an invalid IP address? And I suppose the tcpdump on the openvpn server is just the same as before - you see an ICMP echo reply packet on eth1 but it is not forwarded to tun0? Try running `sudo tcpdump -vn -i tun0` without any further filters just to see if **anything** gets forwarded, even if it is address-rewritten. Your openvpn config looks good, but it might be something outside of openvpn - I'd strongly suspect iptables. – the-wabbit May 31 '11 at 21:07
answering in order; 1) the server logs seem fine, final row after client connection: "PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 10.15.119.1,topology net30,ifconfig 10.15.119.6 10.15.119.5' (status=1)" 2) tun0 does not get any reply at all, just the request 3) my iptables on the openvpn server are currently totally empty and flushed. – lurscher May 31 '11 at 21:28

opvnvpn: addressing nodes in LAN-behinds

8 Answers8

server.conf

client.conf