Bug #124663 “No default internet traffic after connecting to VPN...” : Bugs : vpnc package : Ubuntu

Revision history for this message

Kees Cook (kees) wrote on 2007-07-10:

#1

Thanks for taking the time to report this bug and helping to make Ubuntu better. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find.

Revision history for this message

Emmet Hikory (persia) wrote on 2007-07-10:

#2

This is the default behaviour for the commercial cisco client as well. The reason it is configured in this manner is to prevent external attackers using a (typically poorly secured) external workstation with VPN access to access internal resources. Cisco has a feature in their newer concentrators that allows this behaviour to be disabled for certain groups of users, although I am unsure as to whether vpnc supports this.

The preferred general solution is for the VPN hosting organisation to provide (secured) routing to external resources through the VPN for connected clients, in compliance with the providing organisations security model.

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2007-07-10: Re: [Bug 124663] Re: No default internet traffic after connecting to VPN

#3

But that doesn't make my work easier. Can you please add this feature in
vpnc and help me please.

I found on this webpage http://www.gentoo.org/doc/en/vpnc-howto.xml that it
is a problem of DNS Masquerading. Although it doesn't work for me (possibly
because Gentoo is different from Ubuntu), is there a way of solving this
problem in some way?

I am sure some changes in the shell scripts that configure the tunnel as the
default gateway can be done? Can't we use the user's terminal as a DNS
server and then route traffic meant for VPN through the tunnel and the rest
through the default gateway?

Also, can we modify the code that adds and removes gateways to make it just
add one more gateway and not remove the others entirely? If you notice the
bug report and the forums, this is one of the most important reasons why
people prefer Microsoft to Linux. I am sure, Linux has the ability to beat
Microsoft. Kindly give this a try.

Solving this problem will bring Ubuntu many more customers in the future.

Thanks and Regards,
Balaji

On 7/10/07, Emmet Hikory <email address hidden> wrote:
>
> This is the default behaviour for the commercial cisco client as well.
> The reason it is configured in this manner is to prevent external
> attackers using a (typically poorly secured) external workstation with
> VPN access to access internal resources. Cisco has a feature in their
> newer concentrators that allows this behaviour to be disabled for
> certain groups of users, although I am unsure as to whether vpnc
> supports this.
>
> The preferred general solution is for the VPN hosting organisation to
> provide (secured) routing to external resources through the VPN for
> connected clients, in compliance with the providing organisations
> security model.
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Balaji

Revision history for this message

Emmet Hikory (persia) wrote on 2007-07-10:

#4

Personally, I don't believe the behaviour should be changed. The default is the same for Windows and Linux with the Cisco client, and is more secure than allowing dual-homed access. If you're sufficiently sure that you are not compromising your VPN provider by doing so, there's no reason you can't modify the routes manually, but it seems a poor choice by default, as most people who would not be able to modify the routes would also not be able to guarantee the integrity of their VPN client sufficiently to protect the providers network.

Further, if vpnc were to provide open routing by default, it would be in the interest of many VPN providers to block vpnc from access, thereby defeating the value of the tool.

Revision history for this message

Oliver Wilson (wool-in-silver) wrote on 2007-08-12:

#5

That is not the default behaviour in the Windows Cisco client, surely?
I use the Windows client all the time and my internet routing is unaffected.

Are we suggesting that he should disconnect from VPN just to use google?
Or that his company should provide web access, and then send it through the tunnel?

Perhaps I misunderstand what has been posted, but I don't think armies of Windows users are hacking their routing tables every time they connect to a VPN.

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2007-08-13:

#6

Exactly my point Oliver. This is why I am requesting that this bug be taken
seriously. It is one of the reasons why I contemplated going back to
Windows. The Windows Cisco client has a simpler interface, and with just one
option, one could either have the normal internet traffic continued or shut
off. The default behaviour is to allow other traffic while on VPN.

The idea of security by making sure only the tunnel works is not very clear
- rather counter-intuitive. What could happen on the tunnel if no-one knows
that there is a tunnel at all? Besides, hacking the tunnel or listening to
the tunnel is hardly possible since data packets are exchanged over the
tunnel in a secure manner. Saying that to maintain security we would shut
off google access for example is like saying that to allow a person buy
something on the internet using his credit card through secure web means
shutting off google.

I really request that the VPN client in Ubuntu be customized or easily
customizable so that more Windows users would want to start using Ubuntu.
Often have I seen topics on Ubuntu forums saying "Ubuntu? I have work to
do!" or "Ubuntu: I should either stop working or stop surfing!" People find
it more difficult to use Ubuntu if such features that ease out the user's
work are enabled.

Please take the bug seriously and help me out with this. There are ways
people have found out to tunnel through this in Gentoo for example using
dnsmasq. http://www.gentoo.org/doc/en/vpnc-howto.xml The only thing is that
his instructions just don't work for Ubuntu.

Please help.

Thanks,
Balaji

On 8/13/07, Oliver Wilson <email address hidden> wrote:
>
> That is not the default behaviour in the Windows Cisco client, surely?
> I use the Windows client all the time and my internet routing is
> unaffected.
>
> Are we suggesting that he should disconnect from VPN just to use google?
> Or that his company should provide web access, and then send it through
> the tunnel?
>
> Perhaps I misunderstand what has been posted, but I don't think armies
> of Windows users are hacking their routing tables every time they
> connect to a VPN.
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Balaji

Exactly my point Oliver. This is why I am requesting that this bug be taken
seriously. It is one of the reasons why I contemplated going back to
Windows. The Windows Cisco client has a simpler interface, and with just one
option, one could either have the normal internet traffic continued or shut
off. The default behaviour is to allow other traffic while on VPN.

The idea of security by making sure only the tunnel works is not very clear
- rather counter-intuitive. What could happen on the tunnel if no-one knows
that there is a tunnel at all? Besides, hacking the tunnel or listening to
the tunnel is hardly possible since data packets are exchanged over the
tunnel in a secure manner. Saying that to maintain security we would shut
off google access for example is like saying that to allow a person buy
something on the internet using his credit card through secure web means
shutting off google.

I really request that the VPN client in Ubuntu be customized or easily
customizable so that more Windows users would want to start using Ubuntu.
Often have I seen topics on Ubuntu forums saying "Ubuntu? I have work to
do!" or "Ubuntu: I should either stop working or stop surfing!" People find
it more difficult to use Ubuntu if such features that ease out the user's
work are enabled.

Please take the bug seriously and help me out with this. There are ways
people have found out to tunnel through this in Gentoo for example using
dnsmasq. http://www.gentoo.org/doc/en/vpnc-howto.xml The only thing is that
his instructions just don't work for Ubuntu.

Please help.

Thanks,
Balaji

On 8/13/07, Oliver Wilson <wool.in.silver@ntlworld.com> wrote:
>
> That is not the default behaviour in the Windows Cisco client, surely?
> I use the Windows client all the time and my internet routing is
> unaffected.
>
> Are we suggesting that he should disconnect from VPN just to use google?
> Or that his company should provide web access, and then send it through
> the tunnel?
>
> Perhaps I misunderstand what has been posted, but I don't think armies
> of Windows users are hacking their routing tables every time they
> connect to a VPN.
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

-- 
Balaji

Revision history for this message

none (ubuntu-bugs-nullinfinity-deactivatedaccount) wrote on 2007-09-03:

#7

Providing easy to use but insecure defaults is to a large extent what got Microsoft into their security mess. I believe this issue is best resolved by either asking your organization to route traffic between their vpn endpoint and the internet, or using the network-manager vpn configuration dialog to only route traffic through the vpn for certain networks.

Revision history for this message

Wilken Haase (hibbelharry) wrote on 2007-10-27:

#8

With that change in the pptp plugin i'm not able to use either the vpn tunnel at my workingplace, neither the Internet Connection my University provides via WLAN. So the plugin became useless for me since using gutsy. I think that is a major backdraw for the usabilty of my system.
I know many other bigger organizations like other German Universities which provide Internet Access via a PPTP Tunnel and all these Organizations have not configured their Routing to use the tunnel-endpoint as gateway. It is also no easy task to convince the staff of the University to change their configuration since everything works well with MS clients which are used by the vast majority of users.
Please consider that pptp is somekind of a MS invention and mostly offered to bring in an easy way of authorization of access and some little easy usable encryption, thats a totally different goal to that of the cisco, etc. offerings using ipsec.

I think it would be a really wise idea to revert this behaviour. May it's a better idea to ask upstream to make this configurable and include it then as an recommended option once this becomes implemented.

Revision history for this message

Wilken Haase (hibbelharry) wrote on 2007-10-27:

#9

After reading again and just have followed a forum link in Ubuntu Forums i saw i maybe have chosen the wrong bug to comment. Sorry !

Revision history for this message

Adam Schumacher-Darling (adam-genericor) wrote on 2007-11-27:

#10

I am also affected by this bug. While I agree with Johan that allowing the client a direct route to the internet while the tunnel is active is a Bad Thing, that is ultimately the decision of the network architect, not the client. I believe that the client should route whatever networks are advertised by the VPN gateway; if that includes the default route, then so be it.

The reality of the situation is that network administrators are often configuring their VPNs based on the behaviour of the Windows client, and aren't necessarily about to make changes for one or two Linux users in the enterprise.

While the NetworkManager vpnc plugin does allow you to manually enter which networks are to be routed through the tunnel, doing so prevents NM from correctly updating resolv.conf to use the organization's DNS servers, which breaks name resolution for hosts on the private network.

Revision history for this message

James Cape (jcape) wrote on 2007-12-02:

#11

We run a Cisco VPN which pulls it's configuration over DHCP, including a default route. Gutsy's NM/vpnc does not apply this route. This feature of the Cisco VPN works just fine in other places: the official client for Windows, for Mac, and for Linux, the command-line /usr/sbin/vpnc executable, and NetworkManager-vpnc 0.6.4 from Fedora.

Please take this seriously, it *is* an actual bug, one which is irritating enough to make Ubuntu less useful for me and those I work with.

Revision history for this message

Emmet Hikory (persia) wrote on 2007-12-02:

#12

Thanks for testing with a Cisco concetrator that supplies a default route. If that's not being applied, it's definitely a bug. Setting Confirmed.

Changed in vpnc:
importance:	Undecided → Medium
status:	New → Confirmed

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2007-12-02:

#13

Thanks! Finally this bug which I have been beating my breast about since
Feisty days is getting attention. How did that happen?

Thanks anyway! Now please take action and close this bug. I want to start
using VPN from network manager on my Ubuntu laptop.

-Balaji

On Dec 2, 2007 9:25 AM, Emmet Hikory <email address hidden> wrote:

> Thanks for testing with a Cisco concetrator that supplies a default
> route. If that's not being applied, it's definitely a bug. Setting
> Confirmed.
>
> ** Changed in: vpnc (Ubuntu)
> Importance: Undecided => Medium
> Status: New => Confirmed
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Balaji

Revision history for this message

integr8e (integr8e) wrote on 2007-12-09:

#14

Go figure . . . I've only been a member of the Linux community (Kubuntu) since August, and for about 2 months, I used KVpnc to connect to my university's VPN; then, after using the Gutsy beta for probably a week, this bug happened. It was completely random and seemingly without cause, as I hadn't updated or changed any settings in KVpnc since the previous time I'd connected to my university's server. For a while I didn't know what to do, but eventually learned how to manually configure KNetworkManager to connect to connect to my university, which worked! Now, after having happily used KNetworkManager for the last couple of weeks, KNetworkManager has decided to fizzle out on me too. Frustrated, I installed KVpnc once again, and lo-and-behold, it works - hugh???

I dunno'; I'm pretty sure this is a bug, though.

Revision history for this message

integr8e (integr8e) wrote on 2007-12-09:

#15

Ugh! I was connected to my university when I posted the last reply (5 minutes ago), and after posting it, I lost my regular internet connection =-( I disconnected from my university's VPN, and had a connection again, then, reconnected to the VPN, and now still have a connection; it's very inconsistent.

Revision history for this message

Tomasz 'Zen' Napierala (tzn) wrote on 2007-12-14:

#16

If Ubuntu wants to take any market share in enterprise, such sudden changes cannot happen. I was using NetowrkManager's vpnc plugin for a while, and it's crucial for my work (I believe it's crucial for many people). Please fix this or let us know how to help to get this issue fixed!

Revision history for this message

Emmet Hikory (persia) wrote on 2007-12-14:

#17

I don't understand how the specific fix would work, but the general process towards a resolution would be for someone to investigate the code and find out why and how the default route is being adjusted, for someone to use this information to determine how the application should behave, for someone to use that information to prepare a patch, for someone to wrap the patch in a debdiff, and for someone to upload a new revision including that debdiff to the repositories. These could be different people or all one person, depending on who has which knowledge and skills.

From my viewpoint, a correct solution would include the ability of the VPN provider to allow or block a default route not through the VPN, would be consistent and documented, would match the behaviour of commercial clients, and would integrate properly with NetworkManager.

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-03-06:

#18

Oddly, I never had this problem back during Gutsy like all you did, but now that I'm using Hardy, my network traffic has ceased to go through the VPN and I have to use the command line VPN client. I don't mind using the command line one too much...but I imagine everybody at my school that relies on NM-VPNC is going to come to me when they can't figure out how to get online.

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2008-03-07:

#19

Try out installing/reinstalling the following packages:

pptpd, pptp-linux, network-manager-pptp, vpnc, network-manager-vpnc,
bcrelay, openvpn, network-manager-openvpn, ebox-openvpn

Also do make sure the package resolvconf is uninstalled. Thereafter the
nm-vpnc should work.

When I migrated from Feisty to Gutsy, I ran into this problem. Although the
matter being discussed here is entirely different, I would be happy if I was
of some help. The issue at hand is that while you connect through vpnc, your
normal traffic is stopped. Ideally that should not be the case. I have to
connect to my company's proxy to be able to use Google for example. However,
several personal email websites are not accessible through that proxy. It is
therefore preferable if somehow, we have a way of identifying that a
particular DNS or address belongs to the domain of company and should
therefore direct such requests through the tunnel. Others requests should go
bypassing the tunnel and we should be able to use normal internet while
connected to the VPN.

It is just plain irritating right now. However there is some sort of a good
news in all of this. When my nm-vpnc was not working, I had to initially
start with the shell. At that time, I noticed that if I connect through vpnc
on the shell, my pigdin chat client is still working. The same is true about
Azureus. I still however, have to connect to the proxy on firefox. I use
network-manager and connect to VPN using the GUI, all my normal traffic is
blocked and I can't use pigdin or Azureus.

To me therefore, it appears that
1. nm-vpnc/whatever actually runs if you use the GUI to connect to the VPN
gateway, is doing a little more stuff than vpnc does.
2. There should be a way to let firefox know how to bypass the tunnel just
like Azureus and pidgin do.

Thanks,
Balaji

On Fri, Mar 7, 2008 at 2:26 AM, Mackenzie Morgan <email address hidden> wrote:

> Oddly, I never had this problem back during Gutsy like all you did, but
> now that I'm using Hardy, my network traffic has ceased to go through
> the VPN and I have to use the command line VPN client. I don't mind
> using the command line one too much...but I imagine everybody at my
> school that relies on NM-VPNC is going to come to me when they can't
> figure out how to get online.
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Balaji

Try out installing/reinstalling the following packages:

pptpd, pptp-linux, network-manager-pptp, vpnc, network-manager-vpnc,
bcrelay, openvpn, network-manager-openvpn, ebox-openvpn

Also do make sure the package resolvconf is uninstalled. Thereafter the
nm-vpnc should work.

When I migrated from Feisty to Gutsy, I ran into this problem. Although the
matter being discussed here is entirely different, I would be happy if I was
of some help. The issue at hand is that while you connect through vpnc, your
normal traffic is stopped. Ideally that should not be the case. I have to
connect to my company's proxy to be able to use Google for example. However,
several personal email websites are not accessible through that proxy. It is
therefore preferable if somehow, we have a way of identifying that a
particular DNS or address belongs to the domain of company and should
therefore direct such requests through the tunnel. Others requests should go
bypassing the tunnel and we should be able to use normal internet while
connected to the VPN.

It is just plain irritating right now. However there is some sort of a good
news in all of this. When my nm-vpnc was not working, I had to initially
start with the shell. At that time, I noticed that if I connect through vpnc
on the shell, my pigdin chat client is still working. The same is true about
Azureus. I still however, have to connect to the proxy on firefox. I use
network-manager and connect to VPN using the GUI, all my normal traffic is
blocked and I can't use pigdin or Azureus.

To me therefore, it appears that
1. nm-vpnc/whatever actually runs if you use the GUI to connect to the VPN
gateway, is doing a little more stuff than vpnc does.
2. There should be a way to let firefox know how to bypass the tunnel just
like Azureus and pidgin do.

Thanks,
Balaji

On Fri, Mar 7, 2008 at 2:26 AM, Mackenzie Morgan <macoafi@gmail.com> wrote:

> Oddly, I never had this problem back during Gutsy like all you did, but
> now that I'm using Hardy, my network traffic has ceased to go through
> the VPN and I have to use the command line VPN client.  I don't mind
> using the command line one too much...but I imagine everybody at my
> school that relies on NM-VPNC is going to come to me when they can't
> figure out how to get online.
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

-- 
Balaji

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-03-14:

#20

I'm confused. Are you guys saying stuff *does* go through the VPN that you don't want to go through the tunnel or that nothing's going through the tunnel? On Hardy, nothing goes through the tunnel. That's the problem I'm having. I just keep getting the "please connect to the VPN" page. Is this the same or a different problem?

Revision history for this message

integr8e (integr8e) wrote on 2008-03-14:

#21

With me, >>>all<<< network traffic was stopped whenever I connected to my university's VPN tunnel; I got it working, though, following Balaji's post (thanks, by the way). Maybe resolvconf was the culprit???

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-03-14:

#22

OK if I connect using network-manager-vpnc, all traffic runs into the
"please connect to the VPN" gateway page. If I use the "sudo vpnc" command,
though, it all works perfectly fine. Is that the same for you guys?

On Fri, Mar 14, 2008 at 5:47 PM, integr8e <email address hidden> wrote:

> With me, >>>all<<< network traffic was stopped whenever I connected to
> my university's VPN tunnel; I got it working, though, following Balaji's
> post (thanks, by the way). Maybe resolvconf was the culprit???
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2008-03-14:

#23

Download full text (3.6 KiB)

Morgan,

Using sudo is the right way to use vpnc. The problem is not that. This is
explained below:

Case 0: Not connected to VPN
Description: Can browse the web freely. This is heaven. But I can't see my
company's internal stuff. This is intended. I need VPN to connect.

Case 1: You are connected to your office network through VPN on Ubuntu
Description: You can read all pages on your intranet, your company's
internal pages are accessible. However, websites outside your company's
domain are not accessible. Example: Yahoo/Gmal is inaccessible when an
employee is remotely connected to their network through VPN. One can't even
browse through IEEEXplore through the company's login because to do so you
need to be inside the campus. You can't even search something on Google.
Your normal internet traffic is being routed through the VPN and the VPN
gateway does not recognize http://www.google.com You can't ask your company
to change their VPN gateway to a DNS.
Result: User switches to windows in search of better VPN programs. Not VPN's
fault. This is a matter of proxies.

Case 2: You are connected to your office network through VPN on Ubuntu -
This is how things are right now.
Description: User realizes that using the company's proxy will solve a lot
of his problems. He can now browse all those pages of the internet outside
his company's domain that he could access from his office. If the proxy
however blocks a number of websites that the user is interested in viewing.
For example his bank account or his personal email. These are not accessible
through the proxy because they are not accessible in the company campus
either and the same proxy applies everywhere. But connecting remotely has to
add the advantage of being able to access pages of the web that are not
accessible by bypassing the VPN. This is not happening.
Result: User is frustrated. He can't chat or do his personal work when he is
on the company's network. It is plain irritating.

Case 3: You are connected to your office networ through VPN on Ubuntu - This
is how things should be and we want it to be
Description: You can access all websites. If a website is blocked by your
company network, VPN should direct the request out of the VPN directly
through your normal internet connection and let you browse your personal
emails for example. You should be able to chat with your friends or make
personal bank transactions while on company network without having to change
the proxy.
Result: User is very happy! :)

Did you get it?

Thanks,
Balaji

On Sat, Mar 15, 2008 at 3:27 AM, Mackenzie Morgan <email address hidden> wrote:

> OK if I connect using network-manager-vpnc, all traffic runs into the
> "please connect to the VPN" gateway page. If I use the "sudo vpnc"
> command,
> though, it all works perfectly fine. Is that the same for you guys?
>
> On Fri, Mar 14, 2008 at 5:47 PM, integr8e <email address hidden> wrote:
>
> > With me, >>>all<<< network traffic was stopped whenever I connected to
> > my university's VPN tunnel; I got it working, though, following Balaji's
> > post (thanks, by the way). Maybe resolvconf was the culprit???
> >
> > --
> > No default internet traffic after connecting to VPN
>...

Morgan,

Using sudo is the right way to use vpnc. The problem is not that. This is
explained below:

Case 0: Not connected to VPN
Description: Can browse the web freely. This is heaven. But I can't see my
company's internal stuff. This is intended. I need VPN to connect.

Case 1: You are connected to your office network through VPN on Ubuntu
Description: You can read all pages on your intranet, your company's
internal pages are accessible. However, websites outside your company's
domain are not accessible. Example: Yahoo/Gmal is inaccessible when an
employee is remotely connected to their network through VPN. One can't even
browse through IEEEXplore through the company's login because to do so you
need to be inside the campus. You can't even search something on Google.
Your normal internet traffic is being routed through the VPN and the VPN
gateway does not recognize http://www.google.com You can't ask your company
to change their VPN gateway to a DNS.
Result: User switches to windows in search of better VPN programs. Not VPN's
fault. This is a matter of proxies.

Case 2: You are connected to your office network through VPN on Ubuntu -
This is how things are right now.
Description: User realizes that using the company's proxy will solve a lot
of his problems. He can now browse all those pages of the internet outside
his company's domain that he could access from his office. If the proxy
however blocks a number of websites that the user is interested in viewing.
For example his bank account or his personal email. These are not accessible
through the proxy because they are not accessible in the company campus
either and the same proxy applies everywhere. But connecting remotely has to
add the advantage of being able to access pages of the web that are not
accessible by bypassing the VPN. This is not happening.
Result: User is frustrated. He can't chat or do his personal work when he is
on the company's network. It is plain irritating.

Case 3: You are connected to your office networ through VPN on Ubuntu - This
is how things should be and we want it to be
Description: You can access all websites. If a website is blocked by your
company network, VPN should direct the request out of the VPN directly
through your normal internet connection and let you browse your personal
emails for example. You should be able to chat with your friends or make
personal bank transactions while on company network without having to change
the proxy.
Result: User is very happy! :)

Did you get it?

Thanks,
Balaji

On Sat, Mar 15, 2008 at 3:27 AM, Mackenzie Morgan <macoafi@gmail.com> wrote:

> OK if I connect using network-manager-vpnc, all traffic runs into the
> "please connect to the VPN" gateway page.  If I use the "sudo vpnc"
> command,
> though, it all works perfectly fine.  Is that the same for you guys?
>
> On Fri, Mar 14, 2008 at 5:47 PM, integr8e <integr8e@gmail.com> wrote:
>
> > With me, >>>all<<< network traffic was stopped whenever I connected to
> > my university's VPN tunnel; I got it working, though, following Balaji's
> > post (thanks, by the way).  Maybe resolvconf was the culprit???
> >
> > --
> > No default internet traffic after connecting to VPN
> > https://bugs.launchpad.net/bugs/124663
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
> Mackenzie Morgan
> Linux User #432169
> ACM Member #3445683
> http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
> apt-get moo
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

-- 
Balaji

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-03-14:

#24

OK there's what I've got:
- If I'm on campus using a wired network, I can access anything.
- If I'm on wireless using the command line vpnc, I can access anything.
- If I'm on wireless using the network-manager-vpnc GUI, I can't access
anything.

So, I should file this as a separate bug?

On Fri, Mar 14, 2008 at 6:30 PM, Balaji <email address hidden>
wrote:

> Morgan,
>
> Using sudo is the right way to use vpnc. The problem is not that. This is
> explained below:
>
> Case 0: Not connected to VPN
> Description: Can browse the web freely. This is heaven. But I can't see my
> company's internal stuff. This is intended. I need VPN to connect.
>
> Case 1: You are connected to your office network through VPN on Ubuntu
> Description: You can read all pages on your intranet, your company's
> internal pages are accessible. However, websites outside your company's
> domain are not accessible. Example: Yahoo/Gmal is inaccessible when an
> employee is remotely connected to their network through VPN. One can't
> even
> browse through IEEEXplore through the company's login because to do so you
> need to be inside the campus. You can't even search something on Google.
> Your normal internet traffic is being routed through the VPN and the VPN
> gateway does not recognize http://www.google.com You can't ask your
> company
> to change their VPN gateway to a DNS.
> Result: User switches to windows in search of better VPN programs. Not
> VPN's
> fault. This is a matter of proxies.
>
> Case 2: You are connected to your office network through VPN on Ubuntu -
> This is how things are right now.
> Description: User realizes that using the company's proxy will solve a lot
> of his problems. He can now browse all those pages of the internet outside
> his company's domain that he could access from his office. If the proxy
> however blocks a number of websites that the user is interested in
> viewing.
> For example his bank account or his personal email. These are not
> accessible
> through the proxy because they are not accessible in the company campus
> either and the same proxy applies everywhere. But connecting remotely has
> to
> add the advantage of being able to access pages of the web that are not
> accessible by bypassing the VPN. This is not happening.
> Result: User is frustrated. He can't chat or do his personal work when he
> is
> on the company's network. It is plain irritating.
>
> Case 3: You are connected to your office networ through VPN on Ubuntu -
> This
> is how things should be and we want it to be
> Description: You can access all websites. If a website is blocked by your
> company network, VPN should direct the request out of the VPN directly
> through your normal internet connection and let you browse your personal
> emails for example. You should be able to chat with your friends or make
> personal bank transactions while on company network without having to
> change
> the proxy.
> Result: User is very happy! :)
>
> Did you get it?
>
> Thanks,
> Balaji

--
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo

OK there's what I've got:
- If I'm on campus using a wired network, I can access anything.
- If I'm on wireless using the command line vpnc, I can access anything.
- If I'm on wireless using the network-manager-vpnc GUI, I can't access
anything.

So, I should file this as a separate bug?

On Fri, Mar 14, 2008 at 6:30 PM, Balaji <balaji.ramasubramanian@gmail.com>
wrote:

> Morgan,
>
> Using sudo is the right way to use vpnc. The problem is not that. This is
> explained below:
>
> Case 0: Not connected to VPN
> Description: Can browse the web freely. This is heaven. But I can't see my
> company's internal stuff. This is intended. I need VPN to connect.
>
> Case 1: You are connected to your office network through VPN on Ubuntu
> Description: You can read all pages on your intranet, your company's
> internal pages are accessible. However, websites outside your company's
> domain are not accessible. Example: Yahoo/Gmal is inaccessible when an
> employee is remotely connected to their network through VPN. One can't
> even
> browse through IEEEXplore through the company's login because to do so you
> need to be inside the campus. You can't even search something on Google.
> Your normal internet traffic is being routed through the VPN and the VPN
> gateway does not recognize http://www.google.com You can't ask your
> company
> to change their VPN gateway to a DNS.
> Result: User switches to windows in search of better VPN programs. Not
> VPN's
> fault. This is a matter of proxies.
>
> Case 2: You are connected to your office network through VPN on Ubuntu -
> This is how things are right now.
> Description: User realizes that using the company's proxy will solve a lot
> of his problems. He can now browse all those pages of the internet outside
> his company's domain that he could access from his office. If the proxy
> however blocks a number of websites that the user is interested in
> viewing.
> For example his bank account or his personal email. These are not
> accessible
> through the proxy because they are not accessible in the company campus
> either and the same proxy applies everywhere. But connecting remotely has
> to
> add the advantage of being able to access pages of the web that are not
> accessible by bypassing the VPN. This is not happening.
> Result: User is frustrated. He can't chat or do his personal work when he
> is
> on the company's network. It is plain irritating.
>
> Case 3: You are connected to your office networ through VPN on Ubuntu -
> This
> is how things should be and we want it to be
> Description: You can access all websites. If a website is blocked by your
> company network, VPN should direct the request out of the VPN directly
> through your normal internet connection and let you browse your personal
> emails for example. You should be able to chat with your friends or make
> personal bank transactions while on company network without having to
> change
> the proxy.
> Result: User is very happy! :)
>
> Did you get it?
>
> Thanks,
> Balaji

-- 
Mackenzie Morgan
Linux User #432169
ACM Member #3445683
http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
apt-get moo

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2008-03-15:

#25

Download full text (4.3 KiB)

Do add a comment on this bug and provide a link to your new bug if you are
filing a new one.

Your problem appears pretty closely related. As I suggested earlier, it
appears that nm-vpnc is doing some extra step that is offending. It is doing
more stuff than vpnc does and that is the real problem. The extra stuff that
nm-vpnc seems to do is causing our normal internet traffic to stop.

In your case however, it appears to be the issue that integr8e has had. Try
removing resolvconf. I think your problems should go too if that is the only
problem you are facing. If not try the rest of what I told him to do 3-4
posts back. In any case, I believe you should be filing it under this bug
report only. Please do check your specific issue again do as you deem fit.

Thanks,
Balaji

On Sat, Mar 15, 2008 at 4:15 AM, Mackenzie Morgan <email address hidden> wrote:

> OK there's what I've got:
> - If I'm on campus using a wired network, I can access anything.
> - If I'm on wireless using the command line vpnc, I can access anything.
> - If I'm on wireless using the network-manager-vpnc GUI, I can't access
> anything.
>
> So, I should file this as a separate bug?
>
>
> On Fri, Mar 14, 2008 at 6:30 PM, Balaji <email address hidden>
> wrote:
>
> > Morgan,
> >
> > Using sudo is the right way to use vpnc. The problem is not that. This
> is
> > explained below:
> >
> > Case 0: Not connected to VPN
> > Description: Can browse the web freely. This is heaven. But I can't see
> my
> > company's internal stuff. This is intended. I need VPN to connect.
> >
> > Case 1: You are connected to your office network through VPN on Ubuntu
> > Description: You can read all pages on your intranet, your company's
> > internal pages are accessible. However, websites outside your company's
> > domain are not accessible. Example: Yahoo/Gmal is inaccessible when an
> > employee is remotely connected to their network through VPN. One can't
> > even
> > browse through IEEEXplore through the company's login because to do so
> you
> > need to be inside the campus. You can't even search something on Google.
> > Your normal internet traffic is being routed through the VPN and the VPN
> > gateway does not recognize http://www.google.com You can't ask your
> > company
> > to change their VPN gateway to a DNS.
> > Result: User switches to windows in search of better VPN programs. Not
> > VPN's
> > fault. This is a matter of proxies.
> >
> > Case 2: You are connected to your office network through VPN on Ubuntu -
> > This is how things are right now.
> > Description: User realizes that using the company's proxy will solve a
> lot
> > of his problems. He can now browse all those pages of the internet
> outside
> > his company's domain that he could access from his office. If the proxy
> > however blocks a number of websites that the user is interested in
> > viewing.
> > For example his bank account or his personal email. These are not
> > accessible
> > through the proxy because they are not accessible in the company campus
> > either and the same proxy applies everywhere. But connecting remotely
> has
> > to
> > add the advantage of being able to access pages of the web that are not
> >...

Do add a comment on this bug and provide a link to your new bug if you are
filing a new one.

Your problem appears pretty closely related. As I suggested earlier, it
appears that nm-vpnc is doing some extra step that is offending. It is doing
more stuff than vpnc does and that is the real problem. The extra stuff that
nm-vpnc seems to do is causing our normal internet traffic to stop.

In your case however, it appears to be the issue that integr8e has had. Try
removing resolvconf. I think your problems should go too if that is the only
problem you are facing. If not try the rest of what I told him to do 3-4
posts back. In any case, I believe you should be filing it under this bug
report only. Please do check your specific issue again do as you deem fit.

Thanks,
Balaji

On Sat, Mar 15, 2008 at 4:15 AM, Mackenzie Morgan <macoafi@gmail.com> wrote:

> OK there's what I've got:
> - If I'm on campus using a wired network, I can access anything.
> - If I'm on wireless using the command line vpnc, I can access anything.
> - If I'm on wireless using the network-manager-vpnc GUI, I can't access
> anything.
>
> So, I should file this as a separate bug?
>
>
> On Fri, Mar 14, 2008 at 6:30 PM, Balaji <balaji.ramasubramanian@gmail.com>
> wrote:
>
> > Morgan,
> >
> > Using sudo is the right way to use vpnc. The problem is not that. This
> is
> > explained below:
> >
> > Case 0: Not connected to VPN
> > Description: Can browse the web freely. This is heaven. But I can't see
> my
> > company's internal stuff. This is intended. I need VPN to connect.
> >
> > Case 1: You are connected to your office network through VPN on Ubuntu
> > Description: You can read all pages on your intranet, your company's
> > internal pages are accessible. However, websites outside your company's
> > domain are not accessible. Example: Yahoo/Gmal is inaccessible when an
> > employee is remotely connected to their network through VPN. One can't
> > even
> > browse through IEEEXplore through the company's login because to do so
> you
> > need to be inside the campus. You can't even search something on Google.
> > Your normal internet traffic is being routed through the VPN and the VPN
> > gateway does not recognize http://www.google.com You can't ask your
> > company
> > to change their VPN gateway to a DNS.
> > Result: User switches to windows in search of better VPN programs. Not
> > VPN's
> > fault. This is a matter of proxies.
> >
> > Case 2: You are connected to your office network through VPN on Ubuntu -
> > This is how things are right now.
> > Description: User realizes that using the company's proxy will solve a
> lot
> > of his problems. He can now browse all those pages of the internet
> outside
> > his company's domain that he could access from his office. If the proxy
> > however blocks a number of websites that the user is interested in
> > viewing.
> > For example his bank account or his personal email. These are not
> > accessible
> > through the proxy because they are not accessible in the company campus
> > either and the same proxy applies everywhere. But connecting remotely
> has
> > to
> > add the advantage of being able to access pages of the web that are not
> > accessible by bypassing the VPN. This is not happening.
> > Result: User is frustrated. He can't chat or do his personal work when
> he
> > is
> > on the company's network. It is plain irritating.
> >
> > Case 3: You are connected to your office networ through VPN on Ubuntu -
> > This
> > is how things should be and we want it to be
> > Description: You can access all websites. If a website is blocked by
> your
> > company network, VPN should direct the request out of the VPN directly
> > through your normal internet connection and let you browse your personal
> > emails for example. You should be able to chat with your friends or make
> > personal bank transactions while on company network without having to
> > change
> > the proxy.
> > Result: User is very happy! :)
> >
> > Did you get it?
> >
> > Thanks,
> > Balaji
>
>
>
> --
> Mackenzie Morgan
> Linux User #432169
> ACM Member #3445683
> http://ubuntulinuxtipstricks.blogspot.com <-my blog of Ubuntu stuff
> apt-get moo
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>

-- 
Balaji

Revision history for this message

Balaji (balaji-ramasubramanian) wrote on 2008-05-05: Dear friend,

#26

Dear friend,
      We are so sorry for hope I don't disturb you .
we are an authorized export wholesaler.
we mainly supply Laptops Notebooks, Digital Cameras ,Digital Video,
Television,Ipods, Mobile, PDA, GPS,PS3,PSP and so on.
We will supply the best price and high qulity items.
     you could register to be a member of our website.
and you can order it online and fill the order letter,
or contact me for the items through email.
if you have any questions,please contact us by the following ways:
  WEBSITE: <http://www.teuec.com/>
      MSN: <email address hidden>
    EMAIL: <email address hidden>
    thanks for your golden time.
    best wishes to you and all your family members.

Revision history for this message

Manfred Moser (mosabua) wrote on 2008-10-02:

#27

I can reproducible connect with the command line vpnc with the internet connection being tunneled correctly. However if I use the same connection details with knetworkmanager internet is not tunneled and I can only connect network hosts in the network I vpn into.

Revision history for this message

Marc Luethi (netztier) wrote on 2008-11-19:

#28

Download full text (3.4 KiB)

In answer to what Balaij describes in his "use case 3" (inhttps://bugs.launchpad.net/ubuntu/+source/vpnc/+bug/124663/comments/23):

That is precisely what enterprise networks don't want to happen, because it's a security nightmare. If I had a user trying this on my employer's remote access VPN, I'd have the Chief Security Officer all over his back.

If the VPN Tunnel is up, your system becomes part of the enterprise network, and therefore must use any internet access facilities and services (DNS Servers that can resolve internet names, virus scanning proxy servers etc.) as if the system were connected to the internal network.

That of course is true if we are talking of "full integration", which I consider the normal use case. There are others, where an enterprise gives VPN access to a customer or contractor. Here, the VPN Tunnel must not give full access to the internal network, but only a few selected hosts. In that case, a proper configuration should seed out a few bits of routing information to the clients and leave their routing config untouched otherwise. Yet, there should be a network firewall protecting these allowed hosts against the VPN device where contractor's tunnels terminate.

On a "full integration" scenario, allowing traffic to bypass the tunnel becomes a violation of security policies - it is equivalent to having a laptop plugged into the wired enterprise LAN and it's WiFi NIC associated with the coffee shop's public WiFi donwstairs.

That is why having the default route point to a next hop beyond the tunnel interface is - IMHO - the correct behaviour, and why this is a feature, not a bug. It's kind of disturbing that no one bar the orginal poster has ever shown the output of "netstat -nr" in this thread.

Adding a second default route is somewhat questionable - you'd need a (summary) static route for your enterprise network on the tun0 interface and a single default route towards your internet router. Mutliple default routes always cause confusion.

Here's how to do it manually:

1.Remove default-through-tunnel route:
sudo route delete 0.0.0.0/0 gw 0.0.0.0 tun0

2. Add route for enterprise network (possibly multiple, ask your enterprise's network admin for info about <network>/<prefix>)
sudo route add <network>/<prefix> gw 0.0.0.0 tun0

3. Add new default route, where <local router> and ethX are your local LANs default gateway and ethX the interface connecting to it:
sudo route add default gw <local router> ethX

Current (8.10) network-manager-vpnc even allows you to add these static routes via GUI, and while doing so, leaves the default route as it was before.

However, you still have the problem of DNS:

/etc/resolv.conf is rewritten to use the enterprise network's DNS servers, which might be a "hard" requirement if you wanted to connect to systems whose names can only be resolved by their DNS. If these can also resolve internet names, you're lucky, even if somewhat hampered by possible DNS lookup delay, because lookup requests go through the tunnel (which might have it's other end somewhere far away), while your normal web request still uses your local internet access.

If however the enterprise's DNS can't resolve in...

In answer to what Balaij describes in his "use case 3" (inhttps://bugs.launchpad.net/ubuntu/+source/vpnc/+bug/124663/comments/23):

That is precisely what enterprise networks don't want to happen, because it's a security nightmare. If I had a user trying this on my employer's remote access VPN, I'd have the Chief Security Officer all over his back.

If the VPN Tunnel is up, your system becomes part of the enterprise network, and therefore must use any internet access facilities and services (DNS Servers that can resolve internet names, virus scanning proxy servers etc.) as if the system were connected to the internal network.

That of course is true if we are talking of "full integration", which I consider the normal use case. There are others, where an enterprise gives VPN access to a customer or contractor. Here, the VPN Tunnel must not give full access to the internal network, but only a few selected hosts. In that case, a proper configuration should seed out a few bits of routing information to the clients and leave their routing config untouched otherwise. Yet, there should be a network firewall protecting these allowed hosts against the VPN device where contractor's tunnels terminate.

On a "full integration" scenario, allowing traffic to bypass the tunnel becomes a violation of security policies - it is equivalent to having a laptop plugged into the wired enterprise LAN and it's WiFi NIC associated with the coffee shop's public WiFi donwstairs.

That is why having the default route point to a next hop beyond the tunnel interface is  - IMHO - the correct behaviour, and why this is a feature, not a bug. It's kind of disturbing that no one bar the orginal poster has ever shown the output of "netstat -nr" in this thread.

Adding a second default route is somewhat questionable - you'd need a (summary) static route for your enterprise network on the tun0 interface and a single default route towards your internet router. Mutliple default routes always cause confusion.

Here's how to do it manually:

1.Remove default-through-tunnel route:
sudo route delete 0.0.0.0/0 gw 0.0.0.0 tun0

2. Add route for enterprise network (possibly multiple, ask your enterprise's network admin for info about <network>/<prefix>)
sudo route add <network>/<prefix> gw 0.0.0.0 tun0

3. Add new default route, where <local router> and ethX are your local LANs default gateway and ethX the interface connecting to it:
sudo route add default gw <local router> ethX

Current (8.10) network-manager-vpnc even allows you to add these static routes via GUI, and while doing so, leaves the default route as it was before.

However, you still have the problem of DNS:

/etc/resolv.conf is rewritten to use the enterprise network's DNS servers, which might be a "hard" requirement if you wanted to connect to systems whose names can only be resolved by their DNS. If these can also resolve internet names, you're lucky, even if somewhat hampered by possible DNS lookup delay, because lookup requests go through the tunnel (which might have it's other end somewhere far away), while your normal web request still uses your local internet access.

If however the enterprise's DNS can't resolve internet names, you'll get stuck: manually rewriting /etc/resolv.conf to use some local DNS can help, but then you'll probably lose visibility and resolve-ability of enterprise host names...

Again: I consider it a feature, not a bug. If you require other scenarios, you can work around it.

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-11-19:

#29

I agree with netzier. This isn't a bug. Network-manager-vpnc is broken, in my opinion, for *not* putting everything through the default route.

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-11-20:

#30

To expand upon that:
VPNs are supposed to be as if you were on that network. They are encrypted with IPSec so that no data is transmitted unencrypted on the local network. Instead, everything goes through the encrypted tunnel. If any data is allowed to automatically circumvent the tunnel, there is no integrity in the system. The way it currently is, the user knows that their data is securely encrypted. If traffic circumvents the tunnel with no user intervention and without the user's knowledge, the user could *very* easily be exposing private data to anyone with a wireless sniffer on the local network. That would be a a *major* security concern.

Revision history for this message

Eric Weidner (eric-pumavision) wrote on 2008-12-05:

#31

I am having this problem with network-manager-openvpn but the discussion seems relevant. In my case, in version .6 of nm-openvpn, there was an option (not the default) that said "Only use VPN for these addresses...". In .7, I have been unable to replicate that setting and therefore lose my fast local internet when on VPN. The OpenVPN command line utility works as I expect since we are not pushing the redirect-gateway option to force the default route through the VPN.

Am I just missing the ability to replicate the older option?

Are you guys saying that the Network Manager project has intentionally removed these options between .6 and .7 in order to enforce the stricter security policy? If so, isn't that overriding the decisions made by a) the underlying vpn solution creators (cisco, openvpn, etc) and b) the organization implementing the solution?

I'm just looking for a definitive answer here so I can stop banging my head on trying to replicate my .6 setup if it's just not going to work. I understand the tradeoffs and personally would prefer the flexibility to make those decisions for my particular uses. In my personal usage, I can decide to use the less secure method that doesn't force all of my internet traffic over across my dsl line and in my organization, I can configure my server to tell the clients to use a more secure option.

Or I could just be missing something in the setup.

Please clarify this for me. The way it's currently working, I am falling back to command line OpenVPN client to get the desired functionality for my current use case.

Thanks.

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2008-12-05: Re: [Bug 124663] Re: No default internet traffic after connecting to VPN

#32

> Are you guys saying that the Network Manager project has intentionally
> removed these options between .6 and .7 in order to enforce the stricter
> security policy?

My guess is they thought it was unnecessary and wanted to simplify the
GUI. I was talking about security policy because the reporter was
asking that NM *ignore* the network's settings and never set the default
route that the network tries to push.

Revision history for this message

Eric Weidner (eric-pumavision) wrote on 2008-12-05:

#33

> My guess is they thought it was unnecessary and wanted to simplify the
> GUI. I was talking about security policy because the reporter was
> asking that NM *ignore* the network's settings and never set the default
> route that the network tries to push.
>

OK, thanks for the clarification.

I'll try to get some answers from someone related to the openvpn
portion then. I've filed the following
https://bugs.launchpad.net/ubuntu/+source/network-manager-openvpn/+bug/305584
to try to get some answers. At the least the panel is non-intuitive
and has no instructions.

Revision history for this message

Artships (ubuntubugs-johndouglass-deactivatedaccount) wrote on 2009-02-09:

#34

I know I'm late to this party but...

I see netzier and Mackenzie Morgan's point, that once you've established a VPN tunnel all traffic should go through it as a security feature, but I still prefer the convenience of routing some traffic through my ISP, too. I too wish someone brighter than I could fix the script to allow it. I suspect it can be done because that is my experience with a VPN client from within a Virtualbox virtual machine - Inside the virtual machine I can only access places on the other end of its VPN tunnel, while on my host machine I see the rest of the world through my ISP.

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2009-02-09:

#35

Then you can do that using the "route" command. The fact is that when
it is by default configured the way you want, everyone who *requires* a
VPN to get any internet access at all gets NONE and thus have no way to
read online explanations of how to set which applications should use
which route. It would create not only a security problem but much
bigger userability problems than the one you are having.

Revision history for this message

Popsicle-Pete (bclements-forums) wrote on 2009-02-25:

#36

Has this issue (VPNc / Network Manager dropping internet traffic) been resolved? I have been searching the net for the past week hoping to find a solution. I am running FC10 (2.6.27.15-170.2.24.fc10.i686) and receive the exact same behavior described by Balaji. Although I'm not on the Ubuntu platform this problem doesn't appear to be related directly with the distro. I am running the latest versions of VPNc and Network Manager.

My company is running a Cisco VPN, supporting Windows / Cisco VPN client configurations. I have the .pcf files which I imported into the VPNc plugin via Network Manager. I get a successful connection to the vpn tunnel but internet traffic drops immediately. I have been logging my troubleshooting process over on the Fedora forums (http://forums.fedoraforum.org/showthread.php?t=214636).

If you have any tips for resolving this issue please let me know.

Revision history for this message

Mackenzie Morgan (maco.m) wrote on 2009-02-25:

#37

This honestly is distro-specific. Xandros will leave the old default route and
just add the one that the VPN tells it to add. The result is that Firefox
still hits the gateway page that yells at he user to start the vpn
client..when they already have.

Current behaviour on Ubuntu is to replace the existing route with what the VPN
server says is the correct route. This means that if you are trying to get on
company wireless and need everything to go through the VPN, you're in great
shape. If you're remote and only want certain IPs to go through the VPN, I
believe network manager has an option in the GUI to only use the VPN for
___________________________ and then you list the IPs.

Revision history for this message

Version7x (version7x) wrote on 2009-04-13:

#38

Following up on MM's post above...

In 8.10 (and possibly otheres) there was a feature in Network manager to add subnets to force to use the vpn traffic. This works wonderfully for many situtuations (if you know all of the subnets you'll be using and don't have any duplicates). However in 9.04, this feature is gone (at this time).

Not sure if that confuses anything, but thought I'd throw it in!

Revision history for this message

Doug Schaapveld (djschaap) wrote on 2009-04-16:

#39

Version7x, are you referring to the "Routes..." dialog under the IPv4 tab? It appears to be there on my Jaunty box (as of today, anyway).

All,
The behavior of sending only internal traffic through the VPN tunnel is commonly called "split tunneling". (Search on Wikipedia for more info.) While large enterprises may consider it a security risk, smaller companies with limited bandwidth tend to prefer using split tunneling (in my experience) to improve performance. Split tunneling is normally configured at the VPN concentrator (head end) rather than the client (though the client must understand and act upon the options passed by the concentrator).

In any event, I believe Jaunty can be configured (via NM GUI) to work properly in all of these situations. Bug 207506 has info on how to allow split tunneling in Jaunty (oddly, Jaunty disables split operation by default, unlike Intrepid, which simply respects the VPN concentrator's wishes).

(Disclaimer: This is based on my observations and a pre-release OS. Apologies if anything is wrong!)

Revision history for this message

Version7x (version7x) wrote on 2009-04-16: Re: [Bug 124663] Re: No default internet traffic after connecting to VPN

#40

Download full text (8.8 KiB)

I have the box as well, however, for the last couple updates, it has been
grayed out. For the life of me, there is no option I can configure to allow
me to add text in to that field.

In 8.04/10 I was able modify this field after an import of our company's
PCF file.

If I'm missing something really obvious, let me know!

Thanks

On Thu, Apr 16, 2009 at 11:04 AM, Doug Schaapveld <email address hidden>wrote:

> Version7x, are you referring to the "Routes..." dialog under the IPv4
> tab? It appears to be there on my Jaunty box (as of today, anyway).
>
> All,
> The behavior of sending only internal traffic through the VPN tunnel is
> commonly called "split tunneling". (Search on Wikipedia for more info.)
> While large enterprises may consider it a security risk, smaller companies
> with limited bandwidth tend to prefer using split tunneling (in my
> experience) to improve performance. Split tunneling is normally configured
> at the VPN concentrator (head end) rather than the client (though the client
> must understand and act upon the options passed by the concentrator).
>
> In any event, I believe Jaunty can be configured (via NM GUI) to work
> properly in all of these situations. Bug 207506 has info on how to
> allow split tunneling in Jaunty (oddly, Jaunty disables split operation
> by default, unlike Intrepid, which simply respects the VPN
> concentrator's wishes).
>
> (Disclaimer: This is based on my observations and a pre-release OS.
> Apologies if anything is wrong!)
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “vpnc” source package in Ubuntu: Confirmed
>
> Bug description:
> I am connecting to my office VPN using the Network Manager applet's VPN
> connection. I am not sure which VPN tool is being used, because to get VPN
> working right, I had to install, vpnc, network-manager-vpnc, openvpn,
> network-manager-openvpn, pptpd and network-manager-pptp - all of them to
> start working.
>
> Now if I login to the VPN using my company's profile .pcf file, it logs in
> correctly and I am able to use the office network correctly. But the default
> internet traffic gets disconnected and I can't surf the web while connected
> to office.
>
> Upon digging I found that even the default traffic is trying to go through
> the VPN tunnel.
>
> I wish someone could help me with this and have the following information
> for you:
>
> A. Before connecting to VPN:
> $ cat /etc/resolv.conf
> # generated by NetworkManager, do not edit!
>
> nameserver 192.168.1.1
> $ netstat -r
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt
> Iface
> 192.168.1.0 * 255.255.255.0 U 0 0 0
> eth0
> default 192.168.1.1 0.0.0.0 UG 0 0 0
> eth0
>
> $ ifconfig -a
> eth0 Link encap:Ethernet HWaddr 00:16:36:74:57:8E
> inet addr:192.168.1.4 Bcast:192.168.1.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:142850 errors:0 dropped:0 o...

I have the box as well, however,  for the last couple updates, it has been
grayed out.  For the life of me, there is no option I can configure to allow
me to add text in to that field.

In 8.04/10  I was able modify this field after an import of our company's
PCF file.

If I'm missing something really obvious, let me know!

Thanks

On Thu, Apr 16, 2009 at 11:04 AM, Doug Schaapveld <djschaap@gmail.com>wrote:

> Version7x, are you referring to the "Routes..." dialog under the IPv4
> tab?  It appears to be there on my Jaunty box (as of today, anyway).
>
> All,
> The behavior of sending only internal traffic through the VPN tunnel is
> commonly called "split tunneling".  (Search on Wikipedia for more info.)
>  While large enterprises may consider it a security risk, smaller companies
> with limited bandwidth tend to prefer using split tunneling (in my
> experience) to improve performance.  Split tunneling is normally configured
> at the VPN concentrator (head end) rather than the client (though the client
> must understand and act upon the options passed by the concentrator).
>
> In any event, I believe Jaunty can be configured (via NM GUI) to work
> properly in all of these situations.  Bug 207506 has info on how to
> allow split tunneling in Jaunty (oddly, Jaunty disables split operation
> by default, unlike Intrepid, which simply respects the VPN
> concentrator's wishes).
>
> (Disclaimer: This is based on my observations and a pre-release OS.
> Apologies if anything is wrong!)
>
> --
> No default internet traffic after connecting to VPN
> https://bugs.launchpad.net/bugs/124663
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “vpnc” source package in Ubuntu: Confirmed
>
> Bug description:
> I am connecting to my office VPN using the Network Manager applet's VPN
> connection. I am not sure which VPN tool is being used, because to get VPN
> working right, I had to install, vpnc, network-manager-vpnc, openvpn,
> network-manager-openvpn, pptpd and network-manager-pptp - all of them to
> start working.
>
> Now if I login to the VPN using my company's profile .pcf file, it logs in
> correctly and I am able to use the office network correctly. But the default
> internet traffic gets disconnected and I can't surf the web while connected
> to office.
>
> Upon digging I found that even the default traffic is trying to go through
> the VPN tunnel.
>
> I wish someone could help me with this and have the following information
> for you:
>
> A. Before connecting to VPN:
> $ cat /etc/resolv.conf
> # generated by NetworkManager, do not edit!
>
> nameserver 192.168.1.1
> $ netstat -r
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 192.168.1.0     *               255.255.255.0   U         0 0          0
> eth0
> default         192.168.1.1     0.0.0.0         UG        0 0          0
> eth0
>
> $ ifconfig -a
> eth0      Link encap:Ethernet  HWaddr 00:16:36:74:57:8E
>          inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>          RX packets:142850 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:142033 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:97208755 (92.7 MiB)  TX bytes:18752118 (17.8 MiB)
>          Interrupt:10 Base address:0x4000
>
> lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1
>          RX packets:491 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:491 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:55830 (54.5 KiB)  TX bytes:55830 (54.5 KiB)
>
> wlan0     Link encap:Ethernet  HWaddr 00:14:A5:C3:F0:2F
>          UP BROADCAST MULTICAST  MTU:1500  Metric:1
>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>          Interrupt:9 Memory:b3200000-b3204000
>
> B. After connecting to the VPN:
> $ cat /etc/resolv.conf
> # generated by NetworkManager, do not edit!
> search amd.com
>
> nameserver 165.204.25.14
> nameserver 163.181.1.2
> $ netstat -r
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 203.101.113.70  castun.amd.com  255.255.255.255 UGH       0 0          0
> eth0
> 192.168.1.0     *               255.255.255.0   U         0 0          0
> eth0
> default         *               0.0.0.0         U         0 0          0
> tun0
> $ ifconfig -a
> eth0      Link encap:Ethernet  HWaddr 00:16:36:74:57:8E
>          inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
>          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>          RX packets:143049 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:142271 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:97292723 (92.7 MiB)  TX bytes:18796205 (17.9 MiB)
>          Interrupt:10 Base address:0x4000
>
> lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          UP LOOPBACK RUNNING  MTU:16436  Metric:1
>          RX packets:495 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:495 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>          RX bytes:57082 (55.7 KiB)  TX bytes:57082 (55.7 KiB)
>
> tun0      Link encap:UNSPEC  HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>          inet addr:165.204.27.133  P-t-P:165.204.27.133
>  Mask:255.255.255.128
>          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1412  Metric:1
>          RX packets:54 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:116 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:500
>          RX bytes:6797 (6.6 KiB)  TX bytes:17461 (17.0 KiB)
>
> wlan0     Link encap:Ethernet  HWaddr 00:14:A5:C3:F0:2F
>          UP BROADCAST MULTICAST  MTU:1500  Metric:1
>          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:1000
>          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>          Interrupt:9 Memory:b3200000-b3204000
>
> If I try to add another default gateway by using the command
> $ sudo route add default gw 192.168.1.1
>
> I can't get any output for `netstat -r` - it hangs. Instead:
> $ netstat -r -n
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags   MSS Window  irtt
> Iface
> 203.101.113.70  192.168.1.1     255.255.255.255 UGH       0 0          0
> eth0
> 192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0
> eth0
> 0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0
> eth0
> 0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0
> tun0
>
> At this stage, searching for a general web address keeps the browser simply
> waiting for response and eventually gives up.
>
> I am exasperated at this stage and don't understand too much of all these
> network configuration commands. It would be great if something could be done
> for semi-n00bs like me, who would prefer using software for the sake of
> getting other work done, rather than trying to debug or program as a
> passion.
>
> In my last attempt, I made a back-up copy of the vpnc-script in the
> /etc/vpnc directory and found that it actually deletes my existing default
> gateways and sets up a new gateway. To solve this, I tried to comment out
> those two lines from the shell procedure I find there:
>
>        set_default_route() {
>                $IPROUTE route | grep '^default' | fix_ip_get_output >
> "$DEFAULT_ROUTE_FILE"
> ###             $IPROUTE route $route_syntax_del default
> ###             $IPROUTE route add default dev "$TUNDEV"
>                $IPROUTE route flush cache
>        }
>
> This function is called in the do_connect procedure in this script and I
> thought that this should fix it. But it does not help at all.
>
> Now if some software programmer interested in fixing this asks me to
> provide more information, I would request him to actually help me through a
> Remote Desktop or some chat. I can't be knowing all Linux internals - I use
> Ubuntu because it helps my research. And it is my research that I want to
> spend time on rather than this kind of debugging. I have done my share of
> debugging and by all standards this is the most logical thing a person could
> do. If further there are hidden scripts and config files, that should be the
> software programmer's trouble. If you need some specific information from a
> particular file, please tell me the path of the file and not some funny name
> of the thing you want.
>

Revision history for this message

NTA (sakovias) wrote on 2009-04-18:

#41

Is there still any possibility to resolve this VPN issue on Intrepid? When I connect to a VPN I can't use my email or access any websites... so VPN just gets useless. I would really appreciate if someone gives an advice on how to fix this.

Revision history for this message

Donal (donaljoconnor) wrote on 2009-08-11:

#42

If you connect using vpnc on the command line you won't have this issue.

http://www.debuntu.org/how-to-connect-to-a-cisco-vpn-using-vpnc

Revision history for this message

ankit (ankbhadoria) wrote on 2012-08-12:

#43

i am having the same problem and i can't even ping individual ip's like of google.it says operation not permitted.plz help how do i resolve dis

Revision history for this message

Florian Schlichting (fschlich) wrote on 2012-08-12:

#44

I'm closing this bug as "invalid" because it's a mess of different issues, and I don't think the initial problem (network manager plugin not handling split routes properly) still stands.

If you feel you're experiencing a similar issue, please file a new report. If you're using NetworkManager rather than a command line to connect, file your bug against the network-manager-vpnc (or -openvpn, -openconnect, -pptp) package. And please make sure to include a few basic details about your configuration, including the output of the "ip addr" and "route" commands.

Changed in vpnc (Ubuntu):
status:	Confirmed → Invalid

Ubuntu
vpnc package

No default internet traffic after connecting to VPN

Bug Description

Other bug subscribers

Remote bug watches

Ubuntuvpnc package

No default internet traffic after connecting to VPN

Bug Description

Other bug subscribers

Remote bug watches

Ubuntu
vpnc package