Re: Strange VPN problems
--On Sunday, November 09, 2008 23:42:07 -0500 Dan Williams [EMAIL PROTECTED] wrote: ¦ On Fri, 2008-11-07 at 11:27 +, Rick Jones wrote: ¦ ¦ Is it possible to use that dialog to define a route via a dynamic ¦ address? E.g. to set a default route via the MB provider, or the WiFi ¦ hotspot hub, where the address is unknown prior to connection? ¦ ¦ Not at this time; though you can use dispatcher scripts to do this on a ¦ per-connection basis using the connection's UUID if you like. I assume ¦ you mean some special notation where NM would substitute the device's ¦ current gateway or something like that? Just been chewing this over a bit - I think you'd need a couple of substitute codes, one for the current gateway on the main connection, and one for the gateway on the VPN. E.g. you might want to define specific route(s) over the VPN leaving the default on the main connection, or you might want to do it the other way round. Cheers, Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
On Fri, 2008-11-07 at 11:27 +, Rick Jones wrote: --On Thursday, November 06, 2008 16:38:48 -0500 Dan Williams [EMAIL PROTECTED] wrote: ¦ It would be nice to be able to set a policy of which addresses go via ¦ the VPN, but it's not critical so long as this routing fix is made. ¦ ¦ You do this from the Routes dialog in the IPv4 tab of the connection ¦ editor Is it possible to use that dialog to define a route via a dynamic address? E.g. to set a default route via the MB provider, or the WiFi hotspot hub, where the address is unknown prior to connection? Not at this time; though you can use dispatcher scripts to do this on a per-connection basis using the connection's UUID if you like. I assume you mean some special notation where NM would substitute the device's current gateway or something like that? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
--On Thursday, November 06, 2008 16:38:48 -0500 Dan Williams [EMAIL PROTECTED] wrote: ¦ It would be nice to be able to set a policy of which addresses go via ¦ the VPN, but it's not critical so long as this routing fix is made. ¦ ¦ You do this from the Routes dialog in the IPv4 tab of the connection ¦ editor Is it possible to use that dialog to define a route via a dynamic address? E.g. to set a default route via the MB provider, or the WiFi hotspot hub, where the address is unknown prior to connection? Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
--On 06 November 2008 06:42 -0500 Dan Williams [EMAIL PROTECTED] wrote: ¦ ¦ Is 192.168.7.128 the address of the VPN server? Yes ¦ NM clearly doesn't insert a route to the VPN server (192.168.7.128). ¦ ¦ But it should; if it doesn't there's a bug. There's currently a bug ¦ where, upon DHCP renewal, NM will flush that host route to the VPN ¦ gateway. I'm trying to fix that right now. Sounds like it could be the problem. The VPN server is also the DHCP server, and I guess the client renews the lease on each connection. ¦ ¦ It has also zapped the default route. Has this been fixed in a later ¦ build? ¦ ¦ If there are any custom routes sent by the VPN server (pptp doesn't have ¦ this capability) or entered by you in the IP4 Routes dialog, NM assumes ¦ that you do not want the VPN to be the default connection (if it was, ¦ any custom routes would be completely redundant). I don't think that's ¦ the case here, your issue looks like a bug. AFAIK the server is not doing anything fancy with routes. Prior to establishing the VPN, the default route is to the MB host address: 0.0.0.0 10.36.193.0 0.0.0.0 UG0 00 ppp0 When the VPN is up, this entry has gone, replaced by something that looks to me like a meaningless route: 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp1 Standard pptp leaves the default route alone, as it should. ¦ Any idea what SVN revision your NM is based on? The package id on ppa.launchpad.net is 0.7~~svn20081018t105859-0ubuntu2-nm2-hardy1. I guess that's from SVN dated 2008/10/18, the other numbers don't mean anything to me. I've can confirm that routing is the sole cause of the problem - if I make the VPN connection in NM, then immediately enter the missing routes manually, it all works and stays connected, echo packets function, etc. -- Cheers Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
On Thu, 2008-11-06 at 12:09 +, Rick Jones wrote: --On 06 November 2008 06:42 -0500 Dan Williams [EMAIL PROTECTED] wrote: ¦ ¦ Is 192.168.7.128 the address of the VPN server? Yes ¦ NM clearly doesn't insert a route to the VPN server (192.168.7.128). ¦ ¦ But it should; if it doesn't there's a bug. There's currently a bug ¦ where, upon DHCP renewal, NM will flush that host route to the VPN ¦ gateway. I'm trying to fix that right now. Sounds like it could be the problem. The VPN server is also the DHCP server, and I guess the client renews the lease on each connection. ¦ ¦ It has also zapped the default route. Has this been fixed in later ¦ build? ¦ ¦ If there are any custom routes sent by the VPN server (pptp doesn't have ¦ this capability) or entered by you in the IP4 Routes dialog, NM assumes ¦ that you do not want the VPN to be the default connection (if it was, ¦ any custom routes would be completely redundant). I don't think that's ¦ the case here, your issue looks like a bug. AFAIK the server is not doing anything fancy with routes. Prior to establishing the VPN, the default route is to the MB host address: 0.0.0.0 10.36.193.0 0.0.0.0 UG0 0 0 ppp0 mobile broadband I assume? When the VPN is up, this entry has gone, replaced by something that looks to me like a meaningless route: 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp1 No, this is a default route through the VPN, which is expected, since there aren't any custom routes either sent by the VPN server or added by you. If there are no custom routes, everything will be sent through the VPN because you have not told NetworkManager what specific routes to use the VPN for. Standard pptp leaves the default route alone, as it should. Maybe, maybe not :) It depends on policy. Dan ¦ Any idea what SVN revision your NM is based on? The package id on ppa.launchpad.net is 0.7~~svn20081018t105859-0ubuntu2-nm2-hardy1. I guess that's from SVN dated 2008/10/18, the other numbers don't mean anything to me. I've can confirm that routing is the sole cause of the problem - if I make the VPN connection in NM, then immediately enter the missing routes manually, it all works and stays connected, echo packets function, etc. -- Cheers Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
--On Thursday, November 06, 2008 07:33:07 -0500 Dan Williams [EMAIL PROTECTED] wrote: ¦ mobile broadband I assume? Yes, my main use for VPN is over MB. ¦ When the VPN is up, this entry has gone, replaced by something that ¦ looks to me like a meaningless route: ¦ ¦ 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp1 ¦ ¦ No, this is a default route through the VPN, which is expected, since ¦ there aren't any custom routes either sent by the VPN server or added by ¦ you. If there are no custom routes, everything will be sent through the ¦ VPN because you have not told NetworkManager what specific routes to use ¦ the VPN for. ¦ ¦ Standard pptp leaves the default route alone, as it should. ¦ ¦ Maybe, maybe not :) It depends on policy. I take your point. In fact for my purpose I should really have a gateway route just to 192.168.7.* via the VPN server. Can this kind of routing policy be configured in NM? However, there's still a strange problem with these routes. If the default route to the MB gateway on ppp0 is not present, then nothing will go over the VPN on ppp1, not even the echo packets. Successful echo depends _only_ on the existence of this route. Other communication over the VPN depends on both this _and_ an explicit route to the VPN server on ppp1. I've tried all kinds of route permutations, and it won't work if the original MB default route is not there. It doesn't seem to make a lot of sense, but that's what's happening. Maybe you can figure it out? -- Cheers Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
--On Thursday, November 06, 2008 16:49:29 + Rick Jones [EMAIL PROTECTED] wrote: ¦ I take your point. In fact for my purpose I should really have a gateway route just to 192.168.7.* via the VPN server. Can this kind of routing policy be configured in NM? ¦ ¦ However, there's still a strange problem with these routes. If the default route to the MB gateway on ppp0 is not present, then nothing will go over the VPN on ppp1, not even the echo packets. Successful echo depends _only_ on the existence of this route. Other communication over the VPN depends on both this _and_ an explicit route to the VPN server on ppp1. ¦ ¦ I've tried all kinds of route permutations, and it won't work if the original MB default route is not there. It doesn't seem to make a lot of sense, but that's what's happening. Maybe you can figure it out? Cracked it! There must be at minimum a gateway route to the VPN host via ppp0, since pptp is using that to carry the VPN packets. By adding just that route, everything then works. The routing table ends up as: 82.153.174.82 10.44.200.0 255.255.255.255 UGH 0 00 ppp0 10.44.200.0 0.0.0.0 255.255.255.255 UH0 00 ppp0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp1 The first line is the route I manually added. 82.153.174.82 is the public address of my server, 10.44.200.0 is the MB gateway for the current session. If the original default route via the MB gateway is removed, then it must be replaced by this. It would be nice to be able to set a policy of which addresses go via the VPN, but it's not critical so long as this routing fix is made. (I'm sending this email logged into my IMAP server via VPN over MB, just to prove to myself it can be done!) -- Cheers Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
On Thu, 2008-11-06 at 18:24 +, Rick Jones wrote: --On Thursday, November 06, 2008 16:49:29 + Rick Jones [EMAIL PROTECTED] wrote: ¦ I take your point. In fact for my purpose I should really have a gateway route just to 192.168.7.* via the VPN server. Can this kind of routing policy be configured in NM? ¦ ¦ However, there's still a strange problem with these routes. If the default route to the MB gateway on ppp0 is not present, then nothing will go over the VPN on ppp1, not even the echo packets. Successful echo depends _only_ on the existence of this route. Other communication over the VPN depends on both this _and_ an explicit route to the VPN server on ppp1. ¦ ¦ I've tried all kinds of route permutations, and it won't work if the original MB default route is not there. It doesn't seem to make a lot of sense, but that's what's happening. Maybe you can figure it out? Cracked it! There must be at minimum a gateway route to the VPN host via ppp0, since pptp is using that to carry the VPN packets. By adding just that route, everything then works. The routing table ends up as: 82.153.174.82 10.44.200.0 255.255.255.255 UGH 0 00 ppp0 10.44.200.0 0.0.0.0 255.255.255.255 UH0 00 ppp0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp1 The first line is the route I manually added. 82.153.174.82 is the public address of my server, 10.44.200.0 is the MB gateway for the current session. If the original default route via the MB gateway is removed, then it must be replaced by this. This is how it should already work with recent VPN and PPTP fixes; I fixed a few PPTP things the other day. If it doesn't do this with latest SVN then it's a bug. It would be nice to be able to set a policy of which addresses go via the VPN, but it's not critical so long as this routing fix is made. You do this from the Routes dialog in the IPv4 tab of the connection editor Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Strange VPN problems
I've never been able to get NM to make a successful VPN connection, and I finally have some meaningful (I hope) logs etc. I can get a working connection using pppd with pptp on the command line, but not using NM. It seems that the NM plugin sets up the connection slightly differently. This command line works (executed as root): /usr/sbin/pppd pty '/usr/sbin/pptp server.my.domain --nolaunchpppd' nodetach lock usepeerdns noipdefault refuse-pap refuse-chap refuse-mschap require-mppe nobsdcomp nodeflate name rick (auth is handled by chap-secrets in normal way) The server is another Linux box, so the connection is served by pppd + pptp on the remote end as well. In particular the server log shows the server responding to client PPTP echo requests at 1 minute intervals: pptpd[2289]: CTRL: Received PPTP Control Message (type: 5) pptpd[2289]: CTRL: Made a ECHO RPLY packet pptpd[2289]: CTRL: I wrote 20 bytes to the client. pptpd[2289]: CTRL: Sent packet to client ... etc When I create the connection with NM, no PPTP echo messages are received, instead the server attempts to send the echoes, but gets no response. This kind of thing appears after about 2 minutes: pptpd[31784]: CTRL: Sending ECHO REQ id 1 pptpd[31784]: CTRL: Made a ECHO REQ packet pptpd[31784]: CTRL: I wrote 16 bytes to the client. pptpd[31784]: CTRL: Sent packet to client pptpd[31784]: CTRL: EOF or bad error reading ctrl packet length. pptpd[31784]: CTRL: couldn't read packet header (exit) pptpd[31784]: CTRL: CTRL read failed pptpd[31784]: CTRL: Client 89.193.143.54 control connection finished pptpd[31784]: CTRL: Exiting now - connection gone. (Note this is not LCP echo - that's disabled already) NM appears to be setting up the connection differently, in a way that doesn't work - what's the difference? Is there anything I can do server-side to make it more friendly? I'm running the current PPA build of NM on Ubuntu Hardy 8.0.4. Has anything changed in this area in rc1? -- Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Strange VPN problems
On Wed, 2008-11-05 at 17:31 +, Rick Jones wrote: I've never been able to get NM to make a successful VPN connection, and I finally have some meaningful (I hope) logs etc. I can get a working connection using pppd with pptp on the command line, but not using NM. It seems that the NM plugin sets up the connection slightly differently. This command line works (executed as root): /usr/sbin/pppd pty '/usr/sbin/pptp server.my.domain --nolaunchpppd' nodetach lock usepeerdns noipdefault refuse-pap refuse-chap refuse-mschap require-mppe nobsdcomp nodeflate name rick (auth is handled by chap-secrets in normal way) The server is another Linux box, so the connection is served by pppd + pptp on the remote end as well. In particular the server log shows the server responding to client PPTP echo requests at 1 minute intervals: pptpd[2289]: CTRL: Received PPTP Control Message (type: 5) pptpd[2289]: CTRL: Made a ECHO RPLY packet pptpd[2289]: CTRL: I wrote 20 bytes to the client. pptpd[2289]: CTRL: Sent packet to client ... etc When I create the connection with NM, no PPTP echo messages are received, instead the server attempts to send the echoes, but gets no response. This kind of thing appears after about 2 minutes: pptpd[31784]: CTRL: Sending ECHO REQ id 1 pptpd[31784]: CTRL: Made a ECHO REQ packet pptpd[31784]: CTRL: I wrote 16 bytes to the client. pptpd[31784]: CTRL: Sent packet to client pptpd[31784]: CTRL: EOF or bad error reading ctrl packet length. pptpd[31784]: CTRL: couldn't read packet header (exit) pptpd[31784]: CTRL: CTRL read failed pptpd[31784]: CTRL: Client 89.193.143.54 control connection finished pptpd[31784]: CTRL: Exiting now What does the routing table look like immediately after you connect, and then right before the 2-minute disconnection? 'route -n' format please. Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
