I have a client (which is also a gateway for a 192.168.203.0/24 network) that is trying to connect to a remote server (that is a gateway for a 192.168.150.0/24 network) and make a fully bridge between them.
The client has the following OpenVPN Configuraiton:
dev tun
remote gs.example.com
ca OurCompany-CA.crt
client
port 5800
proto udp
comp-lzo
verb 3
cipher BF-CBC
ca /etc/openvpn/gs-keys/ca.crt
cert /etc/openvpn/gs-keys/kang.crt
key /etc/openvpn/gs-keys/kang.key
keepalive 10 60
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log
The server has the following:
port 5800
proto udp
dev tun
push "route 192.168.150.0 255.255.255.0"
push "route 192.168.203.0 255.255.255.0"
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/kang-server.crt
key /etc/openvpn/keys/kang-server.key
dh /etc/openvpn/keys/dh1024.pem
server 192.168.155.0 255.255.255.0
keepalive 10 120
comp-lzo
status /var/log/openvpn-status.log
log /var/log/openvpn.log
verb 3
persist-key
persist-tun
client-config-dir /etc/openvpn/ccd
The /etc/openvpn/ccd/kang.exmaple.org file has the following:
iroute 192.168.203.0 255.255.255.0
From kang (192.168.203.1), I can ping 192.168.150.1, but nothing else (150.10, 150.11, etc all give me "Destination Port Unreachable"). From gs (192.168.150.1) I can ping anything in the 203 subnet fine.
From anywhere on the 203 network, I can ping 192.168.150.1, but not anything else on that subnet (get "Destination Port Unreachable when I ping 192.168.150.10). From anything on the 150 subnet (for example if I'm on 192.168.150.10) I can't even ping 192.168.203.1.
The firewall on kang has an ACCEPT rule for anything coming through its tun adapter. On gs, I also have an ACCEPT for tun0, but I still have these problems even if I completely turn the firewall off.
I'm wondering if the iroute rules are even being read from the ccd files. How should those show up in the logs?
EDIT:
ip_forwarding (/proc/sys/net/ipv4/ip_forward) is set to 1 on both machines.
On gs gateway (192.168.150.1) if I do a traceroute:
traceroute 192.168.203.40
traceroute to 192.168.203.40 (192.168.203.40), 30 hops max, 38 byte packets
1 192.168.155.6 (192.168.155.6) 396.019 ms 372.837 ms 362.607 ms
2 192.168.203.40 (192.168.203.40) 364.324 ms 387.439 ms 366.329 ms
Same traceroute from 192.168.150.10:
traceroute 192.168.203.40
traceroute to 192.168.203.40 (192.168.203.40), 30 hops max, 38 byte packets
1 192.168.150.1 (192.168.150.1) 1.409 ms 1.173 ms 1.958 ms
2 192.168.150.1 (192.168.150.1) 1.475 ms 1.222 ms 1.068 ms
And 192.168.150.10's routing table:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.11.0 * 255.255.255.0 U 0 0 0 br-lan
192.168.150.0 * 255.255.255.0 U 0 0 0 eth0.2
default 192.168.150.1 0.0.0.0 UG 0 0 0 eth0.2
Similar traceroutes from 192.168.203.1 (kang):
traceroute 192.168.150.1
traceroute to 192.168.150.1 (192.168.150.1), 30 hops max, 40 byte packets using UDP
1 192.168.150.1 (192.168.150.1) 51.687 ms 50.260 ms 54.513 ms
kang:~ # traceroute 192.168.150.10
traceroute to 192.168.150.10 (192.168.150.10), 30 hops max, 40 byte packets using UDP
1 192.168.155.1 (192.168.155.1) 48.623 ms 55.955 ms 54.684 ms
2 192.168.155.1 (192.168.155.1) 57.062 ms 55.816 ms 57.978 ms
Kang's routes (Kang is also a VPN server for individual users. They can get to 192.168.203.0/24 and 192.168.150.1, but nothing else on 192.168.150.0/24). That VPN uses the 192.168.137.0/24 subnet:
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.137.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.155.5 * 255.255.255.255 UH 0 0 0 tun1
192.168.155.1 192.168.155.5 255.255.255.255 UGH 0 0 0 tun1
10.42.7.0 * 255.255.255.0 U 0 0 0 eth1
192.168.137.0 192.168.137.2 255.255.255.0 UG 0 0 0 tun0
192.168.203.0 * 255.255.255.0 U 0 0 0 eth0
192.168.150.0 192.168.155.5 255.255.255.0 UG 0 0 0 tun1
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 10.42.7.1 0.0.0.0 UG 0 0 0 eth1
