[Openswan Users] FreeSWAN, Wireless Windows 98/ME/2K/XP
RoadWarriors, DHCP over IPsec - overview
Jeannot Langlois
jlanglois at actares.com
Tue Jun 8 16:44:21 CEST 2004
Hi Trevor,
First, thanks for your help. I really appreciate your time helping me out.
I've been doing quite some reading lately about Freeswan, DHCP over
IPsec and windows IPsec clients
(such as SSH sentinel and ipsec.exe). I'm feeling more and more
comfortable every day :).
Trevor Benson wrote:
>Are you saying you want the 10.1.1.0/24 subnet to be served to the
>machines after they establish an IPSec tunnel? I assume you know that
>they would have to have an IP address prior to connecting an 'IPSec'
>connetion.
>
>
I'm actually hoping to find a way to serve DHCP requests on the
10.1.1.0/24 subnet *WHILE* the IPsec tunnels are negotiated, for *EACH*
wireless client, so everything is encrypted.
After I sent the email, I realized that it is necessary that an IP
address is assigned BEFORE the IPsec can be established. Whoops, my
mistake :).
Ideally, I'd like everything to be encrypted as much as possible, so I
have no choice but to use DHCP-over-IPsec I guess, because the leases
must be issued/revoked in a secure manner.
>>The setup would look like this:
>>
>>
>> (ethernet interface)
>> [INTERNET SIDE]
>> ==================
>> FREESWAN
>> LINUX
>> GATEWAY
>> ==================
>> [LAN SIDE]
>> (wifi interface)
>> / | | | \
>> / | | | \
>> / | | | \
>> / | | | \
>>
>> A B C D E
>>
>>
>>A, B, C, D and E are all Windows-based clients (running either 98, ME,
>>2K or XP) using 802.11b wireless cards (actually there will be more
>>clients, but this is just a basic example).
>>
>>Let's suppose the LAN uses the 10.1.1.0/24 subnet address space.
>>There would be NO NAT, as everything would happen within the same
>>10.1.1.0/24 subnet.
>>I'd like the RoadWarriors NOT to be able to see each other, but just
>>
>>
>the
>
>
>>gateway, so they can access the internet using secure tunnels. In
>>
>>
>this
>
>
>>case, we consider the INTERNET side to be trusted (I know this might
>>sound funny but... :)), so the tunnel ends on the FREESWAN GATEWAY's
>>
>>
>LAN
>
>
>>SIDE, and firewall rules on the FREESWAN GATEWAY should not interfere
>>with FREESWAN.
>>
>>
>
>If your machines have IP addresses in the same subnet, and wireless
>cards, they are likely to be able to talk to eachother unless the
>wireless driver would allow you to limit communication to the AP.
>
>If anyone else is more familiar with limiting communications for a local
>subnet over 802.11 let me know, good food for thought.
>
>
>
They'll all be in the same subnet. I guess restricting communication
between the wireless nodes would be way too complicated (and maybe upset
the wireless users too :)), so I'll leave it aside for now.
Actually there *WOULD BE* NAT occuring, but *OUTSIDE* the IPsec
tunnels... just for traffic entering/leaving the FREESWAN gateway
from/to the INTERNET... *NOT* on the WIRELESS side.
So the WIRELESS interface on the FREESWAN gateway would be the LEFT side
of each tunnel, and the windows wireless clients would all be RIGHT
sides of their respective IPsec tunnels.
>>A DNS server listening on the wifi interface on the FREESWAN GATEWAY
>>will be offering DNS services to the Windows RoadWarriors.
>>
>>
>
>Take a look at www.ipcop.org if you are looking for something prebuilt
>that does quite a bit of what your asking for without having to figure
>out the rules or not, then this might be something for you. They are
>about to release the final beta of 1.4.0. I have been using it since
>alphas and am right now logged into an IPSec connection over my Wifi.
>
>
Thanks for the link, but we've already been setting up Soekris boxes
using Pebble Linux and I guess we should be alright with these... I
just need to confirm a couple points such as DHCP-over-IPsec and
RoadWarrior-style Freeswan before I attempt installs/configurations...
I'll keep the link around, just in case. It might be useful some day.
>>So far I have only established SUBNET-to-SUBNET tunnels in all the
>>FreeSWAN experiments I have been attempting to this day.
>>
>>As this is the first time I am attempting such a RoadWarrior-SUBNET
>>setup with FreeSWAN (and I am just starting to read basic/advanced
>>
>>
>tips
>
>
>>on the freeswan.ca documentation), I was wondering about the Windows
>>side's configuration, and feasability.
>>
>>
>
>Almost the same, checkout http://vpn.ebootis.de for the ipsec.exe
>program, and then you just make an ipsec.conf file.
>
>
>
Yeps. I've checked this already and ipsec.exe sounds like a good
solution for Windows 2000/XP.
>>According to the interoperability summary I've seen on the freeswan.ca
>>site, I believe that RSA keys are NOT possible in the Windows 2K/XP
>>
>>
>case
>
>
>>and ONLY the same Pre-Shared Key can be used by all the Windows
>>clients? Is this right? What about Windows 98 and ME ?
>>
>>
>
>I am currently using X.509 certificates from my Windows XP Pro system,
>so it works. Just have to import them through an MMC.
>
>
Ok. I've seen this acronym several times while reading through some
documentation, but I'm not too sure of what it means -- What's an MMC ???
>>As the windows clients have to emulate some kind of IPsec router, I
>>believe that they have to be running some sort of IPsec VPN client
>>software (the Nortel IPsec VPN client comes to mind, or would any
>>
>>
>other
>
>
>>IPsec-style client do the job)? Is this assumption correct?
>>
>>Is this VPN client software required on ALL the different RoadWarriors
>>Windows platforms: 98, ME, 2K, XP ?
>>
>>Most importantly, are there any OpenSource versions of these client
>>software available for these Windows versions? We wouldn't like to
>>
>>
>buy
>
>
>>licenses just for experiments...
>>
>>I've heard that Windows 2K and XP do NOT need such client software, as
>>they integrate IPsec functionality already. Is that true?
>>
>>
>
>Check the vpn.ebootis.de site, that's the command line vpn client
>software, otherwise there are other GUI Windows clients available.
>There was one I was using for a bit, but I was more comfortable
>modifying the file by hand for all my needs, cant remember if it was
>just PSK as well. Ipsec.exe and the gui client are open source. I cant
>remember its name, Jacco De Leeuw or Nate Carlson I think has it in
>their howto.
>
>
>
I have read the Nate Carlson howto, seems great, can't wait to start
implementing that :).
I have emailed Mr. Marcus Muller about ipsec.exe, and he told me that
ipsec.exe only supports Windows 2000/XP because earlier Windows versions
do NOT have an IPsec stack.
So either I'll have to buy licenses for a proprietary solution (probably
SSH Sentinel, which would support ALL windows versions) or I'll just
restrict the WIFI clients to use Windows 2000/XP. I'll start with
ipsec.exe and try to get things to work for now.
>>The IP addresses will be allocated dynamically to the Windows
>>RoadWarriors using a DHCP daemon listening on the FREESWAN GATEWAY's
>>
>>
>LAN
>
>
>>interface. I've seen many people asking for advices about DHCP over
>>IPsec. Is that really a problem? If yes, what can be done about it ?
>>
>>
>>
>
>I think in most cases that people are talking about using DHCP over a
>subnet to subnet connections. Trying to attain the same type of remote
>DHCP addressing as from RFC 3046 relaying DHCP (I may have the RFC #
>wrong).
>
>I have not heard of any option for routing DHCP through IPSec without
>subnets, unless you are just looking to get a local LAN address AFTER
>you establish an IPSec tunnel, and then I would suggest looking into
>L2TP instead of DHCP relay.
>
>
In my case private addresses on the WIFI side would be used at ALL
times. I'm looking for some way to route DHCP securely, *WHILE* the
tunnels are established (I guess one could call that "IPsec tunnels with
DHCP address allocation on demand").
Could that be achieved if the DHCP-relay server would run/listen on the
WIFI interface, on the *SAME* machine which is also running DHCPD ?
According to the DHCP relay docs, this SEEMS possible if both DHCP-relay
and DHCPD use the local loopback interface.
What do you think ?
That's the biggest issue I see for the moment. I'll be experimenting
this soon I think.
>Thanks in advance for your help.
>
>Answers and/or pointers to pertinent FreeSWAN documentation will be
>greatly appreciated,
>
>
>
>
>Do you have a domain behind the Freeswan that the Windows machines will
>be connecting to? Or just internet access? If you have a domain, use
>the Windows Server to enable Routing and Remote Access, and then have it
>pass L2TP VPN connections to your IPSec tunnels.
>
>Trevor
>
>
>
It'll just be a simple internet access on the "ETHERNET SIDE" as
described above.
On the "WIRELESS" side, since we prefer that the wireless clients be
registered within a dns server (so most apps will not complain), a
simple BIND nameserver will be offering nameservice for
"wifihostx-y.wifidomain.lan"-type hostnames (where x is the wireless
client's last IP digit number and y is the subnet number) -- so host
10.1.1.4 would have the following entry registered in the wifidomain.lan
zone: "wifihost4-1.wifidomain.lan". That's why I've put a BIND
nameserver on the Wireless interface.
I think that covers it for now, what do you think ?
--
Jeannot Langlois
Programmeur-Analyste / Software Developer
Administrateur Systeme/Reseau / System/Network Administrator
jlanglois AT actares DOT com
http://www.actares.com
More information about the Users
mailing list