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