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
Some things to check:
Make sure
/proc/sys/net/ipv4/ip_forward
is1
on both the OpenVPN server and client machines.Make sure the machines that are not the OpenVPN end points have routing information to use the VPN tunnel to reach to other network. If the machines are the gateways for their respective networks, the routing should be taken care of automatically. If not, then the default gateway needs to have a static route that will send traffic for the other network through the OpenVPN endpoint.