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:25 EDT