This bounced because Ian isn't s*bscribed under this address. However,
it was worth reposting.
Paul
----- Forwarded message from slug@nks.net -----
From: "Ian C. Blenke" <icblenke@blenke.com>
Date: Sun, 15 Apr 2001 14:35:50 -0400
To: slug@nks.net
Subject: Re: [SLUG] IP MASQ & VPN
Message-ID: <20010415143550.A30981@blenke.com>
References: <007b01c0c22c$494ebb60$c7cb1fac@BALaptop> <3AD46E52.CDD8CC78@illusionary.com> <3AD4942C.FECFD912@nks.net> <008f01c0c2b0$33232db0$78821fac@BALaptop> <3AD623B0.F515AEB6@nks.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AD623B0.F515AEB6@nks.net>; from ebravick@nks.net on Thu, Apr 12, 2001 at 05:52:48PM -0400
On Thu, Apr 12, 2001 at 05:52:48PM -0400, Eric Bravick wrote:
>
> 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.
IPSEC uses ESP encapsulation (IP protocol 50) or AH packets (IP protocol 51)
for VPN sessions.
PPTP uses PPP over GRE (IP protocol 47) for VPN sessions, with an outbound
TCP port 1483 control channel to initiate the connection.
While these are both IP protocols, your kernel masquerading currently only
really knows how to handle TCP (IP protocol 6), UDP (IP protocol 17), and
ICMP (IP protocol 1), and then only generically. Some things like active mode
FTP transfers require special handling (return TCP port 20 data transfers,
etc).
The easiest way to get IPSEC working *might* be to directly forward *ALL* type
50 and 51 packets directly through your firewall both ways *WITHOUT* NATting
them (changing the src or dst of those packets breaks their authenticity and
confuses the remote VPN server). This might allow it to work, but can be
quite a large security concern, and will break more than one VPN session from
being established through your firewall. The other problem with this is that
the remote firewall (or VPN server) would see arriving packets with private
IP addresses and would return packets to a non-routable source. This is why
you will likely need a patched masquerading module.
The "better" way is to patch your kernel masquerading to automagically (and
transparently) allow sessions dynamically as they are established. Doing this,
the firewall would be able to track multiple IPSEC sessions and route the type
50,51 packets as appropriate.
I've had good success tunnelling PPTP over OpenBSD/IPFilter with a simple
redir of protocol 47 packets to the client workstation IP behind the firewall.
I've also managed to get IPSEC working between two RoadRunner OpenBSD boxen
without much hassle (other than the dynamic nature of their IPs).
You *could* just use FreeSWAN (http://www.freeswan.org) to VPN directly from
your firewall instead of from a client PC behind, which would avoid all of the
NAT problems all together.
> 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.
I would recommend Netfilter as well: if for nothing more than the ability to
use stateful inspection (my primary reasons for using IPFilter and OpenBSD in
the first place).
> > 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.
You will find that there are "grades" of Network Address Translation (NAT)
firewalls out there. Linux IP Masquerading is very robust, and can handle a
wide variety of plugins... from active mode FTP and real-video streaming in
2.2 kernels and patches for RTP/RTSP H.323 masquerading, to stateful
inspection in the newer netfilter stuff. But there are a number of other
IP stacks out there as well, on a variety of platforms, with vendors that
may or may not handle any given protocol. I've only seen a few NAT
implementations that can handle PPTP, and only a couple that are IPSEC aware.
> > > 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.
Actually, I've seen mostly PPTP, PPP over L2TP, IPSEC, and oddball proprietary
UDP based protocols like Shiva and PGPNet. While a TCP circuit based VPN
session would be easy to NAT, I've never really come across anything outside
of PPP over SSH (please enlighten me to others though, I'm always looking
to learn!)
> > > 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.)
I would have to argue this. TCP circuit based VPNs would be trival to NAT. It's
the non-session oriented packet nature of UDP based protocols and other oddball
IP protocols like GRE and ESP/AH that really throw firewalls for a loop.
> > > > 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.
This is usually the primary reason IPSec breaks from a NATted private IP
subnet... the masquerading/NAT in your firewall would need to deal with this.
> > > > 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.
>From past experience with that patch, I think they were just allowing GRE
encapsulated traffic (PPTP).
> > > > 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.
In that case, you'd be on your own. :( A thorough google search may dig up
others in your predicament.
> > > > 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.
You can also use an updated pppd and the PPTP client to VPN if your VPN is
PPTP/GRE based. It works, but is a real bear to setup.
> > > > 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*)
Closed source software sucks. :)
- Ian C. Blenke <ian@blenke.com>
----- End forwarded message -----
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:43:17 EDT