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

[Openvpn-users] Routing problems - continued...

  • Subject: [Openvpn-users] Routing problems - continued...
  • From: Brian Leyton <bleyton@xxxxxxxxxxxx>
  • Date: Thu, 17 Mar 2005 12:47:23 -0800

I apologize in advance for the length of this message...
I think I've distilled my things down enough to have a pretty good idea of what is causing my problems.
I've done pings and tcpdumps on various machines, and here's what I've found.
First of all, here are the 4 machines involved in the test.
#1 cpe_nt02, the Exchange Server.  IP Address, uses gw address (as do all of the machines on my LAN).  Running NT Server 4.0.
#2 IPCop 1.4.2 - this is the firewall, which serves as the gateway for the network.  LAN IP Address  I have added a static route for the network, to use as the gateway for that network.
#3 OpenVPN Server.  Running OpenVPN 2.0rc16 on FC3.  LAN Interface
#4 Test Client.  Windows XP Pro SP2, with firewall off for testing.  Connected via dialup to the Internet, connects to the OpenVPN Server to establish tunnel.  IP Address
First off, let me say that I believe that OpenVPN is doing what it is supposed to do.  So in truth, this message probably belongs somewhere else, but I'm not sure where that "somewhere else" should be :-), and besides - I have a hard time understanding why no one else has this same problem.
So here's the scenario.  I establish the tunnel to the OpenVPN server.  This works fine.  I then ping #1 from #4.  From looking at tcpdumps of each of these machines, I can determine that this is what is happening:
The ping exits the client.  It passes through #3, then goes straight to #1 (not through the IPCop).  #1 replies, however the reply goes to the default gateway, which is #2.  There it dies.  The IPCop does not appear to send back any icmp redirect, and I don't see any other activity - like forwarding the packet to #3 - it seems to simply drop the packet. 
Now scenario #2 is this - I ping FROM #1 to #4.  In this case, the ping goes to #2 (the IPCop).  At the IPCop, I don't see any indication that the packet is being forwarded, however I do see the packet arrive at the OpenVPN server (which shows that it did arrive from the IPCop).  Meanwhile, after the second ping, #1 gets an ICMP redirect from the IPCop, telling not to bug me, send your packets to  #1 dutifully does so, adding a temporary route to the network, and the next 2 packets go straight to #3.
I will extrapolate from these findings (and my other observations) that until you create outbound traffic (any kind - pings or anything else) from LAN hosts to the network, it will be impossible for VPN connected clients to communicate with these LAN hosts - and each host is a separate issue, because it needs to have the route to the network in its table to be accessible.
So here are the questions that I have.
#1.  If I have a static route in the IPCop telling it to pass along traffic to the OpenVPN Server, then why doesn't it always do so?
#2  Why is it that a request through the IPCop will generate an icmp redirect, but a reply to a request will not?  Is this normal behavior?
#3.  I understand that the icmp redirect received by #1 (NT Server) will cause the creation of a temporary route to the network, which is great, but for security reasons, XP machines will only do this if you have specifically enabled it.  This would conceivably cause greater problems with these XP machines than I'm having now with my NT hosts.
#4.  Is it normal to rely on these temporary routes being created, is there some simple way to get these routes into all of the LAN hosts, or is there some better way to avoid this?
#5 Why isn't anyone else having these same problems?  I would expect that anyone who runs an OpenVPN server in routing mode, on a machine other than their default gateway, would have the very same problems.  Why am I the only one having trouble???
I have been contemplating just moving the OpenVPN over to the IPCop machine.  Based on my observations, it seems like this should solve the problem.  Is this the best approach?
Brian Leyton
IT Manager
Commercial Petroleum Equipment