Re: net/mpd4: Unable to pass pass traffic as pptp client
- From: Tom McLaughlin <tmclaugh@xxxxxxxxxxxxxxxx>
- Date: Fri, 20 Apr 2007 17:24:48 -0400
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 |
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"
- References:
- Re: net/mpd4: Unable to pass pass traffic as pptp client
- From: Alexander Motin
- Re: net/mpd4: Unable to pass pass traffic as pptp client
- Prev by Date: Network interface failover in 6.2?
- Next by Date: Re: rtentry and rtrequest
- Previous by thread: Re: net/mpd4: Unable to pass pass traffic as pptp client
- Next by thread: Re: net/mpd4: Unable to pass pass traffic as pptp client
- Index(es):