|
|
||||||||||||||||||||||||||||||||||||||||||
|
Home | Products | Buy | Support | Partners | About | Contact |
||||||||||||||||||||||||||||||||||||||||||
| Contact us | ||||||||||||||||||||||||||||||||||||||||||
|
It's time to have confidence in your firewall! |
||||||||||||||||||||||||||||||||||||||||||
News 2001/05/09: I was at a LINUQ meeting tonight, a great Linux group in Quebec city promoting free software and Linux. They gave me the opportunity to introduce FreeSwan and VPNs to their members. My presentation (html) is available in french here. You can find the LINUQ group homepage here. Introduction : This tutorial describes the configuration needed to setup Ipsec tunnels in various situations such as RoadWarriors and NATed/Firewall gateways. This document assumes you have already installed Freeswan and knows a bit of the Ipsec/Freeswan terminology. You should read the Freeswan documentation before use of the present document. My Ipsec gateways are :
*** All IP addresses used in this document were selected randomly
The practical configurations covered are : Simple subnet-to-subnet configuration (RSA). Subnet-to-subnet configuration with a NATed gateway (RSA). RoadWarrior configuration : Freeswan-to-Freeswan (RSA). RoadWarrior configuration : NAI's PGPnet-to-Freeswan (PSK). RoadWarrior configuration : IRE's Safenet SoftPK-to-Freeswan (PSK). Using a central Ipsec gateway as a "tunnel hub". Expanding NT domain logon validation and network browsing through IPSec tunnels. Subnet-to-Subnet : Win2000-to-Freeswan (PSK).
Simple Subnet-to-Subnet configuration. This is the simplest case and easiest to setup. We have 2 LANs that we want to link together through the Internet. Each LAN is connected to the internet via router or firewall with static IP adresses. For example :
Both Ipsec gateways will have the same ipsec.conf configuration file.
*Not truly valid, you should create a RSA signature of at least 1024 bits on each gateway. And be carefull with the necessary whites spaces. On each gateway :
Then paste the key in /etc/ipsec.secrets. Finally, paste the value from the field #pubkey into the coresponding rsasigkey parameter in the ipsec.conf file.
Restart the ipsec service on both gateways and observe the logs for any errors.
This configuration assumes that both Ipsec gateways use the interface eth0 to reach the internet. Most default values were used here for simplicity.
Both gateways must have IP forwarding turned on to allow packets from the leftsubnet to reach the rightsubnet and vice-versa. Ipchains must be installed and used to permit traffic from leftsubnet to rightsubnet.
Remember that Ipsec is as secure as your gateways are. I recommend to only accept Ipsec traffic on the interface visible to Internet. On the left gateway :
Disable any unused services (inetd.conf) and protect the remaining services called from inetd (hosts.allow and hosts.deny). Do not run daemons that should not resides on a security gate. I.e DNS, Sendmail and such services with a big security history. I often run SSH on those gateways, its the only backdoor if your tunnel stops working. If using SSH here horrifies you, use a good internal PPP access with callback support... just in case.
That's it for the simple subnet-to-subnet case. The tricky ones coming...
Subnet-to-Subnet configuration with a NATed gateway.
This is the first tricky configuration as one of the gateways is behind a router/firewall doing Network Address Translation (NAT). I use the term NAT here for a 1 to 1 translation. I.e one external IP address is converted to 1 internal IP address and vice-versa. This is not masquerading or PAT. This configuration can only work using ESP, because AH does not support modifications in the IP header. As of Freeswan 1.3, this configuration also only works with RSA authentication. For example :
The difference is that the left gateway is no longer being exposed directly to the Internet. The trick here is to have 2 different configuration files :
The right gateway only have to see left as its external NATed address. This work because authentication is based on @sgx.yourdomain.com, not on a real IP address ( the @ says to KLIPS to not resolve that name to an IP. No need to put registered hosts names here).
Proceed the same way as the simple subnet-to-subnet configuration for your ipsec.secrets files.
The NAT/Firewall device was in fact a CISCO 1600 router in my setup. Don't forget that the router's access-lists (IOS) or firewall rules must let pass UDP 500 and ESP (50) for that setup to work.
Altough I did not had the chance to test it, this could work even if both gateways are NATed, if you adjust the configuration.
RoadWarrior Configuration : Freeswan-To-Freeswan.
This setup is usefull for moving users with laptop to connect to a central network using Ipsec. As most of the time they will be using a modem over an async connection to the ISP, my example describes that case.
The difficulties of this configuration origins from the fact that the initiator of the tunnel IP configuration (DHCP) is volatile and unknown from the right gateway. The configuration will have to reflect that situation and permit multiple users to connect at the same time. :
This setup works well with RSA authentication, and can work with PSK if you update ipsec.secrets automaticly on the RoadWarrior (had a script to do that).
To bring the ipsec tunnel up as I connect to the internet, I usually remove Ipsec from start-up :
And bring the ipsec service up and down with my PPP interface through ip-up.local and ip.down.local in the /etc/ppp directory. Don't forget to make those executable.
You can NOT have both RSA and PSK RoadWarriors as of Freeswan 1.3.
Some tips about routing & RoadWarriors :
RoadWarrior configuration : NAI's PGPnet-to-Freeswan
Using Windows clients to access Freeswan is for me the key to integration of IPSec and the desktop. NAI's PGPnet is great for that task . It is pretty stable and transparent for the user. Remember that only the commercial copy of PGPnet can do tunnels as I will show in this example :
Here's the steps needed to setup PGPnet on the Win32 client (letfgateway) for that configuration (refer to NAI's documentation for installation) :
*I choosed to rekey faster that Freeswan to solve a common rekeying problem with Win32 Ipsec clients.
Some Screenshots of that configuration.
Ipsec.conf and ipsec.secrets on right gateway :
All your RoadWarriors will have to share the same PreShared Key.
See my tips about routing and RoadWarriors.
RoadWarrior Configuration : IRE's SafeNet/SoftPK-to- Freeswan
Using the same example as for PGPnet :
IRE's SafeNet/SoftPK (3DES) is a much lighter software to do Ipsec tunnels but does not integrates PGP in emails and local encryption. If your only goal is to do some Ipsec tunnels on a Win32 desktop, SafeNet is the good choice as it is cheaper than NAI's PGPnet.
Its configuration is not complex and works in most cases (exept with ADSL as it does not support a PPPoe interface).
Lets do the Safenet's setup on the Win32 desktop (left gateway) for the configuration above :
All your RoadWarriors will have to share the same PreShared Key.
The right gateway's configuration (Freeswan) will be the same as the previous example.
As I said earlier, the troubleshooting is a lot easier checking the logs on the responder (right gateway). Most of the problems origins from configuration errors and typos like different netmasks entered on each side.
See my tips about routing and RoadWarriors. Using a central Ipsec gateway as a "tunnel hub"
If you got multiples subnets connected to a central one, lets say a few remote locations connected to your headquarters, you might want to connect them all using Ipsec to permit communications between those remotes locations. You could create a mesh, i.e a connection from one locations to each others on all your gateways. If you got only 2 or 3 remote locations, this will work. But as you add more and more locations, it is gonna be a pain to administer as you will have to update all your ipsec gateways each time you add another tunnel. If you got 10 or more locations, this could become impossible to maintain ( 10*10 = 100 tunnels !).
Using one central location as a "tunnel hub" simplifies connecting all those subnets together, as only one tunnel is added for a new location. There are 3 drawbacks to that solution :
That configuration might look like this :
The remote locations are on the left side and the headquarters on the right. We want the subnets 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24 to communicate with each others and with the central network 192.168.0.0/24.
The trick to make this work is on the graphic... all remote locations are on a C class network just as the central location. But each SA are for a longer netmask at the central site. Each remote location will create a tunnel from their subnet to the central subnet 192.168.0.0/16. But the central subnet is a 192.168.0.0/24 network.When this is done, the central Ipsec gateway will have an eroute for each remote network. When someone on a remote location wants to talk to another remote location, lets say 192.168.1.8 to 192.168.2.16, it thinks the destination is on the central network, but the central Ipsec gateway have a specific eroute for the 192.168.2.0/24 network, so it routes the packet through the good tunnel for that remote location. Networks : Central subnet : 192.168.0.0 255.255.255.0 Remote location 1 : 192.168.1.0 255.255.255.0 Remote location 2 : 192.168.2.0 255.255.255.0 Remote location 3 : 192.168.3.0 255.255.255.0
Ipsec tunnels : 192.168.1.0/24 --> 192.168.0.0/16 for remote location 1 192.168.2.0/24 --> 192.168.0.0/16 for remote location 2 192.168.3.0/24 --> 192.168.0.0/16 for remote location 3
The configuration is the same as the Simple subnet-to-subnet case, just remember the network mask trick and everything should work.
You can control wich remote locations can talk to another by adjusting your forwarding rules with ipchains on the central ipsec gateway.
Subnet-to-Subnet configuration : Win2000-to-Freeswan (PSK).
This is the most complex configuration, because of microsoft's strange way to represent a connection and its parameters. This section is far from being complete, as I did not find any simple way to explain this in details yet without making you get crazy through all the menus and options, I will at first try to explain Microsoft's logic of a tunnel mode connection.
We can use the simple subnet-to-subnet case as a model :
A connection in Microsoft's terminology is a Security Policy. An Ipsec Security Policy is configurable through an MMC console with the IP Security management Snap-in added.
When you create a new IP Security Policy (a connection) you must define rules for the traffic going throught it. You must define at least 2 rules for a tunnel mode connection to work :
A rule defines a :
Ipsec/IKE proposals, rekeying settings and PFS are defined inside the Filter Action.
This logic can be very confusing, as you can go from properties menus inside properties menus. Ouch !
The generics steps I recommend to make this setup work are :
Test it :
The longest SCREENSHOTS you've never seen to setup the previous example. 900 KB...you've been warned ;).
HINTS & LIMITATIONS :
I will need feedbacks to make this section clear, so don't hesitate to send me some comments !
|
||||||||||||||||||||||||||||||||||||||||||
|
Images and content are copyright to Lindengrove 2003 Site designed by Lindengrove |
||||||||||||||||||||||||||||||||||||||||||
