Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Avoid creating PPTP default routes' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Avoid creating PPTP default routes
Authored by: Nom on Jul 13, '04 09:56:12PM

Completely different way to do this under 10.3.4

Say you've used Internet Connect to create a new VPN 'My_VPN' (yes, that underscore is important). To suppress default route allocation:

/etc/ppp/peers/My_VPN:
nodefaultroute

You can't put this in the global options (/etc/ppp/peers) because a configuration error results.

Then, to patch up routing you need an ip-up and an ip-down. Here, we assume that your remote network has two independent class C subnets, a.b.c1/24 and a.b.c2/24. If your remote has a single class B, you would use a.b/16, and so on.

/etc/ppp/ip-up:
#!/bin/sh
/sbin/route -n add -net a.b.c1 $IPREMOTE >> /tmp/ppp.log 2>&1
/sbin/route -n add -net a.b.c2 $IPREMOTE >> /tmp/ppp.log 2>&1

/etc/ppp/ip-down:
#!/bin/sh
route -n delete -net a.b.c1 $IPREMOTE >> /tmp/ppp.log 2>&1
route -n delete -net a.b.c2 $IPREMOTE >> /tmp/ppp.log 2>&1

Don't forget to make them both executable: chmod +x ip-up ip-down


Patching DNS is even easier. There's a special set of redirects in /etc/resolver. Add appropriate ones for your VPN. Copy the resolv.conf provided by your VPN into a suitable place in your /etc/resolver, and name it (for example) my.vpn.com. Any lookups for my.vpn.com will use this alternative resolver. Tip: copy it BEFORE you make any of the above changes.

You also need to set reverse lookups as well:

ln -s my.vpn.com c1.b.a.in-addr.arpa
ln -s my.vpn.com c2.b.a.in-addr.arpa

In theory, this all works. :)



[ Reply to This | # ]
Avoid creating PPTP default routes
Authored by: jalbrecht2000 on Oct 05, '04 12:37:39PM

I agree with NOM, that is the only correct way to acheive a "correct" split route vpn. However there is a problem that pops up when you have more than one VPN you connect to.

I have a VPN connection that I use to connect to work from home, and vice-versa. Both VPN connections assign me different IP addresses when I connect. I didn' t want to have to manually update ip-up and ip-down everytime I chose to connect to one of the VPN's, so after a little digging here is what I came up with:

ip-up script:
-----CUT HERE-----
#!/bin/sh
#
# This script is run by the pppd after the link is established.
# It should be used to add routes, set IP address
# etc.
#
# This script is called with the following arguments:
# Arg Name Example
# $1 Interface name ppp0
# $2 The tty ttyS1
# $3 The link speed 38400
# $4 Local IP number 12.34.56.78
# $5 Peer IP number 12.34.56.99

case "$5" in
192.168.0.202) /sbin/route -n add -net 192.168.0.0/24 192.168.0.202 >> /var/log/ppp.log 2>&1 ;;
204.118.193.6) /sbin/route -n add -net 10.0.0.0/24 204.118.193.6 >> /varl/log/ppp.log 2>&1 ;;
esac
----CUT HERE----

ip-down script:
----CUT HERE----
#! /bin/sh
#
# This script is run by the pppd after the link is disconnected.
# It should be used to delete routes, remove IP address
# etc.
#
# This script is called with the following arguments:
# Arg Name Example
# $1 Interface name ppp0
# $2 The tty ttyS1
# $3 The link speed 38400
# $4 Local IP number 12.34.56.78
# $5 Peer IP number 12.34.56.99

case "$5" in
192.168.###.###) /sbin/route -n delete -net 192.168.0.0/24 192.168.###.### >> /var/log/ppp.log 2>&1 ;;
204.118.###.###) /sbin/route -n delete -net 10.0.0.0/24 204.118.###.### >> /varl/log/ppp.log 2>&1 ;;
esac
----CUT HERE----

What these scripts do is use a couple of variables to determine the remote IP address you have connected to. Depending on what IP address it finds it will modify the routing table accordingly. Of course you will want to subsitute my numbers with your own IP addresses. I've been using this script for quite awhile now, it works beautifully. Hope this is useful for someone else!

---
__________
Justin



[ Reply to This | # ]
Avoid creating PPTP default routes
Authored by: Kirke on Oct 09, '04 02:54:58AM

This hint is great, but I have a couple of questions just to clarify what's going on and a bit of a problem that maybe someone can help solve.

First, is it fair to assume that ip-up (and ip-down) are files that [something] looks for and executes when initiating (and ending) a VPN session? It just happens that they are missing/not used by default? Is "[something]" Internet Connect or is this a more standard unix thing?

Ok, now here's my problem--a bit of a catch-22 actually. The DNS that can resolve the names of internal servers to their corresponding IP addresses is itself only available "internally." Let me give an example; maybe that will explain this better.

Pretend I work for Zippy Foods and want to connect to zippyfoods.com VPN. The VPN server's address is vpn.zippyfoods.com, the public Web site is www.zippyfoods.com and there is an internal server called private.zippyfoods.com. The DNS that can resolve the private.zippyfoods.com name is at 101.102.103.104 and is only reachable from inside the network.

So, following the instructions from hint, I get to the resolver step and create a new file called zippyfoods.com that looks like:
nameserver 101.102.103.104
nameserver [something cryptic]
port 53
timeout 1

So now I try to connect to the VPN at vpn.zippyfoods.com or go to the public Web site and get an error since it can't resolve those names. Since they are part of zippyfood.com, my computer tries to ask 101.102.103.104 about them and gets no response (because it's not reachable from outside the network).

I can fix the VPN part by changing my parameters to look for the IP address of the VPN server instead (no big deal). But that doesn't solve the issue of not being able to get to the public zippyfoods.com Web site when not connected to the VPN.

I thought maybe a new entry in the /etc/resolver directory for www.zippyfoods.com pointing to local ("ln -s local www.zippyfoods.com") might solve this, but it doesn't seem to. There must be a way to resolve this issue. Any suggestions? It seems silly to have to connect to the VPN even to connect to public servers.

Thanks,
Kirke



[ Reply to This | # ]
Nevermind...
Authored by: Kirke on Oct 09, '04 03:09:31AM

Sheesh, I should read more carefully. All my questions were answered very clearly by other posts. In my defense, when I read them before trying anything I didn't really "get it." Then I played around and came up with the questions I had, but didn't go back and re-read the posts.

Anyway, thanks! This is a great resource.

Kirke



[ Reply to This | # ]