"James B. Byrne" <ByrneJB@xxxxxxxxxxxxx> wrote:
> Thank you for the assistance. I have reached the point
> where I seem to have resolved all the firewall issues that
> were contributing to my problems and I can now reliably
> connect a vpn between my MS-W2K box on one C class to a
> CentOS4.2 box running PopTop pptpd with 128 bit MPPE. As
> you anticipated, now I am down to routing problems.
Yep, Joe hit it on the head.
> I have set up the pptpd server to supply a non-routable
> address in the range 192.168.209.194-254 as the client side
> IP and a routable address from the remote C block as the
> server side. I have very little knowledge and even less
> experience with this so please bear with me.
You can always check the routing table of a Windows client
with "ROUTE PRINT". You will probably have to define some
static routes, possibly with a metric of 1 or 2 to reach
additional networks beyond the immediate network you are
VPN'ing into.
> Here is what I want to do:
> Case 1. Typical:
> From any arbitrary external IP address, establish a VPN to
> a pptpd server inside our firewall that will route all
> traffic consigned to our internal network over that VPN
> while all other traffic goes over the gateway established
> before the VPN is set up.
Here's the problem. Your Windows client only knows the route
to the immediate subnet on the other side of the VPN. To
send another packet to another network, the Windows client
has no other gateway defined than the one for that immediate
network.
So either:
1) The VPN system receiving the VPN packets from the Remote
Windows client handles routing for it to other networks, or
2) The default gateway of the VPN system handles routing for
all systems to all networks (doesn't always work, especially
given differing metrics in some cases), or
3) The Windows client needs to know about other routes in
its own local routing table
#3 is easiest to do and is without ambiguity, using the
"ROUTE" command on the Windows box to define routes to other
networks manually. You would then setup a batch file that
runs after the VPN is established to set all those static
routes.
Eventually you'll want to address #1 though as a "catch all"
on the VPN system itself. There are many, many options.
In reality -- I would make it really strong argument at this
point -- is to setup a dynamic routing protocol inside of
your organization since you clearly have at least 3 subnets
-- the local LAN (where your VPN is at), other LAN(s), and
then remote clients that VPN in.
That would solve the problem, period. You advertise routes
between networks, and clients listen and update their local
routing tables accordingly. You'll also have to setup key
systems (such your VPN system) to broadcast routing updates
down select networks (such as any VPN tunnels).
Now I'm not going to tell you to go out and learn RIP and/or
OSPF. That's clearly network administration, although it
probably wouldn't hurt to learn how to setup RIP and/or OSPF
on a multi-subnet LAN. But as a system administrator (both
Linux and Windows), you will need learn how to at least
configure clients to listen for RIP or OSPF updates --
because it solves the problem nicely for enterprise networks.
Especially since you've been tasked with VPN detail.
> I cannot seem to get this to work with the MS network
> connection client. I have turned off the "use default
> gateway on remote network" option in the tcp/ip advanced
> networking options in the MS client,
And what that does is basically remove my #2 as even an
option. You've turned off the default gateway. So where is
the system going to send packets?
> but the only effect that seems to have is that no
> traffic goes over the VPN at all.
Exactomundo. ;->
> I have confirmed via tracert that the destination IP of
> the VPN tunnel is recognized on the eth0 interface and
> responds to ping and traceroute, but the routing from
> my test workstation is invariantly over the public
> gateway and not via the vpn.
Of course. ;->
Because you're tracing the "raw" layer-3 IP packets (and the
resulting layer-2 Ethernet frames), not the "tunneled" VPN
packets inside of those.
>From that standpoint, you're sending packets out the public
gateway -- even when a VPN is established. Remember, "V" is
for "Virtual" network. Physically it's going to that public
gateway. ;->
> Case 2.
> All traffic is routed over the VPN and then, if necessary,
> out onto the Internet via our own gateway. I need to get
> case 1. working before I do this, but this will be a
another
> requirement that will have to be available in addition to
> case 1. for some users.
Again, you need a route -- either on the Windows client, or
on behalf of the Windows client at either the VPN end-point
or LAN gateway.
Case 1 & 2 are very related.
> What I need is a way of configuring vpn clients on Windows
> 2K and XPpro so that these two cases work automatically
> from some sort of simple to deploy client install script.
> I am open to using alternative vpn client software if that
> is required.
All you really need is a batch file that sets up all the
routes runs when the VPN is established. If you want to
e-mail your network topology off-list, I can give you the
_exact_commands_ for Windows to setup static routes.
I can then talk you through putting this batch file in play
when the VPN is established.
> As this is evidently a client side problem I understand
> that it is not strictly CentOS related. However, this
> issue naturally falls on the server end to provide an
> answer
Not necessarily. Your Windows client can solve it too. I
can help you write the batch file to run on the Windows side.
Actually, you'll need 2 -- one when the VPN is up, one when
the VPN is down.
Ideally, your network should solve it with dynamic routing
broadcasts. I know all Windows versions/VPN clients (IIRC)
have a checkbox to at least listen for RIP updates, if not
OSPF as well.
> and I hope that someone here has gone through this already
> and can provide me with some advice or referrals to other
> venues for help.
> Presently, this is what I get on the MS-W2K client when I
> establish a VPN between netblock A and netblock B:
> Active Routes:
> Network Netmask Gateway Interface
Met
> 0.0.0.0 0.0.0.0 A.1 A.77 1
> 127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
> ..168.209.0 ..255.255.0 ..168.209.214 ..168.209.214 1
> ..168.209.214 ..255.255.255 127.0.0.1 127.0.0.1 1
> ..168.209.255 ..255.255.255 ..168.209.214 ..168.209.214 1
> B.21 ..255.255.255 A.1 A.77 1
> A.0 ..255.255.0 A.77 A.77 1
> A.77 ..255.255.255 127.0.0.1 127.0.0.1 1
> A.255 ..255.255.255 A.77 A.77 1
> 224.0.0.0 224.0.0.0 ..168.209.214 ..168.209.214 1
> 224.0.0.0 224.0.0.0 A.77 A.77 1
> ..255.255.255 ..255.255.255 A.77 A.77 1
> Default Gateway: A.1
This system is host interface A.77 on network A.0/24 with a
default gateway of A.1.
It knows of a network 192.168.209.0/24 which is reachable via
gateway 192.168.209.214. But how does it reach network
192.168.209.0/24?
It knows of a host interface 192.168.109.214 on loopback
(127.0.0.1), which is how it taps into the VPN to reach
network 192.168.209.0/24.
Now it also knows of a host interface B.21 which it can reach
via gateway of A.1. What is host interface B.21?
Please define _all_ your networks so I can help you further.
It's fine to use the A, B, C, etc... nomenclature. But I
need to know what is what.
I will also need to see the _local_ routing tables of at
least 3 different systems on the network -- a regular LAN
client, your VPN server, and a VPN client to be sure.
> The only route to the B network seems to go through the
> usual gateway A.1 and not over the VPN.
Then change that while the VPN is up.
C:\> ROUTE DELETE B.21
Now can you get to it? (probably not)
Again, I'm confused on what A and B are.
> If I do NOT clear the use default GW option then all
> traffic goes from the client on A.77 over the VPN
> Default Gateway (192.168.209.214), reaches the IP at
> the server end (B.214),
What is 192.168.209.0/24?
What is A.0/24?
And what is (assumingly?) B.0/24?
Is 192.168.209.0/24 the VPN tunnel network?
Is A.0/24 the local network of your Windows client?
Is B.0/24 the remote nework you want to VPN to?
I'm confused?
> but then is not routed off the pptpd server
> (forwarding is enabled):
> # cat /proc/sys/net/ipv4/ip_forward
> 1
Forwarding means nothing if routes are not known to the
Windows client, or you are not running various routing
capabilities on one of the systems the Windows client can
directly talk to.
--
Bryan J. Smith | Sent from Yahoo Mail
mailto:b.j.smith@xxxxxxxx | (please excuse any
http://thebs413.blogspot.com/ | missing headers)
