"James B. Byrne" ByrneJB@Harte-Lyne.ca 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.