|
|
|
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 192.168.1.40, uses gw address 192.168.1.4 (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 192.168.1.4. I have added a static route for the 10.8.0.0
network, to use 192.168.1.249 as the gateway for that
network.
#3 OpenVPN
Server. Running OpenVPN 2.0rc16 on FC3. LAN Interface 192.168.1.249
#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 10.8.0.6
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
10.8.0.0 packets to 192.168.1.249. #1 dutifully does so, adding a
temporary route to the 10.8.0.0 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 10.8.0.0
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 10.8.0.0 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 10.8.0.0
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 10.8.0.0 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
|