intrepid network-manager-pptp does not have essential options

Bug #278309 reported by Mozg
70
This bug affects 10 people
Affects Status Importance Assigned to Milestone
NetworkManager
Fix Released
Low
network-manager-pptp (Ubuntu)
Triaged
Wishlist
Unassigned
Nominated for Intrepid by Bill Loucks
Nominated for Jaunty by Bill Loucks

Bug Description

Binary package hint: network-manager-pptp

The 0.7 version of network-manager-pptp does not have enough configuration options. The previous versions had the option to disable the use of VPN DNS servers and disable the default gateway through the VPN connection. These options are not longer available under the network-manager-pptp configuration wizard and I think they should be available under the advanced settings.

system in question: Intrepid
package in question: network-manager-pptp 0.7~~svn20080928t225540-0ubuntu1

Revision history for this message
JeSTeR7 (cblocker) wrote :

Wanted to confirm/agree with this. Not having the ability to disable the remote gateway is a deal break for me and sends me back to Hardy.

Revision history for this message
Chris DiMartino (vwchris) wrote :

I concur. This is a major problem. My desired setup for VPN usage is to tunnel all traffic to specific subnets through the VPN, and all other traffic goes out the normal default gateway for the network. Having the VPN interface forced as the default gateway makes the connection basically unusable. Additionally, there is no way to specify the MTU setting for the ppp interface, which tends to break my connection with any large packets. I usually set my MTU to 1412 and have no problems. With the current configuration I am forced to run a script after connecting to manually change the MTU to 1412 for the ppp0 interface.

Revision history for this message
Jasey (jason-rivers) wrote :

Confirming this.

The ability to not allow default route through a VPN connection is Vital to alot of VPN's - why wouldn't it be. you _HAVE_ the internet to get on the VPN, Why should you use our internet for your browsing that being the case?

our office has intentionally disabled VPN traffic to go out through it's routers for the reason that the office is charged for bandwidth, home users generally are not.

Changed in network-manager-pptp:
status: New → Confirmed
Revision history for this message
Marius Gedminas (mgedmin) wrote :

I'm also missing the pppd debug option, that let me debug pptp connection failures. Now I just get an error and have no idea why n-m in Intrepid won't connect to the VPN that I successfully used in Hardy.

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

I agree. VPN under Hardy worked brilliantly!! Now, under Intrepid I can't control traffic specific to the VPN connection and my VPN breaks often..... Rubbish!!! I'm in the crazy situation that I'm using a windows VM to use my office VPN connection. (I know I could use Hardy as VM, but not got that installed set up.) Why have the configuration options for VPN in intrepid been so heavily culled.??? I have posted a bug report regarding the instablity but no response from anyone yet.

Revision history for this message
Brian Kennelly (bkennelly+ubuntu) wrote :

I discovered that, if you add specific routes to the VPN definition, it preserved the existing default.

So, click "Routes" and add the VPN's subnet information to the table. You only need to fill in the IP and prefix.

I would still prefer to see this option explicitly exposed.

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Further to my earlier post. I will try Brian's suggestion. Interestingly, I can vastly improve the stability of the vpn connection by reducing the MTU of ppp0 to 1400 (what i beleive is the MS standard for the PPTP VPN protocol). This currently has to be done after connection to the VPN in a terminal but was previously a configurable option in Network Manager 0.6.6 but not . If the connection drops, it resets to its default MTU of 1496 and a terminal command needs issuing again. As a by product of this Pidgin that previously caused the VPN to fail now not only remains stable, but the MSN connection that has never been able to connect (in Hardy or Intrepid) now works with no problems.

Revision history for this message
Alexander Sack (asac) wrote :

could you add a summary which essential options are missing to the bug description please?

Changed in network-manager-pptp:
status: Confirmed → Incomplete
Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Brian. I wonder if you could post an example of the route you have used. I know what the subnet is, not sure at all what a prefix is.

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

For me the essential options are:
1. being able to specify the MTU for the ppp0 connection - i can't keep it stable with the default.
2. Being able to restrict traffic that uses the VPN - this may be possible now with the routing table but is very cryptic as to how it can be achieved. I can see that the routing table option may be a more configurable way to go so maybe some guidance as to how it can be used could be more appropriate.

Essentially, the options available under Network Manager 0.6.6 were it.

I would encourage others to post their preference too.

Revision history for this message
Mozg (andrei-arhont) wrote : Re: [Bug 278309] Re: intrepid network-manager-pptp does not have essential options

I will have a look at this problem

Andrei

----
On Nov 1, 2008 at 4:33pm, Alexander Sack wrote:

could you add a summary which essential options are missing to the bug
description please?

** Changed in: network-manager-pptp (Ubuntu)
       Status: Confirmed => Incomplete

--
intrepid network-manager-pptp does not have essential options
https://bugs.launchpad.net/bugs/278309
You received this bug notification because you are a direct subscriber
of the bug.

Revision history for this message
Brian Kennelly (bkennelly+ubuntu) wrote :

It is true that the routing table could be better organised. The Prefix is the number of bits in the subnet prefix. E.g., for subnet 192.168.20.0/24, the prefix is 24.

In this example, you would populate the first two columns of the table with "192.168.20.0" and "24", leaving the last two defaulted.

Revision history for this message
Alexander Sack (asac) wrote :

Brian, that doesnt matter here. if you want to discuss improvements unrelated to this bug please open a new one ;)

Revision history for this message
Brian Kennelly (bkennelly+ubuntu) wrote :

I understand, but other the implied criticism of "could be better organised", it was not meant to be a suggestion for improvement.
I was mainly trying to answer JazzyPenguin's question about the routing table, which provides a workaround for the originally reported problem, which was the lack of UI control for "No default route". It is not a visible option, but is implied by the presence of a custom routing table.
I do believe it has bearing on the bug, because the control may not be needed if its effects can be accomplished by the routing table. That allows for focus on the other missing controls.

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Ahh...thanks Brian, it is a different way of specifying the subnet mask. I have now tried your suggestion and done some testing with my VPN. With a routing entry I can get HTTP traffic to be routed through the default gateway. As tested by external IP address checkers correctly reporting my (and not my office IP address). With the VPN running I can use remote desktop protocols to machines on the office subnet (192.168.57.150) so that has to be working too. However, HTTP traffic is slower (i.e. web pages take longer to load) with the VPN running despite being routed via the default gateway. In addition one particular subnet address, that of the VPN server and office router (192.168.57.2), gets routed via my default gateway (192.168.15.5). The attached file shows my routing after issuing "route" in terminal with and without the VPN running. IP of the office X'd out for security reasons only, it showed the correct address. My routing table entry in the VPN is address = 192.168.57.0 Prefix = 24. My understanding is that any traffic to any IP address starting 192.168.57.XXX should be routed via the VPN. Why is traffic to 192.168.57.2 being directed over the default gateway, but traffic to other IP addresses in the subnet is correctly trafficked via the ppp0. Is this a bug in the VPN's routing table or some more global routing issue. Could my browser be using the VPN connection to resolve DNS thus slowing down web access? If so why.

PS. If this is no longer the place for this discussion I will happily continue elsewhere.

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Have added the above information to a more relevant bug

https://bugs.launchpad.net/ubuntu/+source/network-manager-pptp/+bug/113622

Will see what happens there.

Revision history for this message
Mozg (andrei-arhont) wrote :

A must have options for me are:

1. Ability not to use VPN as default route to the internet
2. Ability not to use VPN given DNS settings

Andrei

Alexander Sack wrote:
> could you add a summary which essential options are missing to the bug
> description please?
>
> ** Changed in: network-manager-pptp (Ubuntu)
> Status: Confirmed => Incomplete
>
>

Revision history for this message
Alexander Sack (asac) wrote :

Jazzy, most likely not much. plese open new bugs as i told you.

Revision history for this message
Alexander Sack (asac) wrote :

Mozg, thats not what this bug is about.

Revision history for this message
Mozg (andrei-arhont) wrote :

Alexander Sack wrote:
> Mozg, thats not what this bug is about.
>
>

Well, the reason why i have opened this bug was the lack of the ability
to alter default route and disable the use of vpn dns servers from the
pptp installation wizard or configuration menu. These options were a
part of 0.6 network manager and are lacking in 0.7.

Andrei

Revision history for this message
Alexander Sack (asac) wrote :

for pptp both should work now again ... we properly merge in the advance ip4settings for the ppp connection there. Try the latest PPA packages please (http://launchpad.net/~network-manager/+archive).

Revision history for this message
John (john-navarro) wrote :

I've opened the following but report with gnome:

http://bugzilla.gnome.org/show_bug.cgi?id=559116

nm-applet 0.70 is missing configuration settings that 0.66 had - specifically PPTP MTU. Without this I get a serious performance hit that results in a unusable PPTP connection. SYSLOG reports packet buffering, retransmists, and dropped packts. The workaround is to manually set the MTU after the tunnel has been established (ifconfig ppp0 mtu 1416). I used "1416" since this is the default value provided by nm-applet 0.66.

Revision history for this message
John (john-navarro) wrote :

This may be helpful to know as well - here are the pptp startup parameters on both platforms:

INTREPID 32bit
root 8459 8458 0 21:12 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pptp a.b.c.d --nolaunchpppd --logstring nm-pptp-service-8458 ipparam nm-pptp-service-8458 nodetach lock usepeerdns noipdefault require-mppe-128 nobsdcomp nodeflate novj lcp-echo-failure 5 lcp-echo-interval 30 plugin /usr/lib/pppd/2.4.4/nm-pptp-pppd-plugin.so

HARDY 32bit
root 7060 1 0 21:45 ? 00:00:00 /usr/sbin/pppd pty /usr/sbin/pptp a.b.c.d --nolaunchpppd remotename a.b.c.d ipparam NetworkManager usepeerdns require-mppe-128 nodeflate nobsdcomp lock noauth mtu 1416 mru 1416 lcp-echo-failure 10 lcp-echo-interval 10 plugin nm-pppd-plugin.so

Revision history for this message
Mozg (andrei-arhont) wrote :

I've installed the PPA version of network manager and I still don't have
the option to control the required options. I can't see a way to disable
the use of remote (VPN) DNS and ability to disable the use of default
gateway through the VPN.

Where are these options located?

Andrei

Alexander Sack wrote:
> for pptp both should work now again ... we properly merge in the advance
> ip4settings for the ppp connection there. Try the latest PPA packages
> please (http://launchpad.net/~network-manager/+archive).
>
>

Revision history for this message
John (john-navarro) wrote :

Andrei,

I saw somewhere that the system will only use the first three DNS entries even if more are defined. So why don't you try manually setting 3 dns entries in your VPN configuration. And also check the option to ignore the provider settings. Just an idea.

John

Revision history for this message
Brian Kennelly (bkennelly+ubuntu) wrote :

Mozg,

Both of those options are present, but they are not obvious.
As we have been discussing, if you create a specific route definition, it implies "nodefaultroute".
The second is implemented by the "Method" pull-down. If you choose "Automatic (VPN) addresses only", it will not pick up the DNS entries from the VPN.

(Only the names have been changed to confuse the innocent.)

On 02/11/08 16:25, Mozg wrote:
> A must have options for me are:
>
> 1. Ability not to use VPN as default route to the internet
> 2. Ability not to use VPN given DNS settings
>
>
> Andrei
>
> Alexander Sack wrote:
>
>> could you add a summary which essential options are missing to the bug
>> description please?
>>
>> ** Changed in: network-manager-pptp (Ubuntu)
>> Status: Confirmed => Incomplete
>>
>>
>>
>
>

Revision history for this message
Alexander Sack (asac) wrote :

i am still missing an explicit list of options that are missing here (please dont post broken things or bugs as a missing option). Please provide them. Otherwise there is not much i can do ;).

Revision history for this message
ngc2997 (ngc2997-deactivatedaccount) wrote :

Well, as to summarize the essential missing options from this thread:

- UI to set a custom MTU and
- UI to disable the use of VPN DNS servers.

As mentioned in comment 6, disabling the default gateway would not explicitly be needed as this can be achieved by entering specific routes.

Revision history for this message
Brian Kennelly (bkennelly+ubuntu) wrote :

As I mentioned above, we can already disable the VPN DNS servers, by choosing the 'addresses only' method.
That leaves the MTU setting and the debug option.

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Yes, I agree with Brian, MTU settting and debug option, please.

Revision history for this message
Thorsten Kunz (sfire) wrote :

I also agree that MTU and debug options are badly needed. It is also a regression form version 0.6.5 in Hardy since both options where available there.

Revision history for this message
Cirroz (pomozoff-gmail) wrote :

I have dynamic IP-addresses from PPTP-server, even when I choose 'manual' for IPv4 settings and enter IP-address by hands.
How can I set gateway for manual route?

And another one, I can setup it connection from windows xp, it works and it sets correct route table, but nm-0.7 gets wrong 'Destination' and writes it to route table:

this is a route table from windows (on work):

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 19 d1 57 da f9 ...... Intel(R) 82566DC Gigabit Network Connection - Packet Scheduler Miniport
0x80004 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
     93.88.16.132 255.255.255.255 10.1.0.3 10.1.1.86 20
   192.168.18.255 255.255.255.255 192.168.18.102 192.168.18.102 50
   192.168.18.102 255.255.255.255 127.0.0.1 127.0.0.1 50
 192.168.18.0 255.255.255.0 192.168.18.102 192.168.18.102 1
        224.0.0.0 240.0.0.0 192.168.18.102 192.168.18.102 50
  255.255.255.255 255.255.255.255 192.168.18.102 192.168.18.102 1

>ipconfig /all (some unusual fileds skipped)

Ethernet adapter Local Area Connection:
        Physical Address. . . . . . . . . : 00-19-D1-57-DA-F9
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 10.1.1.86
        Subnet Mask . . . . . . . . . . . : 255.255.248.0
        Default Gateway . . . . . . . . . : 10.1.0.3
        DHCP Server . . . . . . . . . . . : 10.1.0.242
        DNS Servers . . . . . . . . . . . : 10.1.0.3

PPP adapter ESS:
        Connection-specific DNS Suffix . :
        Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
        Physical Address. . . . . . . . . : 00-53-45-00-00-00
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.18.102
        Subnet Mask . . . . . . . . . . . : 255.255.255.255
        Default Gateway . . . . . . . . . :

---------------------------------

and it's from nm-0.7 (home):

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.18.110 192.168.1.1 255.255.255.255 UGH 0 0 0 eth0
93.88.16.132 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 1 0 0 eth0
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0

anton@desktop:~$ ifconfig ppp0
ppp0 Link encap:Протокол PPP (Point-to-Point Protocol)
          inet addr:192.168.18.105 P-t-P:192.168.18.105 Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1396 Metric:1

---------------------------------

93.88.16.132 - pptp-server

Revision history for this message
Bill Loucks (biloucks) wrote :

@Mr. Sack: You wrote "i am still missing an explicit list of options that are missing here". That list can be created by comparing 0.6.5 to 0.7 and enumerating all options which appear in 0.6.5 but do not appear in 0.7. Below is a list of all of the options in 0.6.5's Dialog window labeled "Edit VPN Connection".

network-manager-pptp 0.6.5 (in Hardy)
Textual description of the Dialog window labeled "Edit VPN Connection", a multi-tabbed dialog:

Tab labeled "Connection"
  Free-form text entry labeled "Connection Name"
  Checkbox: "Requires existing network connection"
  Drop-down list with only one entry: "Windows VPN (PPTP)"
  Free-form text entry labeled "Gateway"
Tab labeled "Authentication"
  Checkbox: "Authenticate Peer"
  Checkbox: "Refuse EAP"
  Checkbox: "Refuse CHAP"
  Checkbox: "Refuse MS CHAP"
Tab labeled "Compression & Encryption"
  Group labeled "Compression"
    Checkbox: "Require MPPC Compression"
    Checkbox: "Allow Deflate compression"
    Checkbox: "Allow BSD Compression"
  Group labeled "Encryption"
    Checkbox: "Require MPPE encryption"
    Checkbox: "Require 128 bit MPPE encryption"
    Checkbox: "Enable stateful MPPE"
Tab labeled "PPP Options"
  Free-form text entry labeled "Custom PPP options"
  Group labeled "IP Options"
    Checkbox: "Use Peer DNS"
    Checkbox: "Require explicit IP Addr"
    Checkbox: "Exclusive device access (UUCP-style lock)"
    Checkbox: "Debug output"
  Group labeled "Packet Parameters"
    Drop-down list with up/down arrows AND free-form text entry labeled "MTU"
    Drop-down list with up/down arrows AND free-form text entry labeled "MRU"
  Group labeled "Delays and TImeouts"
    Drop-down list with up/down arrows AND free-form text entry labeled "connect-delay"
    Drop-down list with up/down arrows AND free-form text entry labeled "lcp-echo-failure"
    Drop-down list with up/down arrows AND free-form text entry labeled "lcp-echo-interval"
Tab labeled "Routing"
  Checkbox: "Peer DNS through tunnel"
  Checkbox: "Only use VPN connections for these addresses"
    Free-form text entry below which is the text, "example: 172.16.0.0/16 10.11.12.0/24"

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

I'd be interesting in knowing what, if anything, is planned regarding this bug? For me intrepid solves many niggling problems I had in Hardy, but the new network manager is the one and only step backwards.

Revision history for this message
Bill Loucks (biloucks) wrote :

I'm not very familiar with the "nomination" process, but I think we may need a few thousand more nominations of this bug for Ubuntu distributions (notice, above, I've nominated this bug for Intrepid and Jaunty). Would any of the other subscribers to this bug be willing to add your nomination(s)? We need MORE of them!

In my opinion, the status of this bug needs to be changed to "Confirmed", and the importance set higher than "Undecided".

Regarding 0.7, I'm gradually learning more about it. I think it adds Wireless Broadband and DSL capabilities, so if you REQUIRE those capabilities, 0.7 is your choice, although 0.7 seems to be a rather early work-in-progress, so expect a rocky road for awhile.

The thing that concerns me is that the pptp plugin for 0.7 is barely recognizable from 0.6 and has several show-stoppers, depending on who you are; for me, the show-stoppers were the inability to set refuse-eap (now fixed) and setting custom routing.

Revision history for this message
Bill Loucks (biloucks) wrote :

Due to this and many other bugs in NM 0.7, it seems that we have Regression Potential here, but that would be a problem for those who require 0.7 because they require some of the new features such as Wireless Broadband and DSL. I'm stumped, because it just seems that we've moved ahead to 0.7 and can't regress without hurting the people using/requiring the new features and device types in 0.7. @ JazzyPenguin: take a look at
http://www2.nau.edu/wal2/NetworkManager/Readme.txt

Revision history for this message
Alexander Sack (asac) wrote :

William, thanks for telling me how to compare the options. since you already do that why couldnt you simply extract that infomration for me?

Bill Loucks (biloucks)
Changed in network-manager-pptp:
status: Incomplete → Confirmed
Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Alexander, I thought William did a very good job of providing an extremely comprehensive list as you asked. With the information provided in this bug report thus far can this issue move forward? The general consensus seems to be that the new functionality in 0.7 (i.e. Mobile Broadband and DSL) is laudable and welcome (I haven't used them yet but will experiment with the Mobile Broadband at some point). However, the regression in PPTP VPN configuration is a serious problem to many of us that rely on PPTP VPN connectivity for work or study.

Revision history for this message
Alexander Sack (asac) wrote :

Problem is that i ask for an explicit list of options and you post the list of options that existed in 0.6 ... not helpful, really. I can do the same by going through code.
Ionly have a certain amount of time ... providing me with perfect information would have made this bug at least move forward long ago.

Revision history for this message
Alexander Sack (asac) wrote :

that said: I will surely look at it and find the missing options - at some point. Its just that if you dont provide what i ask for it takes a while.

Revision history for this message
ngc2997 (ngc2997-deactivatedaccount) wrote :

IIRC the most desperately needed options have already been identified - mtu setting and debug, that was..

Alexander Sack (asac)
Changed in network-manager-pptp:
importance: Undecided → Wishlist
status: Confirmed → Triaged
Revision history for this message
Thorsten Kunz (sfire) wrote :

People have identified the two most direly needed options many times now. But well, if you need to get spelled out how this looks on the command line here we go. Both options are pppd, no pptp options so they need to be passed accordingly.

- MTU
  configuration: just a numerical field. If it is empty don't set it. Maybe a default of 1416 would be resonable as it was the default for in previous NM versions.
  cmd parameter: mtu <value>

- debug
  configuration: a boolean field. Default should be false.
  cmd parameter: debug

And now it would be nice to see this get implemented asap because quite honestly it is a dealbreaker for Ubuntu. I can't ask non tech staff to go to cli every time they want to connect to the VPN - and since Ubuntu aims at non tech people I think this should get some higher priority then "whishlist" (also because this clearly is a regression).

Thanks

Revision history for this message
JazzyPenguin (jazzy-clarinet) wrote :

Thorsten, utterly agree with you. This is a hugh issue for those of us that use PPTP VPN - total dealbreaker!!!!!

Revision history for this message
jon (jonathan-albrecht) wrote :

This is a deal breaker for me as well. I had vpn working in Hardy but the upgrade to Intrepid lost my settings. I need the debug info to figure out what is wrong.

Changed in network-manager:
status: Unknown → Confirmed
Changed in network-manager:
status: Confirmed → Fix Released
Revision history for this message
bivanbi (balazs-lengyak) wrote :

The bug still exists in 9.04 with latest updates afaik.

Revision history for this message
Michael Kofler (michael-kofler) wrote :

the bug still exists in 10.10 alpha

Changed in network-manager:
importance: Unknown → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.