Sorry for the bad format, I am using a webmail client.
The fact that you can ping your own subnet AFTER you connect means that you are using the routing table to get to your subnet, but since there is no default gateway set, anything beyond your subnet is unknown to your computer. The route that says "128.187.34.xx (I forgot what it was) with a subnet of 255.255.255.255 and a gateway of 10.7.77.1" means that ONLY traffic bound for 128.187.34.xx will get a response (try pinging your vpn concentrator ip address after you are connected. You should get a response (unless there's a firewall. Let us know the result.)). I am led to believe this is either a) the way it was designed and there is a problem with your vpn concentrator. This would imply that the vpnc takes care of catching all packets, mangling them, and routing them. It would create the packet containing the ip address of where you REALLY want it to go and send it ALL to the vpn concentrator and let that thing sort it out and send it to where it should really go. Hence, the only real thing you will be able to connect to outside your network is the vpn concentrator at the mtc (and the only real route OUT of your subnet you have available). Or b) not the way it was designed, you should have a default gateway that is something besides the vpn concentrator. With church VPN connections, they have two profiles. One that provides a situation similar to A. When people use this profile, for all intents and purposes they LEAVE their network and go to the church connection. This causes trouble in some cases because they can no longer connect to printers in their office and all their traffic has to go to salt lake before it comes back (if it can make it back at all...if the vpn concentrator in salt lake doesn't know how to route to their office, they are OUT of their office...). They created a profile similar to B for cases where A doesn't work. It's called a split profile and does what it's name implies. It will look at the packet and decide (is this bound for this local area, or is it bound for something outside on the internet, or is it bound for something deep within the church network). Once it makes it's decision, it routes it accordingly. They are able to have all the functionality they had before, but they also have the ability to get to places where their routes wouldn't let them go before... I would try two things. First, do you know anyone who has a similar, linux, setup as you? If so, have them compare profiles and routing tables. Make sure they are the same. The other easier thing to do would be to go into your windows box. Create the connection and check your route tables there. This is assuming the connection works as expected on your windows machine :). If you can do all that and it works as expected, just open a command prompt after you are connected and type "route print" and paste the output here. My guess is you SHOULD have a default gateway. The difficulty is knowing whether that default gateway should be on tun0 or eth0 and whether it should be 128.187.34.xx or 10.7.77.1 address. Your windows route tables should shed some light on this. Brian > > On 3/2/06, Brian Phillips <[EMAIL PROTECTED]> wrote: > > Are you able to ping anything on the 10.7.77.xx subnet (besides your > > computer) before connect? After connect? Can you ping anything on > byu's > > network by IP address before connect (128.187.22.200 is a good choice)? > > After connect? Can you ping anything outside the network > (www.google.com) > > before connect and after again... > > > > Ok... so... > > ip address - before - after > 10.7.77.xxx - works - works > 128.187.22.200 - works - fails > www.google.com - works - fails > > > I would TRY the --udp option. There's no harm in having it not work eh? > > > > Brian > > I tried 'vpnc-connect --udp work' - it failed and returned a usage > message. In the usage message it gave the path, so I 'ls -l'd it, and > it gave: > > machine:/location# ls -l /usr/sbin/vpnc-connect > -rwxr-xr-x 1 root root 4139 2005-05-05 17:56 /usr/sbin/vpnc-connect > > Which meant it was not a symlink - right? - so I ran 'cat > /usr/sbin/vpnc-connect' and it dumped a shell script. There are places > in there where I think it's executing the vpnc file - should I add the > '--udp' option there so that I can get all of the extra benefit of the > script? > > I copied the original to 'back it up', added the '--udp' option where > it made sense, ran the 'vpnc-connect work' command again it connected > just fine, and... > > ip address - before - after > 10.7.77.xxx - works - works > 128.187.22.200 - works - fails > www.google.com - works - fails > > So the pinging tests didn't change with the --udp option... > > Running 'route' gives the same information as before. > > If the tun0 device is listed as 'default' when I run 'route', and it > has a gateway of 0.0.0.0, how would it get anywhere? Can I set the > gateway of the tun0 device to be the gateway of the normal/non-vpnc'd > eth0 device? > > -Rich > > -------------------- > BYU Unix Users Group > http://uug.byu.edu/ > > The opinions expressed in this message are the responsibility of their > author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. > ___________________________________________________________________ > List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list > -- Echte DSL-Flatrate dauerhaft für 0,- Euro*! "Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
