Trouble connecting two sites

[lutter]

Want a setup where all machines on LAN S and LAN C can talk to each other

Code: Select all

LAN S: 172.31.0.0/24
       default (Internet) router: 172.31.0.1
       OpenVPN server             172.31.0.8 / 172.31.73.1
       other machine              172.31.0.9

LAN C: 192.168.0.0/24
       default (Internet) router: 192.168.0.254
       OpenVPN client:            192.168.0.2 / 172.31.73.6
       other machine              192.168.0.26

VPN uses 172.31.73.0/24

Both OpenVPN server and client have /proc/sys/net/ipv4/ip_forward set to 1

Problems are the same whether I have iptables running or not; same for
SELinux

VPN connects successfully, and the following pings work:
  192.168.0.2 -> 172.31.73.1
  192.168.0.2 -> 172.31.0.8
  192.168.0.2 -> 172.31.0.9

  172.31.0.8 -> 172.31.73.6

The following pings fail:
  172.31.0.8 -> 192.168.0.2
  172.31.0.9 -> anywhere on LAN C
  192.168.0.26 -> anywhere on LAN S

Routing tables
==============

172.31.0.8:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.31.73.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
172.31.73.0     172.31.73.2     255.255.255.0   UG        0 0          0 tun0
192.168.0.0     172.31.73.2     255.255.255.0   UG        0 0          0 tun0
172.31.0.0      0.0.0.0         255.255.255.0   U         0 0          0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 br0
0.0.0.0         172.31.0.1      0.0.0.0         UG        0 0          0 br0

192.168.0.2:
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
172.31.73.1     172.31.73.5     255.255.255.255 UGH       0 0          0 tun0
172.31.73.5     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
172.31.0.0      172.31.73.5     255.255.255.0   UG        0 0          0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 br0
0.0.0.0         192.168.0.254   0.0.0.0         UG        0 0          0 br0

Both Internet routers have routes to redirect VPN addresses and the other
LAN to their local VPN machine

server.conf:
============

port 1194
proto udp
dev tun

ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server 172.31.73.0 255.255.255.0

ifconfig-pool-persist ipp.txt

push "route 172.31.0.0 255.255.255.0"

client-config-dir /etc/openvpn/ccd
route 192.168.0.0 255.255.255.0

keepalive 10 120

cipher AES-256-CBC

comp-lzo

user openvpn
group openvpn

persist-key
persist-tun

status /var/log/openvpn-status.log
verb 3

/etc/openvpn/ccd/client
=======================
iroute 192.168.0.0 255.255.255.0

client.conf:
============
client
dev tun
proto udp

remote vpn.example.com 1194
resolv-retry infinite
nobind

user openvpn
group openvpn

persist-key
persist-tun

ca ca.crt
cert hv.crt
key hv.key

ns-cert-type server

cipher AES-256-CBC

comp-lzo

[Mimiko]

192.168.0.2 -> 172.31.0.8

172.31.0.8 -> 192.168.0.2

On your client OpenVPn ipforwarding is not enabled to allow packets from tunnel to eth.

172.31.0.9 -> anywhere on LAN C
192.168.0.26 -> anywhere on LAN S

In order to allow all computers to reach each other you have three ways:
1. Install OpenVPN server and client on default gateway, i.e. 172.31.0.1 and 192.168.0.254.
2. For each lan C computer add two static routes:

• route 172.31.0.0 255.255.255.0 192.168.0.2
  route 172.31.73.0 255.255.255.0 192.168.0.2

For each lan S computers add two static routes:

• route 192.168.0.0 255.255.255.0 172.31.0.8
  route 172.31.73.0 255.255.255.0 172.31.0.8

4. On each default gateways for each lan add same routes as in second option, forwarding the packets.

[lutter]

Thanks for the response.

I have those routes on the default gateway. When I try to ping, I see the ICMP redirect from the default router. For example:

On 192.168.0.26 (other machine on LAN C):
ping 172.31.0.8 -> 100% packet loss

On 192.168.0.2 (OpenVPN client):

Code: Select all

#  tcpdump -nS -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
20:48:21.162678 IP 192.168.0.26 > 172.31.0.8: ICMP echo request, id 40541, seq 1, length 64
...

On 172.31.0.8 (OpenVPN server) tcpdump -nS -i tun0 shows no traffic

[Mimiko]

Show iptables from both openvpn servers.

[lutter]

This problem also happens when I turn off iptables and SELinux, i.e. after 'setenforce 0' and with iptables

Code: Select all

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

on all the machines involved.

Here are the iptables config on the three machines, and the issue is exactly the same with iptables turned on on these machines:

172.31.0.8 [OpenVPN Server]

Code: Select all

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [31:3429]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A FORWARD -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -i tun+ -j ACCEPT 
-A RH-Firewall-1-INPUT -i br0 -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT 
-A RH-Firewall-1-INPUT -p esp -j ACCEPT 
-A RH-Firewall-1-INPUT -p ah -j ACCEPT 
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 67 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 67 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 68 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 68 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 2049 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 111 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 32803 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 32803 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 32769 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 32769 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 892 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 892 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 662 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 662 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2223 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 8140 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 6566 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m state --state NEW -m udp --dport 6566 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 3000 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 25 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 2049 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT

192.168.0.2 [OpenVPN client]

Code: Select all

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -p icmp -j ACCEPT 
-A INPUT -i lo -j ACCEPT 
-A INPUT -i tun+ -j ACCEPT 
-A INPUT -i br0 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 53 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 53 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 16509 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 16509 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 67 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 67 -j ACCEPT 
-A INPUT -p tcp -m state --state NEW -m tcp --dport 5900:5910 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 1194 -j ACCEPT 
-A INPUT -j REJECT --reject-with icmp-host-prohibited 
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD -p icmp -j ACCEPT 
-A FORWARD -i lo -j ACCEPT 
-A FORWARD -i tun+ -j ACCEPT 
-A FORWARD -i br0 -j ACCEPT 
-A FORWARD -j REJECT --reject-with icmp-host-prohibited 

192.168.0.26 [other machine on LAN C]

Code: Select all

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [32:4276]
:RH-Firewall-1-INPUT - [0:0]
-A INPUT -j RH-Firewall-1-INPUT 
-A FORWARD -j RH-Firewall-1-INPUT 
-A RH-Firewall-1-INPUT -i lo -j ACCEPT 
-A RH-Firewall-1-INPUT -p icmp -m icmp --icmp-type any -j ACCEPT 
-A RH-Firewall-1-INPUT -p esp -j ACCEPT 
-A RH-Firewall-1-INPUT -p ah -j ACCEPT 
-A RH-Firewall-1-INPUT -d 224.0.0.251 -p udp -m udp --dport 5353 -j ACCEPT 
-A RH-Firewall-1-INPUT -p udp -m udp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 631 -j ACCEPT 
-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 3000 -j ACCEPT 
-A RH-Firewall-1-INPUT -p tcp -m state --state NEW -m tcp --dport 3002 -j ACCEPT 
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited 
COMMIT

Also, the OpenVPN versions are:
172.31.0.8 (server): openvpn-2.1.4-1.el5.x86_64
192.168.0.2 (client): openvpn-2.1.4-1.el6.x86_64

[Mimiko]

On 172.31.0.8 and 192.168.0.2 enable forwarding:

Code: Select all

echo 1 > /proc/sys/net/ipv4/ip_forward

On 192.168.0.2 iptables you have:

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -p icmp -j ACCEPT
-A FORWARD -i lo -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

But on 172.31.0.8 you dont have forwarding. Try to forward traffic from LAN to Tunnel and backward:

Code: Select all

iptables -A FORWARD -i tun0 -o br0 -j ACCEPT
iptables -A FORWARD -o tun0 -i br0 -j ACCEPT

br0 - is a bridge? Which interface it includes?

[janjust]

VPN connects successfully, and the following pings work:
192.168.0.2 -> 172.31.73.1
192.168.0.2 -> 172.31.0.8
192.168.0.2 -> 172.31.0.9

172.31.0.8 -> 172.31.73.6

The following pings fail:
172.31.0.8 -> 192.168.0.2
172.31.0.9 -> anywhere on LAN C
192.168.0.26 -> anywhere on LAN S

if the client can ping the server but the server cannot ping the client the you're looking at a firewalling issue. turn off iptables and selinux on both client and server and first make sure that

Code: Select all

  192.168.0.2 -> 172.31.0.8 works
172.31.0.8 -> 192.168.0.2 works

after that, work your way outwards, i.e. from the client, try to ping the server lan GW , then another host on the server LAN. Then on the server, ping the client LAN GW, then another host on the client LAN , etc.

[lutter]

But on 172.31.0.8 you dont have forwarding. Try to forward traffic from LAN to Tunnel and backward:

