Date: Fri, 20 Apr 2007 17:24:48 -0400 From: Tom McLaughlin <tmclaugh@sdf.lonestar.org> To: Alexander Motin <mav@mavhome.dp.ua> Cc: freebsd-net@freebsd.org, Nikos Vassiliadis <nvass@teledomenet.gr> Subject: Re: net/mpd4: Unable to pass pass traffic as pptp client Message-ID: <1177104288.2950.14.camel@localhost> In-Reply-To: <4628A8B3.2090900@mavhome.dp.ua> References: <1176776612.00725618.1176764402@10.7.7.3> <1176816181.00725799.1176802803@10.7.7.3> <4628A8B3.2090900@mavhome.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2007-04-20 at 14:49 +0300, Alexander Motin wrote: > 232487741 > Nikos Vassiliadis wrote: > >>pptp0: connecting to 208.206.3.5 1723 > >>[vpn] IPCP: LayerUp > >> 172.30.29.9 -> 208.206.3.5 > > > >>ifconfig > >>[root@bofh tom]# ifconfig ng0 > >>ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1396 > >> inet 172.30.29.9 --> 208.206.3.5 netmask 0xffffffff > > > > It seems that your external peer address is the same with the internal > > peer address. You connect to pptp-server-ip through your linksys and > > then say that pptp-server-ip is reachable through the tunnel. So it > > routes everything destined for pptp-server-ip through the tunnel. I > > think that such configuration is valid for other operating systems. > > I don't know if you can work-around the problem on your own, maybe > > you have to contact the VPN concentrator's admin. Perhaps you can > > modify the routing table (the external peer address should be reachable > > as it was, though linksys) and invent some peer address using > > "ifconfig ng0 your_address 10.0.0.1 netmask 0xffffffff". > > But it's not nice... > > > > Can you convice the concentrator's administrator to use another > > address for his internal side? > > It would be a better way. But if it is not possible you could use 'ipfw > fwd' rule to forward all PPTP's GRE and controling TCP packets via > physical interface instead of tunnel. > I found some doc after googling and I followed the instructions here: http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn/fbsd-cisco-vpn.pdf That's gotten me closer. I created an iface up-script to fix the routes after connecting. [root@bofh tom]# netstat -r -f inet Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default linksys UGS 0 81879 em0 localhost localhost UH 0 96 lo0 172.30 172.30.16.14 UGS 0 2 ng0 172.30.16.14 172.30.29.64 UH 1 2 ng0 172.30.29.64/32 lo0 US 0 0 lo0 192.168.1 link#2 UC 0 0 em0 linksys 00:06:25:dc:a0:f1 UHLW 2 0 em0 884 shorthair 00:09:5b:0b:78:e2 UHLW 1 9169 em0 720 COMPASS 00:11:d8:f9:70:aa UHLW 1 26909 em0 1039 192.168.1.255 ff:ff:ff:ff:ff:ff UHLWb 1 341 em0 [root@bofh tom]# ifconfig ng0 ng0: flags=88d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST> mtu 1396 inet 172.30.29.64 --> 172.30.16.14 netmask 0xffffffff I tried pinging while sniffing ng0 and em0 and I see the ping traveling through ng0 and then a PPP compressed data packet out em0. I end up receiving back a PPP LCP protocol reject from the concentrator back to em0 and the following message from mpd4 [vpn] LCP: rec'd Protocol Reject #2 link 0 (Opened) [vpn] LCP: protocol 0xee0b was rejected One bit of advice I received was turning off encryption but this is not an option for me. This same issue appears to have been around since mpd3. tom -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | | BSD# http://www.mono-project.com/Mono:FreeBSD |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1177104288.2950.14.camel>