<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Ubuntu VPN issues</title>
	<atom:link href="http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/feed/" rel="self" type="application/rss+xml" />
	<link>http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/</link>
	<description>Brian Pontarelli</description>
	<pubDate>Tue, 06 Jan 2009 14:16:23 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Remco Stoutjesdijk</title>
		<link>http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-33780</link>
		<dc:creator>Remco Stoutjesdijk</dc:creator>
		<pubDate>Tue, 14 Oct 2008 23:17:08 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-33780</guid>
		<description>I started from here and found how to automate the process, thought I'd post my solution as I have searched high and low:

Check that the VPN works. Usually you can log in and ping known hosts, or even name search with the full domain path. However it does not work without and you can't access hosts by looking up just their name.

We want to add that domain search and replace the name servers in /etc/resolv.conf automatically upon VPN activation. Now, contrary to everything you read about ip-up and ip-down, this does not work! The VPN connection manager calls pppd with some arguments and it does not execute any scripts. Don't waste your time wondering why as I did.

The way to get around it is to install resolvconf:
&#62;$  sudo apt-get install resolvconf

Now try starting your VPN and doing a lookup. Hopefully it works, pppd calls resolvconf and passes it the name server on the VPN, and resolvconf overwrites /etc/resolv.conf to reflect the change. Check that the VPN name servers have been written to the /etc/resolv.conf file. However, once you exit the VPN connection resolvconf is called to delete the new name server info and you end up with an empty /etc/resolv.conf and you can't resolve anything anymore until you edit /etc/resolv.conf and add 'nameserver 192.168.xxx.yyy' (your local name server). Once that is done, all is well again. To prevent having to do this after every VPN reconnect, resolvconf needs default information stored in /etc/resolvconf/resolvconf.d/base.

Edit your /etc/resolvconf/resolvconf.d/base file to read 'nameserver 192.168.xxx.yyy', providing the address of your local name server (not the VPN one).

After this it should work! Log in to the VPN and log out and your local connection, along with your local name server, should be restored.