Code: Select all

iptables -A FORWARD -i tun0 -o br0 -j ACCEPT
iptables -A FORWARD -o tun0 -i br0 -j ACCEPT

Forwarding is turned on on both 172.31.0.8 and 192.168.0.2 (has been since before I posted about this issue). Adding those iptables rules does not change anything.

br0 - is a bridge? Which interface it includes?

Yes, on both 172.31.0.8 and 192.168.0.2 it contains the physical NIC, eth0; the bridge is there for the networking of virtual machines running on these hosts.

[lutter]

if the client can ping the server but the server cannot ping the client the you're looking at a firewalling issue. turn off iptables and selinux on both client and server and first make sure that

Code: Select all

  192.168.0.2 -> 172.31.0.8 works
172.31.0.8 -> 192.168.0.2 works

Turning off iptables and SELinux on all the machines in question does not change anything. With tcpdump, if I ping from 192.168.0.26 (other machine on LAN C) to 172.31.0.8 I see with tcpdump on 192.168.0.2:

# tcpdump -nS -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
23:07:33.592662 IP 192.168.0.26 > 172.31.0.8: ICMP echo request, id 5378, seq 1, length 64
...

But "tcpdump -nS -i tun0" on 172.31.0.8 does not show any traffic.

[Mimiko]

Would you remove this rules on 192.168.0.2:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

[janjust]

you're testing a lan-client ping again ; does

• ping 192.168.0.2 -> 172.31.0.8 work
  ping 172.31.0.8 -> 192.168.0.2 work

?

does the host 172.31.0.8 have a route for the 192.168.0.0 network to go back via the VPN tunnel?

[lutter]

Would you remove this rules on 192.168.0.2:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

Removed those rules, and tested pings:

192.168.0.2 -> 172.31.0.8 works
192.168.0.2 -> 172.31.0.9 works
172.31.0.8 -> 172.31.73.6 works
172.31.0.8 -> 192.168.0.2 does not work

I also removed on 172.31.0.8 the rule

-A RH-Firewall-1-INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

with no change to the ping results above.

[lutter]

you're testing a lan-client ping again ; does

• ping 192.168.0.2 -> 172.31.0.8 work
  ping 172.31.0.8 -> 192.168.0.2 work

?

Pings from 192.168.0.2 work; pings from 172.31.0.8 do not work

does the host 172.31.0.8 have a route for the 192.168.0.0 network to go back via the VPN tunnel?

Yes, the routing tables are the ones I listed in my initial post

[Mimiko]

Oh, where did the route

172.31.73.0 172.31.73.5 255.255.255.0 UG 0 0 0 tun0

gone from 192.168.0.2?

Show the logs from server and client, the part after establish connection, where the route are added.

[lutter]

Routes on 192.168.0.2 before starting OpenVPN client:

Code: Select all

192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     1003   0        0 br0
0.0.0.0         192.168.0.254   0.0.0.0         UG    0      0        0 br0

Routes after starting the OpenVPN client:

Code: Select all

172.31.73.1     172.31.73.5     255.255.255.255 UGH       0 0          0 tun0
172.31.73.5     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
172.31.0.0      172.31.73.5     255.255.255.0   UG        0 0          0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 br0
0.0.0.0         192.168.0.254   0.0.0.0         UG        0 0          0 br0

OpenVPN client log when starting:

Code: Select all

