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 ------
> --------------------------------------------------
>
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:30:36 EDT