|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
Re: [PLUG] PPTP Masquerading Problems
|
I've had much better luck with masquerading and filter support in the 2.4
kernel...any chance of being able to upgrade that machine to a 2.4 kernel?
-dwild
On Sat, 7 Apr 2001, Michael F. Robbins wrote:
> Date: Sat, 7 Apr 2001 10:15:20 -0400
> From: Michael F. Robbins <mike@gamerack.com>
> Reply-To: plug@lists.phillylinux.org
> To: plug@lists.phillylinux.org
> Subject: [PLUG] PPTP Masquerading Problems
>
> Hi everyone. Just as an opener: I know how bad PPTP is, especially
> Microsoft PPTP. But this is for a client, and it's his company policy.
>
> I've got a P233 running Red Hat 6.2 as a masquerading box on a cable modem.
> The hosts behind the box can access webpages and everything just fine; I've
> done that stuff before. Now, I need to access an external PPTP server from
> a Windows system behind the Linux box, IP 38.x.x.x. The Linux box's
> external interface is 24.x.x.x, and the internal interface is 10.10.10.5, to
> match with the client's pre-existing IP numbering. The particular system
> that needs to dial out PPTP is 10.10.10.4. And the real problem is that
> when the Windows system was originally plugged into the cable modem
> directly, it got to the PPTP just fine.
>
> Going by the instructions on
> ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html, I tried to
> patch and compile the following kernel versions: 2.2.14, 2.2.16, RedHat's
> 2.2.16-22, 2.2.17, and 2.2.18. I have had no success. With verbose
> debugging, this is what I get:
>
> 08:51:05: ip_masq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:05: ip_masq_pptp_tcp(): 24.x.x.x -> 38.x.x.x LEN=516 TY=1460
> MC=1010402
> 08:51:05: ip_masq_pptp_tcp(): not a control pkt
> 08:51:05: ip_demasq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:05: ip_demasq_pptp_tcp(): 38.x.x.x -> 10.10.10.4 LEN=516 TY=1460
> MC=1010402
> 08:51:05: ip_demasq_pptp_tcp(): not a control pkt
> 08:51:05: ip_masq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:05: ip_masq_pptp_tcp(): no TCP data in pkt
> 08:51:05: ip_masq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:05: ip_masq_pptp_tcp(): 24.x.x.x -> 38.x.x.x LEN=156 TY=1 MC=1A2B3C4D
> CTL=START_SESSION_REQUEST
> 08:51:05: ip_masq_pptp_tcp(): START_SESSION_REQUEST (TY=1)
> 08:51:05: ip_demasq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:05: ip_demasq_pptp_tcp(): 38.x.x.x -> 10.10.10.4 LEN=156 TY=1
> MC=1A2B3C4D CTL=START_SESSION_REPLY
> 08:51:05: ip_demasq_pptp_tcp(): START_SESSION_REPLY (TY=2)
> 08:51:08: ip_demasq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:08: ip_demasq_pptp_tcp(): 38.x.x.x -> 10.10.10.4 LEN=156 TY=1
> MC=1A2B3C4D CTL=START_SESSION_REPLY
> 08:51:08: ip_demasq_pptp_tcp(): START_SESSION_REPLY (TY=2)
> 08:51:15: ip_demasq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:15: ip_demasq_pptp_tcp(): 38.x.x.x -> 10.10.10.4 LEN=156 TY=1
> MC=1A2B3C4D CTL=START_SESSION_REPLY
> 08:51:15: ip_demasq_pptp_tcp(): START_SESSION_REPLY (TY=2)
> 08:51:28: ip_demasq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:28: ip_demasq_pptp_tcp(): 38.x.x.x -> 10.10.10.4 LEN=156 TY=1
> MC=1A2B3C4D CTL=START_SESSION_REPLY
> 08:51:28: ip_demasq_pptp_tcp(): START_SESSION_REPLY (TY=2)
> 08:51:54: ip_demasq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:54: ip_demasq_pptp_tcp(): 38.x.x.x -> 10.10.10.4 LEN=156 TY=1
> MC=1A2B3C4D CTL=START_SESSION_REPLY
> 08:51:54: ip_demasq_pptp_tcp(): START_SESSION_REPLY (TY=2)
> 08:51:54: ip_masq_pptp_tcp(): app_data=c23909c0 CID=0 MCID=0 PCID=0
> 08:51:54: ip_masq_pptp_tcp(): no TCP data in pkt
>
> It sure looks like the traffic goes to the PPTP server, and back to the
> client at least once. It scares me that it says "no TCP data in pkt" and
> "not a control pkt"...that doesn't sound good. Also, is it a problem that
> the Magic Cookie value seems to be changing or something? The MC of
> 1A2B3C4D is built into the linux PPTP module code, IIRC. Also, I don't see
> any GRE traffic here from functions like ip_masq_pptp_gre() or something
> like that. My IPCHAINS config is set up to allow GRE traffic, and MASQ any
> traffic from the internal network.
>
> This is somewhat urgent, as this client can not access his work files
> anymore. Has anyone done this before? Any help is appreciated. SSH access
> to the masq box may be a possibility, if any of you can help.
>
> Please let me know if you have any questions.
>
> Mike Robbins
> mike@gamerack.com
>
>
>
>
> ______________________________________________________________________
> Philadelphia Linux Users Group - http://www.phillylinux.org
> Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
> General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
>
______________________________________________________________________
Philadelphia Linux Users Group - http://www.phillylinux.org
Announcements-http://lists.phillylinux.org/mail/listinfo/plug-announce
General Discussion - http://lists.phillylinux.org/mail/listinfo/plug
|
|