Technically interesting:
at this point you won't be able to ping anything on your corp network except the vpn server itself. If you open a console and type the "route" command you will find an entry with the lanside ip of your corp's vpn server.

If you type "ip addr" you'll find you have a new ip address (supplied by your corp's dhcp server) matching your corp's lan subnet and the address of the vpn peer.

So:
5. in a console window type:

route add -net 172.16.1.0 netmask 255.255.255.0 gw 172.16.1.142

where 172.16.1.0 represents your corp subnet and 172.16.1.142 is the theoretical "peer" ip from the "ip addr" command.
Once this command executes you'll have total access to your corporate network.

To simplify things I created an executable script in my-applications/bin for each connection, that reads a variation of:

Code:

gpptp
route add -net 172.16.1.0 netmask 255.255.255.0 gw 172.16.1.142

[Edit] * THIS IS PROBABLY THE BEST APPROACH TO THE ROUTING ISSUE:
Adding the following to the end of the "/etc/ppp/ip-up" file will solve the default gateway issue

Code:

# The following figures out our most current "ppp" number
# and sets default route to it.
MYPPP="ppp"

ppp_count=$(ifconfig |grep -c ppp) # Find highest ppp* number which is the one we want.

if [ $ppp_count -gt "0" ] # It MUST find a ppp* before we set routes
then
ppp_count=`expr $ppp_count - 1` # Decrement the count by one to match dev number
MYPPP="$MYPPP$ppp_count" # Append dev number to the ppp variable
route add default $MYPPP # Set the default route
fi

*****

I do exactly this from a 4.12 LiveCD and it works. The changes to files, etc will be permanent on your other installs. I make a symlink to the script and put it on my desktop.

if you type "ip addr" you'll find you have a new ip address (supplied by your corp's dhcp server) matching your corp's lan subnet and the address of the vpn peer.
... and 192.168.1.142 is the theoretical "peer" ip from the "ip addr" command.

Ah - now I see this post, after spending all that time trying to figure it out

I can do this instead

Code:

route add -net 192.168.1.0 netmask 255.255.255.0 dev ppp0

Quote:

Wait for "exited with 0". (0=success!)

Are you sure that is right? There is a "disconnect" button, which is greyed out, and I would have thought it is supposed so you can disconnect when you are finished, after which I would expect it to exit with 0. Otherwise what is the disconnect button for?... maybe I should look at the source some time.

At the moment, I seem to have to run

Code:

killall pppd

to disconnect.

BTW presumably the drop-down arrows in gpptp are meant to actually work... does anyone know where to save the information so your connections show up in here?

Quote:

Yes, you can run your thumbdrive thru the laundry and it still works like new.

Yes, mine has been through a number of times _________________Classic Puppy quotes
-
root: n. the superuser or administrator account that has complete control over everything in the machine. Running as root is a taonga of Puppy Linux users.

I usually use my Thinkpad X60 running 4.2x to connect via verizon broadband wireless because the hardware is built-in.

Since I'm connecting from a routable IP address, I create a script to route all non-routable (RFC-1918) networks using my "ppp? - inet addr" address as the gateway. What this does is make available to me all RFC-1918 networks that route back to the vpn server I connected to.

So for customers whose systems I administer, one short script gives me access to all their subnets.

Here is a mod I did of gpptp so you can populate the dropdown lists and automate the connection process. Read the readme file for details.

jafadmin

[ updated 5-22-2009 ]

I've spent a little time re-working aspects of the Gpptp client. It will now:

1. Retrieve usernames and servernames/ipaddrs of servers from
user-editable files in the /etc/ppp directory.

2. Fixed the buttons so you can disconnect and reconnect using
different servers or userid's without exiting the app.

3. Fixed it so that it knows the pid of the spawned pppd process
so it will kill properly.
.......

Stuff I'm working on:

It would be nice to integrate the route handling into the app instead of using scripts.

maybe a "single file" structure to handle "profiles" that contain all the particular settings details for each particular vpn environment we need to connect to.Last edited by jafadmin on Sat 23 May 2009, 14:04; edited 1 time in total

Gpptp will now remember your VPN sessions after you close the window so you can connect, close the vpn window, then re-open Gpptp later and disconnect the active VPN session if it still exists.

You can use an editor to put entries in the "/etc/ppp/vpn_servers" and the "/etc/ppp/vpn_userids" files and the entries will show up in the drop-down lists in the app.

I added a "Close window" button that will kill the app but leave the connection in place. The "Disconnect" button now works as one would expect; .. if there is an active connection it will be disconnected.

Thanks.
That's weird. It's a lot better, except after I disconnect the vpn my normal network connection doesn't work until I reboot

Ideally it would be good if the route command was added to the main program... although it may be easier to rewrite as a gtkdialog program instead

BTW can we have the source please? Or at least when you've finished, if you're still working on it._________________Classic Puppy quotes
-
root: n. the superuser or administrator account that has complete control over everything in the machine. Running as root is a taonga of Puppy Linux users.

Thanks.
That's weird. It's a lot better, except after I disconnect the vpn my normal network connection doesn't work until I reboot

Ideally it would be good if the route command was added to the main program... although it may be easier to rewrite as a gtkdialog program instead

BTW can we have the source please? Or at least when you've finished, if you're still working on it.

What happens is that your DNS gets reset by the VPN dhcp function where you connect. When you disconnect, the DNS servers can't be reached so dns resolution fails. You shouldn't need to reboot, just have the network connection wizard re-aquire dhcp after you disconnect..

I'm still working on it. The plan is to incorporate the routes into the app and have it fix the dns when we disconnect the VPN connection (I can do this by caching /etc/resolve.conf then restoring it when user disconnects) . Let me clean up the source and I'll send it to you.

Eventually I want it to be able to have multiple connection choices like the remote desktop app has so you can just load the connection by a saved name and it will automatically set everything for that VPN site.

When I tried it before though, my network still worked after I killed pppd _________________Classic Puppy quotes
-
root: n. the superuser or administrator account that has complete control over everything in the machine. Running as root is a taonga of Puppy Linux users.

When I tried it before though, my network still worked after I killed pppd

[Edit]

Ok, I added the functionality to backup and restore the "/etc/resolv.conf" when it connects to and disconnects from a VPN server. This means your DNS should return to it's previous state after you click the "Disconnect" button.

I am very new to PL (since only Jan 09), and GPPTP
has been my biggest snag so far. I know little about
Linux and networking issues, but am a quick learner.
I figured out the wifi driver (my biggest PL street cred so far).

The VPN manual mentions setting DNS to 208.67.222.222 (which shows
up in resolv.conf) and 208.67.220.220 (which doesn't). Should I use
them instead of the 192.168.x.xx?
I've not yet tried either one in the "route add" command.

Do I change the ppp0's assigned genmask from 255.255.255.255 to 255.255.255.0, or was 255.255.255.0 merely an example?

Finally, how do I permanently install the new/improved GPPTP client to my boot CD or pup_save? There must be link about this kind of thing.
Remember, I'm a total PL and Linux newbie.

Many thanks for your help.
I suspect that I'm very nearly there, but am tapped out of ideas.

WHAT I GOT FROM resolv.conf:
nameserver 192.168.2.1
nameserver 208.67.222.222 (this IP is mentioned in my VPN provider's manual, but it didn't show up in "route" or "ip addr")

PINGING:
192.168.2.54 pingback, but only wlan0 blinky
192.168.2.1 no pingback, but wlan0 and ppp0 blinky active
192.168.1.0 no pingback, but wlan0 and ppp0 blinky active
192.168.0.1 pingback, but only wlan0 blinky

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum