PPTP for PPPoE client fails

Hmmm, no takers. Is this too esoteric then?

Anyway, this is a log from an attempted connection:


Jan 28 22:33:36 astaro pptpd[15962]: GRE: Discarding duplicate packet
Jan 28 22:33:38 astaro pptpd[15962]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
Jan 28 22:33:38 astaro pppd[15963]: No CHAP secret found for authenticating  on pptp, trying aua with MS-CHAP
Jan 28 22:33:40 astaro aua[15982]: U: F[:P]ptp R[:$]K C::*
Jan 28 22:33:40 astaro pppd[15963]: In secrets file: unrecognized option 'NO_AUA_OPTS_YET'
Jan 28 22:33:40 astaro pppd[15963]: MSCHAP-v2 peer authentication succeeded for 
Jan 28 22:33:40 astaro pppd[15963]: MPPE 128 bit, stateless compression enabled
Jan 28 22:33:40 astaro pppd[15963]: Cannot determine ethernet address for proxy ARP
Jan 28 22:33:40 astaro pppd[15963]: local  IP address 192.168.10.1
Jan 28 22:33:40 astaro pppd[15963]: remote IP address 192.168.10.3
Jan 28 22:33:46 astaro pptpd[15962]: GRE: read(fd=6,buffer=8055c40,len=8260) from network failed: status = -1 error = Message too long
Jan 28 22:33:46 astaro pptpd[15962]: CTRL: GRE-tunnel has collapsed (GRE read or PTY write failed (gre,pty)=(6,5))
Jan 28 22:33:46 astaro pptpd[15962]: CTRL: Closing child ppp with pid 15963
Jan 28 22:33:46 astaro pptpd[15962]: CTRL: Client  control connection finished
Jan 28 22:33:46 astaro pppd[15963]: Terminating on signal 2.
Jan 28 22:33:46 astaro pppd[15963]: Modem hangup
Jan 28 22:33:46 astaro pppd[15963]: Connection terminated.
Jan 28 22:33:46 astaro pppd[15963]: Connect time 0.2 minutes.
Jan 28 22:33:46 astaro pppd[15963]: Sent 4866 bytes, received 2595 bytes.
Jan 28 22:33:46 astaro pppd[15963]: Exit. 



Ragnar Wisløff    

I can weigh in a tad, but not necessarily with enough expertise to solve  your problem. . . [:(]

I use PPTP with PPPoE connections quite regularly.  With W2K and XP clients it works seamlessly.  My only problem is when I try to connect using a Windows 98 client, and in those instances it works fine till I try to browse anywhere on the VPN using Internet Explorer.  .  .it invariably terminates the VPN.

To the point of your question; I went into my own Roadwarrior log and where you have the error:

  Cannot determine ethernet address for proxy ARP  

My own log shows the successful   found interface eth0 for proxy arp  

All I can say (and you probably already know this) is that this is the point where my successful connection and your unsuccessful connection diverge.

I do note one other thing, and I don't know if it's relevant or not.  I have my PPTP pool of IP addresses set to a different subnet than that of my VPN, so that the last two lines of my successful connection read:

  2004-Jan  4 10:56:51 (none) pppd[18423]: local  IP address 10.46.x.x
2004-Jan  4 10:56:51 (none) pppd[18423]: remote IP address 192.168.x.x
  

I see by contrast that you have your PPTP assigning IP addresses that are in the same subnet as your LAN.  This may cause trouble, although I can't be certain of it.  You might want to try giving your PPTP pool a different address pool and then setting a packet filter rule allowing addresses from that pool to hit your LAN.  I have observed that even when I set up PPTP to give a user a specific remote address which is the same subnet as my LAN, Roadwarrior logs show that "locally" (that is, local to the ASL box) they have an IP address from the pool.  I'm guessing this is necessary for the routing in ASL to work properly.

HTH,

Dan  

Dan,

Thanks for your advice.  I noted the Proxy ARP message, and checked the Proxy ARP settings for the network interfaces. None of them have Proxy ARP set. Do you have Proxy ARP set up?

  I will change the IP ranges so that the local and remote don't overlap, and see if that helps. However, there are several clients that also use PPTP, but on straight Ethernet connections (also ADSL) that have no problem witht the current setup. 

My eye caught the message in the log that said

 GRE: read(fd=6,buffer=8055c40,len=8260) from network failed: status = -1 error = Message too long   

This is why I thought there might be a problem with the PPPoE encapsulation and PPTP encryption as a combination, it seems that the kernel thinks the packets are somehow malformed. And it is a recurring error with this single client. 

Thanks again for taking the time to respond.


Ragnar Wisløff  

Ragnar,

I just checked in my settings and proxy ARP is off for all my NICs, so I doubt this is the issue.

It does occur to me, however, that we haven't yet talked about the client side.  What OS and client are using, either with the other clients that are working, or this one that isn't?

And just because they do some default set-up that doesn't necessarily present all its details first time you look, why don't you look in your Network Definitions and see if an IP range has already been configured by ASL and named "PPTP_Pool."  Then try using that range for your IPs and see what happens.

Dan  

Ragnar,

I just checked in my settings and proxy ARP is off for all my NICs, so I doubt this is the issue.

It does occur to me, however, that we haven't yet talked about the client side.  What OS and client are using, either with the other clients that are working, or this one that isn't?

And just because they do some default set-up that doesn't necessarily present all its details first time you look, why don't you look in your Network Definitions and see if an IP range has already been configured by ASL and named "PPTP_Pool."  Then try using that range for your IPs and see what happens.

Dan  

When combining PPPoE with PPTP the MTU must be right. Normaly with PPPoE it should be 1492. Check this on your ADSL-Router/Modem and correct, if neccecary.

Best regards

Martin