Tue Aug  9 19:30:08 2011 OpenVPN 2.1.4 x86_64-redhat-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] built on Apr 24 2011
Tue Aug  9 19:30:08 2011 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Tue Aug  9 19:30:08 2011 LZO compression initialized
Tue Aug  9 19:30:08 2011 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Aug  9 19:30:08 2011 Socket Buffers: R=[124928->131072] S=[124928->131072]
Tue Aug  9 19:30:08 2011 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Aug  9 19:30:08 2011 Local Options hash (VER=V4): '22188c5b'
Tue Aug  9 19:30:08 2011 Expected Remote Options hash (VER=V4): 'a8f55717'
Tue Aug  9 19:30:08 2011 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Tue Aug  9 19:30:08 2011 UDPv4 link local: [undef]
Tue Aug  9 19:30:08 2011 UDPv4 link remote: 227.175.80.136:1194
Tue Aug  9 19:30:08 2011 TLS: Initial packet from 227.175.80.136:1194, sid=20ccf063 85cc7bce
Tue Aug  9 19:30:09 2011 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Organized_Operations/CN=OpenVPN_CA/emailAddress=openvpn-admin@example.com
Tue Aug  9 19:30:09 2011 VERIFY OK: nsCertType=SERVER
Tue Aug  9 19:30:09 2011 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Organized_Operations/OU=Home/CN=server.example.com/emailAddress=openvpn-admin@example.com
Tue Aug  9 19:30:10 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Aug  9 19:30:10 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  9 19:30:10 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Aug  9 19:30:10 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  9 19:30:10 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Aug  9 19:30:10 2011 [server.example.com] Peer Connection Initiated with 227.175.80.136:1194
Tue Aug  9 19:30:13 2011 SENT CONTROL [server.example.com]: 'PUSH_REQUEST' (status=1)
Tue Aug  9 19:30:13 2011 PUSH: Received control message: 'PUSH_REPLY,route 172.31.0.0 255.255.255.0,route 172.31.73.1,topology net30,ping 10,ping-restart 120,ifconfig 172.31.73.6 172.31.73.5'
Tue Aug  9 19:30:13 2011 OPTIONS IMPORT: timers and/or timeouts modified
Tue Aug  9 19:30:13 2011 OPTIONS IMPORT: --ifconfig/up options modified
Tue Aug  9 19:30:13 2011 OPTIONS IMPORT: route options modified
Tue Aug  9 19:30:13 2011 ROUTE default_gateway=192.168.0.254
Tue Aug  9 19:30:13 2011 TUN/TAP device tun0 opened
Tue Aug  9 19:30:13 2011 TUN/TAP TX queue length set to 100
Tue Aug  9 19:30:13 2011 /sbin/ip link set dev tun0 up mtu 1500
Tue Aug  9 19:30:13 2011 /sbin/ip addr add dev tun0 local 172.31.73.6 peer 172.31.73.5
Tue Aug  9 19:30:13 2011 /sbin/ip route add 172.31.0.0/24 via 172.31.73.5
Tue Aug  9 19:30:08 2011 LZO compression initialized
Tue Aug  9 19:30:08 2011 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Aug  9 19:30:08 2011 Socket Buffers: R=[124928->131072] S=[124928->131072]
Tue Aug  9 19:30:08 2011 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Tue Aug  9 19:30:08 2011 Local Options hash (VER=V4): '22188c5b'
Tue Aug  9 19:30:08 2011 Expected Remote Options hash (VER=V4): 'a8f55717'
Tue Aug  9 19:30:08 2011 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Tue Aug  9 19:30:08 2011 UDPv4 link local: [undef]
Tue Aug  9 19:30:08 2011 UDPv4 link remote: 227.175.80.136:1194
Tue Aug  9 19:30:08 2011 TLS: Initial packet from 227.175.80.136:1194, sid=20ccf063 85cc7bce
Tue Aug  9 19:30:09 2011 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Organized_Operations/CN=OpenVPN_CA/emailAddress=openvpn-admin@example.com
Tue Aug  9 19:30:09 2011 VERIFY OK: nsCertType=SERVER
Tue Aug  9 19:30:09 2011 VERIFY OK: depth=0, /C=US/ST=CA/L=SanFrancisco/O=Organized_Operations/OU=Home/CN=server.example.com/emailAddress=openvpn-admin@example.com
Tue Aug  9 19:30:10 2011 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Aug  9 19:30:10 2011 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  9 19:30:10 2011 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Aug  9 19:30:10 2011 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Aug  9 19:30:10 2011 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Aug  9 19:30:10 2011 [server.example.com] Peer Connection Initiated with 227.175.80.136:1194
Tue Aug  9 19:30:13 2011 SENT CONTROL [server.example.com]: 'PUSH_REQUEST' (status=1)
Tue Aug  9 19:30:13 2011 PUSH: Received control message: 'PUSH_REPLY,route 172.31.0.0 255.255.255.0,route 172.31.73.1,topology net30,ping 10,ping-restart 120,ifconfig 172.31.73.6 172.31.73.5'
Tue Aug  9 19:30:13 2011 OPTIONS IMPORT: timers and/or timeouts modified
Tue Aug  9 19:30:13 2011 OPTIONS IMPORT: --ifconfig/up options modified
Tue Aug  9 19:30:13 2011 OPTIONS IMPORT: route options modified
Tue Aug  9 19:30:13 2011 ROUTE default_gateway=192.168.0.254
Tue Aug  9 19:30:13 2011 TUN/TAP device tun0 opened
Tue Aug  9 19:30:13 2011 TUN/TAP TX queue length set to 100
Tue Aug  9 19:30:13 2011 /sbin/ip link set dev tun0 up mtu 1500
Tue Aug  9 19:30:13 2011 /sbin/ip addr add dev tun0 local 172.31.73.6 peer 172.31.73.5
Tue Aug  9 19:30:13 2011 /sbin/ip route add 172.31.0.0/24 via 172.31.73.5
Tue Aug  9 19:30:13 2011 /sbin/ip route add 172.31.73.1/32 via 172.31.73.5
Tue Aug  9 19:30:13 2011 GID set to openvpn
Tue Aug  9 19:30:13 2011 UID set to openvpn
Tue Aug  9 19:30:13 2011 Initialization Sequence Completed

