*** Bug 12990 has been marked as a duplicate of this bug. ***

The patch I previously sent doesn't work quite right.  I'll work on fixing it 
and resubmit as an attachment to this bug.

ip_masq_pptp.o included in kernel 2.2.16-8 on Winston Beta 3.  Thanks!

The patch compiles cleanly, but there is still an error in it that prevents it 
from working.

From: Domsch, Matt
Sent: Sunday, July 09, 2000 1:19 PM
To: 'jhardin'
Subject: FW: ip_masq_pptp error

John,

Thanks for providing the ip_masq_vpn patch to the Linux kernel.  I really 
appreciate having it.  However, I'm having a problem since upgrading to the 
2.2.16-x kernel, where x={1, 3, 8}, available on Red Hat's rawhide tree.  The 
connection is established properly, but then passing of information across that 
connection (such as password verification, etc) fails in the ip_masq_gre() 
function (or something that calls it).  

Jul  9 07:51:40 cs9359-99 kernel: ip_masq_pptp_tcp(): OUT_CALL_REQUEST 
192.168.0.2 -> 143.166.82.50 CID=0 MCID=EE49 
Jul  9 07:51:40 cs9359-99 kernel: ip_demasq_pptp_tcp(): OUT_CALL_REPLY 
192.168.0.2 -> 143.166.82.50 CID=0 MCID=EE49 
Jul  9 07:51:40 cs9359-99 kernel: ip_masq_gre(): change maddr from 24.93.59.99 
to 0.0.0.0 

Red Hat modified the patch you provided for the 2.2.15/16 kernel to properly 
build into Red Hat's source RPM.  The changes were minor, mostly due to the 
ipvs patch that Red Hat provides.  I'm attaching the modified patch below.  
Basically, the CREDITS, ip_masq.h, and ip_masq.c files needed minor tweaks.

Your patch (against 2.2.14) worked as recently as 2.2.14-100.

Any help you can provide would be greatly appreciated.  I'm encouraging Red Hat 
to include this patch as part of their standard kernel going forward, as we 
lots of requests for it.

Removing the ipvs patch from 2.2.16-8, and using the stock ip_masq_vpn-2.2.15 
patch from the above site, it works just fine.  So, the conflict is somewhere 
between the ipvs and ip_masq_vpn patches.

ipvs takes precedence here.

From: John D. Hardin [jhardin]
Sent: Wednesday, July 19, 2000 9:27 AM
To: Matt_Domsch.com
Cc: dledford
Subject: RE: FW: ip_masq_pptp error

On Tue, 18 Jul 2000 Matt_Domsch wrote:

> John, any luck looking into this?

I just had a report that it all works properly:

> From erosander Wed Jul 19 07:20:24 2000
> Date: Tue, 18 Jul 2000 23:59:10 -0700
> From: Eric Rosander <erosander>
> To: John D. Hardin <jhardin>
> Subject: RE: Quick question
> 
> OK, I'm home now.  Below are the results of my masqueraded
> SecuRemote session.  I went ahead and compiled it with the debug
> verbose options.
> 
> Looks like IKE and PPTP in/out are working AOK.
> 
> # uname -r
> 2.2.16-8
> 
> (public addresses changed to protect the mostly innocent)
> ---
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): O-routed from my.fw.public.addr
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): 10.10.222.10 ->
> the.fw1v41.vpn.gateway SPI B
> 3282B3B (fakeport 2B3B)
> Jul 18 23:34:27 lurch kernel: ip_masq_out_get_esp(): lookup
> 0ADE0A0A:3B2B28B3->0
> 2A069CF OK
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): O-routed from my.fw.public.addr
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): 10.10.222.10 ->
> the.fw1v41.vpn.gateway SPI B
> 3282B3B (fakeport 2B3B)
> Jul 18 23:34:27 lurch kernel: ip_masq_out_get_esp(): lookup
> 0ADE0A0A:3B2B28B3->0
> 2A069CF OK
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): O-routed from my.fw.public.addr
> Jul 18 23:34:27 lurch kernel: ip_demasq_esp(): the.fw1v41.vpn.gateway ->
> my.fw.public.addr S
> PI EDDB2409 (fakeport 2409)
> Jul 18 23:34:27 lurch kernel: ip_masq_in_get_esp(): lookup
> 02A069CF->4D7EE9D1:09
> 24DBED OK
> Jul 18 23:34:27 lurch kernel: ip_demasq_esp(): I-routed to 10.10.222.10
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): 10.10.222.10 ->
> the.fw1v41.vpn.gateway SPI B
> 3282B3B (fakeport 2B3B)
> Jul 18 23:34:27 lurch kernel: ip_masq_out_get_esp(): lookup
> 0ADE0A0A:3B2B28B3->0
> 2A069CF OK
> Jul 18 23:34:27 lurch kernel: ip_masq_esp(): O-routed from my.fw.public.addr
> 
> ---hopefully enough log?

Note that the part of the ip_masq.c patch that conflicts with the
other patches in the Redhat kernel RPMS is used by both the IPsec and
PPTP masquerade code.

I will take a look at things today, I hope...

It's possible that the problem only manifests itself in situations
where the packets should be discarded, which are not too frequently
seen.

This patch fixes it.  Please apply AFTER the ipvs and ip_masq_vpn patches.  It 
fixes a thinko in the ipvs patch such that the maddr wouldn't get looked up on 
GRE packets, resulting in their being sent with an maddr of 0.

--- ip_masq.c.orig	Sat Aug 12 12:30:15 2000
+++ ip_masq.c	Sun Aug 13 19:03:51 2000
@@ -1464,12 +1464,10 @@
 		return -1;
 	}
 
-#ifndef CONFIG_IP_MASQUERADE_VS
 	/* Lets determine our maddr now, shall we? */
 	if (!maddr && (ip_masq_select_addr(skb,&maddr) < 0)) {
 		return -1;
 	}
-#endif
 
 	switch (iph->protocol) {
 	case IPPROTO_ICMP:

That should be linux/net/ipv4/ip_masq.c in the file lines of the patch.
Thanks,
Matt

I believe that will break some IP_MASQ_VPN stuff. It's simply too late to play
with fire in RC1

Alan, would you still object if I moved the 
 	/* Lets determine our maddr now, shall we? */
 	if (!maddr && (ip_masq_select_addr(skb,&maddr) < 0)) {
 		return -1;
 	}
calls to ip_masq_pptp.c (a module) instead of ip_masq.c?  That shouldn't then 
touch anything critical to ipvs, thus minimizing playing with fire. :)

This patch, applied to kernel 2.2.16-21.3 after the IPVS and ip_masq_pptp 
patches, works, and should not conflict in any way with the IPVS code.

--- linux/net/ipv4/ip_masq_pptp.c.orig  Fri Aug 18 11:57:34 2000
+++ linux/net/ipv4/ip_masq_pptp.c       Fri Aug 18 11:59:42 2000
@@ -456,6 +456,18 @@
        if ((grehdr->version & 0x7F) != PPTP_GRE_VERSION ||
            ntohs(grehdr->protocol) != PPTP_GRE_PROTOCOL) return 0;

+#ifdef CONFIG_IP_MASQUERADE_VS
+  /*
+   * hack around VS' playing with maddr
+   * maddr should always be nonzero otherwise
+   */
+       if (!maddr && (ip_masq_select_addr(skb, &maddr) < 0)) {
+         printk(KERN_NOTICE "ip_masq_gre(): ");
+         printk("determine masq addr failed\n");
+         return -1;
+       }
+#endif
+
        /*
         *      Now hunt the list to see if we have an entry
         */

Applying the above patch to 2.2.16-21.4, I am still unable to do ip masqueraded
IPSEC traffic.  The client simply times out waiting for configuration info (i.e.
it is unable to receive any ipsec packets from the server).

I'm not sure what parts of the debugging output would be useful for this, but
let me know and I can add it to this bug.

A new patch has been added to the VPN masq web site which fixes the interaction
with VS for ipsec as well as pptp.  Please try to get this in a future kernel
release.

I believe this is fixed in errata kernel 2.2.17-14.  The spec file indicates 
that the patch to fix this is being applied.