Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
    
Increase the log verbosity to find out whether the ccd has been read. –  Gabor Vincze Mar 11 '12 at 9:25

1 Answer 1

Some things to check:

  • Make sure /proc/sys/net/ipv4/ip_forward is 1 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.

share|improve this answer
    
Both machines are NATing, but I double checked and "cat /proc/sys/net/ipv4/ip_forward" does return 1 on both machines. They are also both the default gateways for their respective networks. –  djsumdog Mar 11 '12 at 8:03
    
Hmm. It might be the NAT rules that are the issue. Can you paste the NAT and FORWARD iptables? –  cjc Mar 11 '12 at 11:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.