Re: IPsec and IPMasq/Proxy
On Sun, Oct 01, 2000 at 12:49:12PM -0400, Randy Edwards wrote: I ran into some trouble using a Debian box as an IP Masq gateway (also running Squid) to a network which uses a VPN box employing IPsec. The ISP's tech support said that GNU/Linux was incapable of doing NAT properly with IPsec and that I'd have to kill the NAT and proxy to make things work. It shouldn't pose any problems - we use exactly this setup at work without ill-effects. -- Mark Brown mailto:[EMAIL PROTECTED] (Trying to avoid grumpiness) http://www.tardis.ed.ac.uk/~broonie/ EUFShttp://www.eusa.ed.ac.uk/societies/filmsoc/ pgpemZILBqev5.pgp Description: PGP signature
Re: IPsec and IPMasq/Proxy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 A long time ago, in a galaxy far, far way, someone said... I ran into some trouble using a Debian box as an IP Masq gateway (also running Squid) to a network which uses a VPN box employing IPsec. The ISP's tech support said that GNU/Linux was incapable of doing NAT properly with IPsec and that I'd have to kill the NAT and proxy to make things work. They're almost right - Kernel 2.2 doesn't like to do NAT on IP protocols other than TCP and UDP. I think that may change for 2.4, but don't quote me on that. However, it can be done, with special tools and relatively minor and well-tested kernel modifications. ftp://ftp.rubyriver.com/pub/jhardin/masquerade/ip_masq_vpn.html has all the information you need. You do need to realise, however, that there can be one and only one IPsec device behind the NAT firewall. Ditto with MS' PPTP VPN stuff. Another solution would be to put IPsec on Linux: http://www.freeswan.org. I've heard good reports on this implementation, but I've not yet used it. I have no experience with IPsec, but this sounded strange. Can anyone confirm or deny this? I can't understand why a Windows machine can plug into the net but that GNU/Linux doing Masquerading or using Squid can't do the same. Could someone whack me with a clue bat? TIA. The problem is, as I said before, kernel 2.2 doesn't like to do NAT on IP protocols other than TCP and UDP. When the kernel does NAT, it translates the source address of the connection to be that of the interface, and does the reverse when packets come back through. However, to be able to do that, the NAT subsystem needs to be able to track the connection. IP protocols 47 (GRE, used by PPTP), 50 (IPsec ESP), and 51 (IPsec AH) do not carry this connection tracking information, therefore these connections can not be forwarded automatically, like a POP3 connection can. You must basically do port forwarding on these alternate IP protocols to get the packets to the correct host. As to why Windows just works but Linux doesn't... Windows is build to work only on way, so it's easy to get working just right. Linux has more flexibility, therfore requires more work to get the details right. HTH. - -- - -- Phil Brutsche [EMAIL PROTECTED] GPG fingerprint: 9BF9 D84C 37D0 4FA7 1F2D 7E5E FD94 D264 50DE 1CFC GPG key id: 50DE1CFC GPG public key: http://tux.creighton.edu/~pbrutsch/gpg-public-key.asc -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE514Mm/ZTSZFDeHPwRAlYAAKC70vws3LkWP3dfhHjoYAYZdY7qBQCgkhzd O697zWZ+lJBSh09LIXULUOg= =Nw9h -END PGP SIGNATURE-
Re: IPsec and IPMasq/Proxy
The problem is, as I said before, kernel 2.2 doesn't like to do NAT on IP protocols other than TCP and UDP. Almost true. Using the iproute2 tools, you can do a static NAT of an inside box to outside. You can then use standard packet filter firewall rules to block various ports you don't want access to from outside. It is the Linux masquerading code that has the problem, regular NAT works just fine. Problem is that it burns another external IP address.
Re: IPsec and IPMasq/Proxy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A long time ago, in a galaxy far, far way, someone said...
The problem is, as I said before, kernel 2.2 doesn't like to do NAT on IP
protocols other than TCP and UDP.
Almost true. Using the iproute2 tools, you can do a static NAT of an
inside box to outside. You can then use standard packet filter firewall
rules to block various ports you don't want access to from outside. It is
the Linux masquerading code that has the problem, regular NAT works just
fine.
The ip neigh {add|del|change|replace} ... sequence?
Problem is that it burns another external IP address.
Um... not good.
- --
- --
Phil Brutsche [EMAIL PROTECTED]
GPG fingerprint: 9BF9 D84C 37D0 4FA7 1F2D 7E5E FD94 D264 50DE 1CFC
GPG key id: 50DE1CFC
GPG public key: http://tux.creighton.edu/~pbrutsch/gpg-public-key.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE5149C/ZTSZFDeHPwRAp8QAKDGcGvOFTEyuRorf10sFplLyQK1vwCeKSVL
XQNRB4nEBvbfWemVJtfKeb4=
=CiCq
-END PGP SIGNATURE-
Re: IPsec and IPMasq/Proxy
The ip neigh {add|del|change|replace} ... sequence?
Yeah. Look in /usr/share/doc/iproute and print off one of the cref
(command reference) docs (note the .ps file wants A4 paper)
Problem is that it burns another external IP address.
Um... not good.
Well, yeah. That is the thing with NAT as opposed to Masq but NAT is a lot
faster. If you have the addresses to spare, you assign one for the
internal IPSec or PPTP or whatever VPN unit and NAT it at the
firewall. The thing is that a lot of these protocols use things like GRE
that Linux does not like to masquerade. Heck, Linux doesn't like UDP all
that much ... try running a CIPE VPN from behind a firewall ... no can do.