Happy VPN ing!</description>
		<content:encoded><![CDATA[<p>I started from here and found how to automate the process, thought I&#8217;d post my solution as I have searched high and low:</p>
<p>Check that the VPN works. Usually you can log in and ping known hosts, or even name search with the full domain path. However it does not work without and you can&#8217;t access hosts by looking up just their name.</p>
<p>We want to add that domain search and replace the name servers in /etc/resolv.conf automatically upon VPN activation. Now, contrary to everything you read about ip-up and ip-down, this does not work! The VPN connection manager calls pppd with some arguments and it does not execute any scripts. Don&#8217;t waste your time wondering why as I did.</p>
<p>The way to get around it is to install resolvconf:<br />
&gt;$  sudo apt-get install resolvconf</p>
<p>Now try starting your VPN and doing a lookup. Hopefully it works, pppd calls resolvconf and passes it the name server on the VPN, and resolvconf overwrites /etc/resolv.conf to reflect the change. Check that the VPN name servers have been written to the /etc/resolv.conf file. However, once you exit the VPN connection resolvconf is called to delete the new name server info and you end up with an empty /etc/resolv.conf and you can&#8217;t resolve anything anymore until you edit /etc/resolv.conf and add &#8216;nameserver 192.168.xxx.yyy&#8217; (your local name server). Once that is done, all is well again. To prevent having to do this after every VPN reconnect, resolvconf needs default information stored in /etc/resolvconf/resolvconf.d/base.</p>
<p>Edit your /etc/resolvconf/resolvconf.d/base file to read &#8216;nameserver 192.168.xxx.yyy&#8217;, providing the address of your local name server (not the VPN one).</p>
<p>After this it should work! Log in to the VPN and log out and your local connection, along with your local name server, should be restored.</p>
<p>Happy VPN ing!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Toolman</title>
		<link>http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-16309</link>
		<dc:creator>Toolman</dc:creator>
		<pubDate>Wed, 07 May 2008 08:37:33 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-16309</guid>
		<description>Cheers for this, fixed my issues.  If you copy the resolv.conf before you connect, it has the correct info, so I just pasted the (old) resolv.conf into the new file.</description>
		<content:encoded><![CDATA[<p>Cheers for this, fixed my issues.  If you copy the resolv.conf before you connect, it has the correct info, so I just pasted the (old) resolv.conf into the new file.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brian Pontarelli</title>
		<link>http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-4803</link>
		<dc:creator>Brian Pontarelli</dc:creator>
		<pubDate>Fri, 07 Sep 2007 13:30:48 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-4803</guid>
		<description>Marco,

Sorry the post is misleading. The route command should add the gateway for your VPN to the route table. My VPN is on the 10.10.30 subnet and my gateway from the VPN network to the internets (hehe) is 10.10.30.1. You should find the gateway for your VPN and then use that.

Here is what my route looks like once I VPN in and run the command:

&lt;pre&gt;
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
69.15.181.37    192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         10.10.30.1      0.0.0.0         UG    0      0        0 ppp0
default         *               0.0.0.0         U     0      0        0 ppp0
&lt;/pre&gt;

As you can see, my wireless device has the gateway from the VPN network to the outside. However, the VPN device needs a gateway as well and that is what I setup with the route command so that the ppp0 has the gateway to the VPN network.

Also, be careful of multiple networking devices. If you have wireless and wired devices I've seen it where sometimes if I'm using wireless my wired device will be assigned the VPN bridge and the route for the VPN gateway will be for my wired device.</description>
		<content:encoded><![CDATA[<p>Marco,</p>
<p>Sorry the post is misleading. The route command should add the gateway for your VPN to the route table. My VPN is on the 10.10.30 subnet and my gateway from the VPN network to the internets (hehe) is 10.10.30.1. You should find the gateway for your VPN and then use that.</p>
<p>Here is what my route looks like once I VPN in and run the command:</p>
<pre>
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
69.15.181.37    192.168.1.1     255.255.255.255 UGH   0      0        0 eth1
192.168.1.0     *               255.255.255.0   U     0      0        0 eth1
default         10.10.30.1      0.0.0.0         UG    0      0        0 ppp0
default         *               0.0.0.0         U     0      0        0 ppp0
</pre>
<p>As you can see, my wireless device has the gateway from the VPN network to the outside. However, the VPN device needs a gateway as well and that is what I setup with the route command so that the ppp0 has the gateway to the VPN network.</p>
<p>Also, be careful of multiple networking devices. If you have wireless and wired devices I&#8217;ve seen it where sometimes if I&#8217;m using wireless my wired device will be assigned the VPN bridge and the route for the VPN gateway will be for my wired device.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marco</title>
		<link>http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-4794</link>
		<dc:creator>Marco</dc:creator>
		<pubDate>Thu, 06 Sep 2007 22:35:18 +0000</pubDate>
		<guid isPermaLink="false">http://brian.pontarelli.com/2007/06/19/ubuntu-vpn-issues/#comment-4794</guid>
		<description>Brian,

this is definitely the problem I'm having (I'm using the Cisco VPN, patched) it does connect, and, if I enter the IP address manually it does ping, browse, whatever.

However, having followed your "absurdly simple" instructions does not seem to alleviate the problem.
My /etc/resolv.conf seems to be created correctly by the Cisco client and looks like this:

domain mycompany.com
nameserver 10.32.38.104
nameserver 10.32.38.109

I get an IP address that looks something like
10.32.54.128/255.255.254.0

but running the route command does not seem to fix the issue.
A couple of questions:

1. what should be the IP entry in the route command?
2. what should the routing table (the one shown by the route command alone) look like?

Thanks,
Marco.</description>
		<content:encoded><![CDATA[<p>Brian,</p>
<p>this is definitely the problem I&#8217;m having (I&#8217;m using the Cisco VPN, patched) it does connect, and, if I enter the IP address manually it does ping, browse, whatever.</p>
<p>However, having followed your &#8220;absurdly simple&#8221; instructions does not seem to alleviate the problem.<br />
My /etc/resolv.conf seems to be created correctly by the Cisco client and looks like this:</p>
<p>domain mycompany.com<br />
nameserver 10.32.38.104<br />
nameserver 10.32.38.109</p>
<p>I get an IP address that looks something like<br />
10.32.54.128/255.255.254.0</p>
<p>but running the route command does not seem to fix the issue.<br />
A couple of questions:</p>
<p>1. what should be the IP entry in the route command?<br />
2. what should the routing table (the one shown by the route command alone) look like?</p>
<p>Thanks,<br />
Marco.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
