[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

[Openvpn-users] Routing mostly works, but ...

  • Subject: [Openvpn-users] Routing mostly works, but ...
  • From: Rob McGee <rob0@xxxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 24 Jan 2004 15:14:56 -0600

... one of the VPN gateways cannot access the remote network. This is
routing, not bridging.

Summary of issue: 2 remote networks successfully routed together using
OpenVPN 1.5.0, but one VPN gateway ONLY cannot access services on the
remote network. Machines behind either VPN gateway can reach any other
remote machine (assuming static routes used where necessary.)

Diagram, good for those using a fixed-width font:

Net1                                                                Net2                                  

gw1 <-------------------------> Internet <-------------------------> gw2
|                                   .------------------> vpn2 <--> tap0|
switch                             /                                   |
|                                 /                               switch
vpn1 <---------------------------'                                     |
|                                                                      |
other net1 clients (on the same switch)                     net2 clients


Cast of characters:
    gw1 and gw2: Slackware ~8.1 and 9.1+ and kernels 2.4.18 and 2.4.22
      respectively, each running stateful iptables firewalls
    vpn1: Slackware 9.0, OpenVPN 1.5.0, kernel 2.4.20
    vpn2: User-mode Linux running on gw2 as host, Slackware 9.1, OpenVPN
      1.5.0, kernel 2.4.22
    net1: 1-2 XP Pro, 2-3 Win98, 0-1 Slackware 9.1 (a couple of dual-
      booting machines in the mix)
    net2: 3 Slackware 9.1+, 1 Win2K (in VMware), 1 NT4, 1 Win98

IP's: vpn1's tun0 is (using an IP in net2's netblock) and
.4.6 on the physical net1 Ethernet. vpn2 has on tun0 (IP in
net1's netblock) and .8.251 on the net2 (a bridge into the real net2
using proxy arp on the host machine, gw2.) gw1 has .4.254 on the net1,
and gw2 is .8.129 on net2.

route tables:
  Default gateways' routes: (note that each is using for
  future expansion -- more VPN's)
    gw1 # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface   U     0      0        0 eth1
    x.xx.xxx.0   U     0      0        0 eth0     UG    0      0        0 eth1       U     0      0        0 lo         x.xx.xxx.1         UG    0      0        0 eth0

    gw2 # route -n # NB: tap0 is not openvpn; it connects to the vpn2 host.
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tap0
    xx.xxx.xx.0 U     0      0        0 eth1   U     0      0        0 eth0     UG    0      0        0 tap0       U     0      0        0 lo         xx.xxx.xx.1         UG    0      0        0 eth1

  VPN gateways' routes:
    vpn1 # route -n
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tun0   U     0      0        0 eth0   UG    0      0        0 tun0       U     0      0        0 lo         UG    1      0        0 eth0

    vpn2 # route -n # remember, this is a UML, with a virtual eth0 to gw2's tap0
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 tun0   UG    0      0        0 tun0   U     0      0        0 eth0       U     0      0        0 lo         UG    1      0        0 eth0

  Clients: All net1 and net2 clients have simple routing: only default
    gateways gw1 and gw2 respectively.

Firewall rules: none on vpn1 nor vpn2. Obviously the external firewalls
(gw1 and gw2) are allowing openvpn through. No client firewalls in use.

Everyone in net2 can reach gw1 and vpn1 using different protocols. That
part is good. gw1 can reach everyone in net2. That's good too. The net1
clients can't do much probably because of their routing (no static route
to net2 through vpn1), but that doesn't matter. I'm sure that if net1
clients needed access to net2, the net1 admin could fix it by adding a
static route. (I'm the net2 admin.)

I and other net2 users do have a need to access services running on the
vpn1 server. Somehow that works. But vpn1 can't initiate any connection
going the other way. (That precludes FTP, which is a service I'd like to
be able to use.) What's odd is that vpn2 seems not to have the problem.
It can get out to net1 machines at will.

I discovered this problem when trying to set up a nameserver on vpn1. I
have one running on gw2. The plan was to have a master server for net1
at vpn1, for net2 at gw2, and to slave each off of the other's master
zone. The initial zone transfers failed.

traceroute from vpn1 to any host in net2 goes to the net1 IP of vpn2 and
gets no further. vpn2, again, does not have this problem. I have not yet
tried a packet sniffer, but that is on the TODO list.

I've already worked around the problem by setting up the nameserver on
gw1 rather than on vpn1, thus achieving mastery of slavery. But I'd
really like to understand and fix the problem. I could try a NAT
workaround too, but routing should work ... right?

My guess: some kind of sysctl setting on vpn1 pertaining to its eth0 or
tun0. Why, then, no problems on vpn2? I'll bet I've missed something
relatively simple. I'd appreciate pointers on what to check.

    Rob - /dev/rob0

PS: James, OpenVPN is looking better all the time! Thanks!

The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
Openvpn-users mailing list