Bug 12799 - please include ip_masq_vpn patch
please include ip_masq_vpn patch
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Michael K. Johnson
:
: 12990 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-06-21 21:10 EDT by Matt Domsch
Modified: 2008-05-01 11:37 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-24 22:28:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matt Domsch 2000-06-21 21:10:32 EDT
Please include the ip_masq_vpn patch available at
ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html
This allows PPTP connections through a firewall.

+CONFIG_IP_MASQUERADE_PPTP=m
+# DEBUG_IP_MASQUERADE_PPTP is not set
+# CONFIG_IP_MASQUERADE_IPSEC is not set
+# CONFIG_IP_MASQUERADE_GENERIC is not set
Comment 1 Matt Domsch 2000-06-26 14:08:18 EDT
*** Bug 12990 has been marked as a duplicate of this bug. ***
Comment 2 Matt Domsch 2000-06-27 18:00:23 EDT
The patch I previously sent doesn't work quite right.  I'll work on fixing it 
and resubmit as an attachment to this bug.
Comment 3 Matt Domsch 2000-07-06 12:03:09 EDT
ip_masq_pptp.o included in kernel 2.2.16-8 on Winston Beta 3.  Thanks!
Comment 4 Matt Domsch 2000-07-10 10:55:04 EDT
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@wolfenet.com'
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.
Comment 5 Matt Domsch 2000-07-12 19:17:45 EDT
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.
Comment 6 Alan Cox 2000-08-01 18:24:19 EDT
ipvs takes precedence here.
Comment 7 Matt Domsch 2000-08-04 21:59:59 EDT
From: John D. Hardin [mailto:jhardin@wolfenet.com]
Sent: Wednesday, July 19, 2000 9:27 AM
To: Matt_Domsch@exchange.dell.com
Cc: dledford@redhat.com
Subject: RE: FW: ip_masq_pptp error

On Tue, 18 Jul 2000 Matt_Domsch@Dell.com wrote:

> John, any luck looking into this?

I just had a report that it all works properly:

> From erosander@MatrixNS.com Wed Jul 19 07:20:24 2000
> Date: Tue, 18 Jul 2000 23:59:10 -0700
> From: Eric Rosander <erosander@MatrixNS.com>
> To: John D. Hardin <jhardin@wolfenet.com>
> 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.
Comment 8 Matt Domsch 2000-08-13 20:25:19 EDT
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:
Comment 9 Matt Domsch 2000-08-13 21:04:55 EDT
That should be linux/net/ipv4/ip_masq.c in the file lines of the patch.
Thanks,
Matt
Comment 10 Alan Cox 2000-08-14 07:08:55 EDT
I believe that will break some IP_MASQ_VPN stuff. It's simply too late to play
with fire in RC1
Comment 11 Matt Domsch 2000-08-14 08:20:51 EDT
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. :)
Comment 12 Matt Domsch 2000-08-18 17:40:32 EDT
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
         */
Comment 13 Brian Ryner 2000-08-27 23:29:26 EDT
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.


Comment 14 Brian Ryner 2000-09-25 01:53:12 EDT
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.
Comment 15 Matt Domsch 2001-02-24 22:28:10 EST
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.

Note You need to log in before you can comment on or make changes to this bug.