Server log (172.31.0.8) during connection:

Code: Select all

Aug  9 10:27:31 lime openvpn[17851]: hv.example.local/131.87.15.108:52884 TLS: soft reset sec=0 bytes=48550/0 pkts=705/0
Aug  9 10:28:13 lime openvpn[17851]: MULTI: multi_create_instance called
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 Re-using SSL/TLS context
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 LZO compression initialized
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 Local Options hash (VER=V4): 'a8f55717'
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 Expected Remote Options hash (VER=V4): '22188c5b'
Aug  9 10:28:13 lime openvpn[17851]: 131.87.15.108:36196 TLS: Initial packet from 131.87.15.108:36196, sid=7a64fa37 e36eaae1
Aug  9 10:28:15 lime openvpn[17851]: 131.87.15.108:36196 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Organized_Operations/CN=OpenVPN_CA/emailAddress=openvpn-admin@example.com
Aug  9 10:28:15 lime openvpn[17851]: 131.87.15.108:36196 VERIFY OK: depth=0, /C=
DE/ST=BW/L=Mannheim/O=Organized_Operations/OU=The Org/CN=hv.example.local/emailAddress=openvpn-admin@example.com
Aug  9 10:28:15 lime openvpn[17851]: 131.87.15.108:36196 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Aug  9 10:28:15 lime openvpn[17851]: 131.87.15.108:36196 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  9 10:28:15 lime openvpn[17851]: 131.87.15.108:36196 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Aug  9 10:28:15 lime openvpn[17851]: 131.87.15.108:36196 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  9 10:28:16 lime openvpn[17851]: 131.87.15.108:36196 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug  9 10:28:16 lime openvpn[17851]: 131.87.15.108:36196 [hv.example.local] Peer Connection Initiated with 131.87.15.108:36196
Aug  9 10:28:16 lime openvpn[17851]: MULTI: new connection by client 'hv.example.local' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Aug  9 10:28:16 lime openvpn[17851]: MULTI: Learn: 172.31.73.6 -> hv.example.local/131.87.15.108:36196
Aug  9 10:28:16 lime openvpn[17851]: MULTI: primary virtual IP for hv.example.local/131.87.15.108:36196: 172.31.73.6
Aug  9 10:28:18 lime openvpn[17851]: hv.example.local/131.87.15.108:36196 PUSH: Received control message: 'PUSH_REQUEST'
Aug  9 10:28:18 lime openvpn[17851]: hv.example.local/131.87.15.108:36196 SENT CONTROL [hv.example.local]: 'PUSH_REPLY,route 172.31.0.0 255.255.255.0,route 172.31.73.1,topology net30,ping 10,ping-restart 120,ifconfig 172.31.73.6 172.31.73.5' (status=1)
Aug  9 10:30:08 lime openvpn[17851]: MULTI: multi_create_instance called
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 Re-using SSL/TLS context
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 LZO compression initialized
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 Local Options hash (VER=V4): 'a8f55717'
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 Expected Remote Options hash (VER=V4): '22188c5b'
Aug  9 10:30:08 lime openvpn[17851]: 131.87.15.108:48671 TLS: Initial packet from 131.87.15.108:48671, sid=d9e2f037 11eb88f1
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 VERIFY OK: depth=1, /C=US/ST=CA/L=SanFrancisco/O=Organized_Operations/CN=OpenVPN_CA/emailAddress=openvpn-admin@example.com
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 VERIFY OK: depth=0, /C=DE/ST=BW/L=Mannheim/O=Organized_Operations/OU=The_Org/CN=hv.example.local/emailAddress=openvpn-admin@example.com
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  9 10:30:10 lime openvpn[17851]: 131.87.15.108:48671 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Aug  9 10:30:10 lime openvpn[17851]: 88.130.15.108:48671 [hv.example.local] Peer Connection Initiated with 88.130.15.108:48671
Aug  9 10:30:10 lime openvpn[17851]: MULTI: new connection by client 'hv.example.local' will cause previous active sessions by this client to be dropped.  Remember to use the --duplicate-cn option if you want multiple clients using the same certificate or username to concurrently connect.
Aug  9 10:30:10 lime openvpn[17851]: MULTI: Learn: 172.31.73.6 -> hv.example.local/88.130.15.108:48671
Aug  9 10:30:10 lime openvpn[17851]: MULTI: primary virtual IP for hv.example.local/88.130.15.108:48671: 172.31.73.6
Aug  9 10:30:13 lime openvpn[17851]: hv.example.local/88.130.15.108:48671 PUSH: Received control message: 'PUSH_REQUEST'
Aug  9 10:30:13 lime openvpn[17851]: hv.example.local/88.130.15.108:48671 SENT CONTROL [hv.example.local]: 'PUSH_REPLY,route 172.31.0.0 255.255.255.0,route 172.31.73.1,topology net30,ping 10,ping-restart 120,ifconfig 172.31.73.6 172.31.73.5' (status=1)

