[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: VPN on Kernel 2.4.18



Thanks Vector.

Ok, I worked on this some more.

I built up a test system with

Debian 2.2 Kernel 2.4.18 on it.
I compiled in all the GRE stuff and such to allow all PPTP and GRE
traffic through.

I then got Masq up and running.
Then I forwarded port 1723 and Protocol 47 to my Internal windows 2000
server using these commands.

iptables -t nat -A PREROUTING -i eth0 -p TCP -d (public IP) --dport 1723
-j DNAT --to 10.10.10.5:1723

iptables -t nat -A PREROUTING -i eth0 -p 47 -d (public IP) -j DNAT --to
10.10.10.5

I then tested the PPTP connection using a Windows XP computer out on the
Internet and whohoo it connected.

I could then browse the Windows 2000 Server remotely.

So, from what it looks like, the new Kernel can do everything the old
Kernel couldn't do unless it was patched and stuff.

Now I need to figure out how to really use IpTables because I have a
sneaking supission that my firewall isn't really secure right now.

I also want to try the pptpd route, but for now I think this will work,
security isn't a real big problem where this will be installed, unless
the hacker can get root access with it.

-Dave



-----Original Message-----
From: Vector [mailto:debian@itpsg.com] 
Sent: Thursday, March 07, 2002 4:39 PM
To: Jeff; Debian User
Subject: Re: VPN on Kernel 2.4.18


----- Original Message -----
From: "Jeff" <jcoppock1@attbi.com>
To: "Debian User" <debian-user@lists.debian.org>
Sent: Wednesday, March 06, 2002 10:53 PM
Subject: Re: VPN on Kernel 2.4.18


> Dave Scott, 2002-Mar-06 15:30 -0800:
> > Thanks Jeff.
> >
> > Wow, I thought this was going to be an easy task. :(
> > Surely there must be thousands of others that have done just this.
> >
> >   |---------------------|
> > |-|----Client(9x,2K)----|
> > | |---------------------|
> > |     |DSL Modem
> > |     |
> > |     |
> > | |---------------------|
> > | |-----Internet--------|
> > | |---------------------|
> > |     |
> > VPN     |
> > |     |Public IP
> > | |--------------------------|    Nat   |------------|
> > | |----Firewall--------------|----------|Workstations|
> > | |--Debian 2.2 W2.4Kernel---|          |------------|
> > | |--------------------------|          192.168.0.10-200
> > | NAT |192.168.0.1
> > |     |
> > |     |
> > | |----------------------------|
> > | |---Windows NT 4.0 Server----|
> > |-|---PP2P Installed-----------|
> >   |----------------------------|
> >            192.168.0.2
> >
> > Need up to 6 VPN connections to the NT Server
> > Is this possible.  Or is there just a better way to go about this.
> > They don't have any money for Cisco or Hard Firewall.
> >
> > At first I was going to use 2.2 Kernel because I read if you
recompile
> > the kernel and install ipfwd you can GRE multi connections across,
but
> > now I just read that 2.4 hasn't been configured to allow multi
connects
> > across, but the date of the article is old.
> > Oh how confusing this is.
> >
> >
> > Cheers
> > -Dave
>
> Nice work on the ascii diagram!  :-)
>
> Personally, I wouldn't use GRE for a VPN for the reasons I stated
> on my previous response.  I'd say you have 2 solutions worth
> considering:
>

    Um, OK..When was the last time you setup PPTP through a firewall.
It doesn't exactly work like "just forward 1723 thorugh your firewall
and your all set."  PPTP uses GRE protocol number 47.  IPSec uses
protocol 50.  Does ipchains support 'forwarding' this through the
firewall?  Nay, I say...been there done that.  If you are using a
2.2.x kernel and you are running ipchains, the ONLY way to make this
work is:
1: If you have more than one address on the public net, and you aren't
doing policy based routing or 'true NAT' then the ONLY ip you can use
for the forwarded PPTP connections and GRE is the one that is actually
being masqueraded for the internal machines (e.g. internal machines
internet connection appear to come from address X on the remote host,
then you had better do your port forwarding through ip X and not any
other or it won't work).
2: Download and install John Hardin's VPN kernel patch.  Patch your
kernel source and follow the directions on building your kernel in the
linux VPN how-to.
3: Now that you have setup tcp port 1723 to forward to the internal
PPTP server AND you have built a custom kernel with support for pptp
masquerading, you download and install the latest version of ipfwd
which is a small utiltiy used only to masquerade protocols unknown to
ipchains (namely in this case protcol numbers 47 and 50).  Also set
this up according to the VPN howto (e.g. bash # ipfwd --masq
192.168.0.99 47 &).  After that is done, you might try it and see if
you can get a connection.

The fine point that the VPN howto leaves out is that the reply traffic
from the internal vpn box must come from the same IP as the external
address you are connecting to.  Also, the fine points of actually
doing this wih a linux 2.2.x kernel is what is kind of the pain.  The
message I'm responding to seems to do the same thing; glosses over all
issues in doing this with a 2.2.x kernel.

vec

> 1.  Use PPTP.  This works and the encryption is adequate, unless
> anyone with some resources thinks you're hiding something
> special  :-)   You'll need to open port 1723 on your firewall for
> the incoming connections.  Just don't use MS-CHAPv2 for auth
> here, there's a well-known vulnerability with it.  So, the remote
> clients will run the native PPTP to connect directly to the NT
> server, having turned on the PPTP support to recieve connections.
> Oh, and you'll actually need to port forward through the firewall
> since you have NAT.  Or, you could run the Linux pptpd server on
> the firewall to terminate the connections there and just route
> normally on the private side.  I like the later.
>
> 2.  Use Freeswan.  This is an IPSec solution that is much more
> secure, but more complex too.  There are interworking issues
> between Linux and Windows but there is some good information on
> that on the web (a google search for "freeswan windows" will turn
> up some of them).  So, in this scenario you'd run the Freeswan
> server on the Firewall and terminate the connections there.  Be
> sure to allow port 500 to connect to the firewall, and I think
> protocol ESP as well.  That's what IPSec runs over.  You'll find
> everything you'll need on the Freeswan website, and you'll need
> to patch the kernel too.
>
> That's all I can think of at the moment.  Having only time in
> your budget is not so uncommon.  With VPN's, like with any other
> security, the more secure the more complex...most of the time.
>
> cya,
> jc
>
>
> --
> Jeff Coppock Systems Engineer
> Diggin' Debian Admin and User
>
>
> --
> To UNSUBSCRIBE, email to debian-user-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
>


-- 
To UNSUBSCRIBE, email to debian-user-request@lists.debian.org 
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org



Reply to: