pptp vpn regresses after feisty to gutsy upgrade

[Steve Romanow]

I have been successfully using network manager with a msft vpn at work for 6 or so months. Speed and reliability was consistent and good. After upgrading to Gutsy (gnome, no X or K), the connection works, but is very flaky. It prompts me to reenter my password a lot (even though I choose to save it in my keyring). When it does connect, it is only good for one app. THe seconf app that uses the tunnel will fail.

For example, i start the vpn connection, then ssh to a server at work. It works, and will stay connected for as long as I need it.
5 minutes after starting connection 1, I try to ssh or telnet to another (or the same server), that connection will say connection is refused. 1st conenction does not end, just cannot initiate a second terminal session.

This did not occur with this laptop and network under feisty. Ive looked in /var/log/daemon log, and the following output was noted.

Nov 2 20:49:13 e1505 pptp[7076]: anon log[ctrlp_disp:pptp_ctrl.c:952]: send_accm is 00000000, recv_accm is FFFFFFFF
Nov 2 20:49:13 e1505 pptp[7076]: anon warn[ctrlp_disp:pptp_ctrl.c:955]: Non-zero Async Control Character Maps are not supported!
Nov 2 20:49:14 e1505 pptp[7074]: anon log[decaps_gre:pptp_gre.c:407]: buffering packet 17 (expecting 16, lost or reordered)
Nov 2 20:49:18 e1505 NetworkManager: <info> VPN Activation (COMMERCE) Stage 4 of 4 (IP Config Get) reply received.
Nov 2 20:49:19 e1505 NetworkManager: <info> Clearing nscd hosts cache.
Nov 2 20:49:19 e1505 NetworkManager: <WARN> nm_spawn_process(): nm_spawn_process('/usr/sbin/nscd -i hosts'): could not spawn process. (Failed to execute child process "/usr/sbin/nscd" (No such file or directory))
Nov 2 20:49:19 e1505 NetworkManager: <info> VPN Activation (COMMERCE) Stage 4 of 4 (IP Config Get) complete.
Nov 2 20:49:19 e1505 NetworkManager: <info> VPN Activation (COMMERCE) successful.
Nov 2 20:49:19 e1505 NetworkManager: <info> VPN service 'org.freedesktop.NetworkManager.ppp_starter' signaled state change 3 -> 4.
Nov 2 20:49:19 e1505 NetworkManager: <debug> [1194050959.227911] nm_dbus_signal_filter(): NetworkManagerInfo triggered update of VPN connection 'COMMERCE'
Nov 2 20:49:24 e1505 dhclient: DHCPREQUEST on eth1 to 192.168.0.100 port 67
Nov 2 20:49:24 e1505 dhclient: DHCPACK from 192.168.0.100
Nov 2 20:49:24 e1505 NetworkManager: <info> DHCP daemon state is now 3 (renew)

Note the nscd error and the pid 7074 and 7076 pptp errors. Is nscd needed for proper nm vpn funtionality? Did it work differently in feisty?

[Steve Romanow (slestak989)]

I think the problem has to do with dns.

I turned off option in NM -> Configure VPN -> PPP Options -> Exclusive device access, seemed to be better.

I tried with and without Configure VPN -> Routing -> Peer DNS through tunnel no change

services that try to resolve by dns fail, but by ip work.

telnetting to ip address works on multiple screens
rdp to name fails (used to work in feisty)
ssh fails do to RSA Key change (man in the middle attack), Think that related to getting different ip address from vpn service.

This is close to working.
One other issue is the password is never being save in teh keyring. It prompts me every time for username and password.

[Steve Romanow (slestak989)]

Well, I seem to have it working by name and by ip address now. I dont think any of my changes were necessary, my current config is the same as the original, but it is working now.

Maybe the gconf schema or other config file formatting changed between 7.04 and 7.10 that just took me running through the setup to get it "up to current". No way to know at this point.

The only outstanding issue is the username and password prompting every time, even if I xhoose to save it int he keyring.

[Steve Romanow (slestak989)]

Oh, its still not right, THat 76. ip address was my comcast ip address. Doh!

So still seems to be a dns issue.

Hmmm. when vpn is connected, /etc/resolv.conf contains only the two remote nameservers.

[Mark Stosberg (markstos)]

I believe this bug is not a duplicate. I am not affected by the target bug, but I am by this one. I have to restart my VPN connection on Gutsy, when I did not on Feisty. I notice this when the computer has been idle for some time and I return.

I could check my various settings at home if it would be helpful.

[Steve Romanow (slestak989)]

I think you are correct. This bug may still be irrelevant. I think the problem is /etc/resolv.conf is being overwritten numerous times by NM and others.
I looked at my resolv.conf settings 15-20 seconds after establishing vpn, and they are only remote dns, check back a couple of minutes later and it is only local dns settings.

I hope upstream is aware and understands. I'm about ready to just throw the 10 or so machines that I vpn to into /etc/hosts and call it a day.