[Mimiko]

It's strange that the server does not push route 172.31.73.0 to the client. Will go with forced approach. Add to the server's config:

Code: Select all

push "route 172.31.73.0 255.255.255.0"

[lutter]

It's strange that the server does not push route 172.31.73.0 to the client. Will go with forced approach. Add to the server's config:

Code: Select all

push "route 172.31.73.0 255.255.255.0"

I just changed that in the server config, restarted the server, then restarted the client, and ... same issues as before. In particular, ping from 192.168.0.2 -> 172.31.0.8 works, ping from 172.31.0.8 -> 192.168.0.2 does not.

The routing table on 192.168.0.2 is now

Code: Select all

172.31.73.1     172.31.73.5     255.255.255.255 UGH       0 0          0 tun0
172.31.73.5     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
172.31.73.0     172.31.73.5     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 br0
172.31.0.0      172.31.73.5     255.255.255.0   UG        0 0          0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 br0
0.0.0.0         192.168.0.254   0.0.0.0         UG        0 0          0 br0

The routing table on 172.31.0.8 is still:

Code: Select all

172.31.73.2     0.0.0.0         255.255.255.255 UH        0 0          0 tun0
172.31.73.0     172.31.73.2     255.255.255.0   UG        0 0          0 tun0
192.168.0.0     172.31.73.2     255.255.255.0   UG        0 0          0 tun0
172.31.0.0      0.0.0.0         255.255.255.0   U         0 0          0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 br0
0.0.0.0         172.31.0.1      0.0.0.0         UG        0 0          0 br0

Can you think of anything else that would cause a Linux machine to not work as a router ? I have net.ipv4.ip_forward = 1 on both machines (and have checked that /proc/sys/net/ipv4/ip_forward is 1, as well as that all /proc/sys/net/ipv4/conf/*/forwarding are set to 1)

162.198.0.2 is running RHEL6.1 (kernel 2.6.32-131.0.15.el6.x86_64), 172.31.0.8 is running RHEL5.5 (kernel 2.6.18-194.el5)

[Mimiko]

Except of routing/firewall/forward issues, I don't see any other issues.

Could you try install OpenVPN client on another computer from the LAN C?

[janjust]

hmmm I just re-read the entire post and noticed something odd:

in an early post you wrote:

/etc/openvpn/ccd/client
=======================
iroute 192.168.0.0 255.255.255.0

this means you expect the name of the client to be [client]

in the server connection log I see

Aug 9 10:30:10 lime openvpn[17851]: XX.XX.XX.XX:48671 [hv.example.local] Peer Connection Initiated with 88.130.15.108:48671

this means that the server thinks that the name of the clietn is hv.example.local - rename the CCD file to 'hv.example.local' and reconnect. Now try the pings 172.31.0.8 <-> 192.168.0.2 again.

[Mimiko]

Oh, yes, janjust, this is the problem too... internal routing of OpenVPN. That iroute never gets executed. it'll be greate to have some utility to view internal routes of OpenVPN.