Ah. I don't think that the 2.2.14 IP Chains stuff knows about protocol
50,51 (IPSEC) so your box is probably just discarding those packets.
IPSEC packets are not IP packets, so there has to be something in the
stack that understands them. I think there was a patch out for this,
but the last time we looked at the older Chains stuff, I don't think my
guys actually got this working.
I would recommend that you upgrade to 2.4 and use the newer Netfilter
stuff, which does support protocol 50,51 and has the tools to build
rules for passing it.
Of course, I could just be smoking crack, but I believe this is your
problem and best solution.
Besides, 2.4 and Netfilter is just cooler.
"Brian S. Armstrong" wrote:
>
> The client is IPSEC based, and I have successfully gotten it to connect
> through a windows machine running NAT32 for proxy. it just doesn't seem to
> want to go through IP Masq.
>
> -BA
>
> ----- Original Message -----
> From: "Eric Bravick" <ebravick@nks.net>
> To: <slug@nks.net>
> Sent: Wednesday, April 11, 2001 1:28 PM
> Subject: Re: [SLUG] IP MASQ & VPN
>
> >
> > Brian, what VPN product is your company running?
> >
> > Generally speaking, there are only 2 flavors of VPN software out there
> > right now, TCP circuit based and IPSEC based.
> >
> > As described by Derek below, some of the TCP circuit based VPN's have a
> > problem with anything NATing the packets in between the client and the
> > server (although most modern clients have solved this problem.)
> >
> > IPSEC based VPN clients have a completely different set of issues
> > associated with them, hence my question...
> >
> > Derek Glidden wrote:
> > >
> > > "Brian S. Armstrong" wrote:
> > > >
> > > > Ok- I have been lurking for quite some time and finally have an issue
> which
> > > > I can't seem to find a workaround for. I just got a shiny new VPN
> account
> > > > for getting back into my company's intranet via the internet. I am
> running
> > > > RedHat 6.22 w/kernel 2.2.14-5.0 and using ip masquerading to provide a
> > > > transparent proxy for my internal network to use the internet.
> Everything
> > > > works fine, except for the VPN back into my company's intranet. When
> I plug
> > > > the client into raw internet and use the VPN it works fine. While
> running
> > > > tcpdump on the outside interface when trying to connect to the VPN, I
> can
> > > > see the packets leaving my external interface destined for the VPN
> address,
> > > > but no packets are ever returned from the VPN.
> > >
> > > The problem you're probably having is that the encrypted packets contain
> > > your "real" address of the machine behind the Masqueraded connection.
> > > When the packets get NAT'ed through ipmasq, that "internal" address has
> > > already been encrypted into the payload, so when the server decrypts the
> > > packet and tries to send a response back, instead of trying to send it
> > > to your ipmasq box, it thinks it needs to send it to the "real" address
> > > of your machine, which is almost certainly non-routable from the network
> > > perspective of the VPN server.
> > >
> > > Generally speaking, it's very very difficult to make VPN'ed traffic pass
> > > through a NAT'ed connection. I've seen the ip_masq VPN patch around,
> > > but it's only supposed to work with specific types of VPN software.
> > >
> > > If it's some flavor of IPSEC implementation, you may have luck, if it's
> > > some kind of proprietary thing, you probably will never get it work
> > > where the packets get NAT'ed through your ipmasq connection.
> > >
> > > You may be better off installing FreeS/WAN on your ipmasq box
> > > (www.freeswan.org) and trying to get the VPN working with it. Note,
> > > however, that FreeS/WAN is IPSEC, so if your VPN is not IPSEC, it will
> > > not work.
> > >
> > > Unfortunately, I do this kind of stuff at work and this is just the way
> > > the vast majority of products are. Even with IPSEC a fairly
> > > well-established standard, so many companies still do VPNs with a
> > > proprietary 'roll-your-own' protocol that just doesn't work with
> > > anything else. (Of course, that's the whole idea - if your server
> > > worked with everyone else's clients, they wouldn't have to also purchase
> > > the client licenses from you also. *sigh*)
> > >
> > > --
> > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> > > #!/usr/bin/perl -w
> > > $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
> > > {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
> > > $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
> > > [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
> > > "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
> > > unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
> > > >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
> > > 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
> > > print+x"C*",@a}';s/x/pack+/g;eval
> > >
> > > usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
> > > | extract_mpeg2 | mpeg2dec -
> > >
> > > http://www.eff.org/ http://www.opendvd.org/
> > > http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
> >
> > --
> > --------------------------------------------------
> > -- Eric Bravick, Engineering Shock Trooper --
> > --- Networked Knowledge Systems ---
> > ---- P.O. Box 20772 Tampa, FL. 33622-0772 ----
> > ----- (813)342-4140 Voice (813)342-4160 FAX -----
> > ------ ebravick@nks.net ------
> > --------------------------------------------------
> >
-- -------------------------------------------------- -- Eric Bravick, Engineering Shock Trooper -- --- Networked Knowledge Systems --- ---- P.O. Box 20772 Tampa, FL. 33622-0772 ---- ----- (813)342-4140 Voice (813)342-4160 FAX ----- ------ ebravick@nks.net ------ --------------------------------------------------
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:35:40 EDT