net/mpd4: Unable to pass pass traffic as pptp client

[Tom McLaughlin]

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 at 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 at 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 at 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 |