|
| |
|
|
|
|
|
|
|
|
|
|
|
|
In this section we will work toward creating a basic site-to-site VPN using IPSec. First, we should get a few technical points out of the way.
IPSec can be used in multiple arrangements: the most common are site-to-site and access. What we'll be creating here is the site-to-site version. In essence, we'll be bridging two remote locations transparently using the internet. All the VPN work is done by the firewall computer...the host computers on the LAN don't need to do anything to participate, it's completely transparent. That said, for this to work you will obviously need two firewalls at different locations, both capable of IPSec VPN traffic. In this example, we will assume we have a remote location that's using a Linux firewall just as we have at our original location. In other words, it will be a mirrored version of our original network diagram, with the internet in the middle:
| PC 1 |
-- |
(LAN Switch) |
--- |
Linux Router! |
--- |
|
--- |
Linux Router! |
--- |
(LAN Switch) |
-- |
PC 1 |
| PC 2 |
-- |
[[VPN Tunnel]] |
-- |
PC 2 |
| PC 3 |
-- |
-- The Internet-- |
-- |
PC 3 |
An important note on topology: The remote network must be on a different subnet than the local network. For example, you can not have both networks using 192.168.1.0/24.
Now hopefully, when you consider that you're about to attempt sending local traffic over the public internet, the question of security will come to mind. After all, you don't want everybody watching your LAN traffic, do you? Well fear not, IPSec was designed with security in mind...the fact that it's short for IP Security should tell you that. :) In fact, major corporations use this same technology every day to transport data between remote business locations. And since Linux is so versatile, we'll be using some of the most powerful encryption on the market today (at no additional cost!). Another cool fact is since we're using standard IPSec traffic your firewall should be interoperable with IPSec devices from any number of vendors.
|
|
|
Alternative Alert! - IPSec
A number of readers have pointed out to me that a competing product, known as OpenVPN, is also available for creating VPNs. I chose IPSec for a couple reasons: First of all, I think IPSec is implemented so widely that it's an important topic for any would be net-admin to cover. Even though the implementation differs, the core fundamentals are the same whether it’s a simple Linux box or a high-end VPN concentrator. Furthermore, after working with OpenVPN, I've found its client-server model to be better suited to road-warrior style VPNs which I hope to cover in another section. That said, I don't want to discourage anyone from trying OpenVPN...In fact I always encourage branching out!
|
|
|
|
|
|
First we need to install a couple IPSec packages. Racoon is responsible for the key exchange portion of our IPSec connections, and will be used to configure our kernel with all the necessary IPSec information. The ipsec-tools package provides just what it sounds like...supporting tools for our IPSec implementation.
Firewall:~# apt-get install racoon ipsec-tools
You will now be prompted with two options: direct configuration or using the racoon-tool program.
We'll be using racoon-tool which nicely automates most of the configuration needed to make our IPSec connection. I recommend everyone start with racoon-tool. If you want to learn the lower-level configuration, just look at the files generated after we run racoon-tool, and you will know what the "direct configuration" files will look like. Most likely on a non-Debian system you would just be using the direct configuration method.
Now that our program is installed, we'll have to tackle the configuration. Since we're using racoon-tool, we can do this from a single file: /etc/racoon/racoon-tool.conf
Firewall:~# nano -w /etc/racoon/racoon-tool.conf
You will see that there are nice example configurations already commented into the config file. This file will need to be edited on both the local and remote networks, assuming you're setting both up at once. Keep in mind that all settings must match on both sides! If they don't, IPSec won't be able to negotiate a connection.
For the remainder of the configuration examples we'll pretend the local network has the following properties:
ISP (external) address: 10.1.1.1
LAN (internal) address: 192.168.1.1 (same as always)
For the remainder of the configuration examples we'll pretend the remote network has the following properties:
ISP (external) address: 10.100.100.1
LAN (internal) address: 192.168.100.1
Let's show the entire racoon-tool.conf configurations first, then break them down:
|
|
|
| Local Configuration |
|
Remote Configuration |
connection(ToRemote):
src_range: 192.168.1.0/24
dst_range: 192.168.100.0/24
src_ip: 10.1.1.1
dst_ip: 10.100.100.1
authentication_algorithm: hmac_sha1
admin_status: yes
peer(10.100.100.1):
passive: off
verify_identifier: on
lifetime: time 30 min
hash_algorithm[0]: sha1
encryption_algorithm[0]: aes
my_identifier: address 10.1.1.1
peers_identifier: address 10.100.100.1 |
connection(ToLocal):
src_range: 192.168.100.0/24
dst_range: 192.168.1.0/24
src_ip: 10.100.100.1
dst_ip: 10.1.1.1
authentication_algorithm: hmac_sha1
admin_status: yes
peer(10.1.1.1):
passive: off
verify_identifier: on
lifetime: time 30 min
hash_algorithm[0]: sha1
encryption_algorithm[0]: aes
my_identifier: address 10.100.100.1
peers_identifier: address 10.1.1.1 |
|
As you can see, the only settings that vary are the IP addresses configured on each side. Each configuration file also has roughly two parts, the connection entry and the peer entry. The connection entry defines which peers are involved, which the peer entry defines specific settings for the peer. Keep in mind that you don't need to limit yourself to one of each; you can potentially run many different IPSec connections and peers just by adding additional entries. Now we'll explain the configuration:
|
|
|
connection(ToRemote):
|
Defines a connection. You can have as many of these as you want. The name in () is arbitrary. |
|
src_range: 192.168.1.0/24
|
The range of IP addresses on the local LAN (internal network). Must be in a separate range from the remote network. |
|
dst_range: 192.168.100.0/24
|
The range of IP addresses on the remote LAN (internal network). Must be in a separate range from the local network. |
|
src_ip: 10.1.1.1
|
The ISP (external) IP address of our local firewall. |
|
dst_ip: 10.100.100.1
|
The ISP (external) IP address of our remote firewall. |
|
| authentication_algorithm: hmac_sha1 |
Defines hmac_sha1 as the algorithm used for authentication. Options include hmac_sha1 and hmac_md5. SHA1 is generally considered stronger. |
|
peer(10.100.100.1):
|
Defines a peer configuration. The IP address should match the dst_ip defined in the connection. |
|
passive: off
|
If passive is on, the router won't initiate the connection. With passive off, a connection will be attempted. |
|
verify_identifier: on
|
Verify the identity of your remote endpoint (probably a good idea). |
|
lifetime: time 30 min
|
The lifetime after which the connection must be renegotiated. A shorter lifetime gives malicious parties less time to crack into a given session. |
|
hash_algorithm[0]: sha1
|
Hashing is used to verify all traffic has not been tampered with en-route. Each packet is hashed as it leaves, and hashed again when it arrives at the remote endpoint. If the hashes don't match, the packet has been altered and is dropped. MD5 and SHA1 are available. You can also specify more than one. |
|
encryption_algorithm[0]: aes
|
Here you specify the encryption algorithm used. This is what keeps your data unreadable by 3rd parties as it travels over public networks. You should have lots of options for this. I've chosen AES as it is one of the stronger types available. Options include aes, des, 3des, blowfish, cast128. You can also specify more than one. |
|
| my_identifier: address 10.1.1.1 |
How you identify yourself to the remote host. Can include IP Addresses, domain names, and others. |
|
| peers_identifier: address 10.100.100.1 |
How to identify the peer (same opts as above). |
|
There are multiple options for how to authenticate the two peers with each other. The most secure (and also most complex) are to use certificate files. The simpler option (but less secure) is to use a pre-shared key. We'll be using a preshared key here. I recommend generating a long string of random characters to use as your key. Do not use words or short keys as it's a high security risk!
By default, racoon-tool configures racoon to use the pre-shared key file /etc/racoon/psk.txt:
Firewall:~# nano -w /etc/racoon/psk.txt
The format of the file is very simple, the IP address of the remote peer's ISP (external) interface, followed by the key. The key should match between the two peers (and ONLY between two peers!).
On the remote firewall:
10.1.1.1 G9KuwsuiuBHGu92S7AC4eKHt5dnpL8548Q46Rdiuke9zCb8U
On the local firewall:
10.100.100.1 G9KuwsuiuBHGu92S7AC4eKHt5dnpL8548Q46Rdiuke9zCb8U
That's the end of our racoon configuration. Now we have to "reload" the tool. Racoon-tool will parse the config, and generate configuration files for the underlying IPSec apps:
Firewall:~# /etc/init.d/racoon reload
If you've made any invalid entries, racoon-tool should tell you. Even though IPSec is now configured, we can't quite start our connection yet. First we have to configure our firewall to allow the IPSec traffic through.
First we have to add a new zone called "VPN" to shorewall:
Firewall:~# nano -w /etc/shorewall/zones
vpn VPN VPN to remote network
Now we have to define an IPSec tunnel using the /etc/shorewall/tunnels file. Remember to use the remote IP address as the gateway:
Firewall:~# nano -w /etc/shorewall/tunnels
ipsec net 10.100.100.1
Now we have to define the vpn zone as a sub-section of the net zone (since they use the same physical interface on the firewall). We do this by identifying the interface the VPN traffic comes in on (our ISP interface), and the subnet the remote network is using. This way when the firewall sees traffic coming in on our ISP interface using the remote LAN subnet, we classify it as part of the VPN zone.
Firewall:~# nano -w /etc/shorewall/hosts
vpn eth0:192.168.100.1
We also need to exclude our remote subnet from being translated as NAT/PAT traffic as it leaves the external interface. The VPN creates an exception where we want our internal IP addresses to remain intact as they leave the firewall, rather than being converted to external addresses. We only have to add on to our original masq config, this is not a new line:
Firewall:~# nano -w /etc/shorewall/masq
eth0 eth1
becomes
eth0:!192.168.100.0/24 eth1
Last but not least, our policy needs to account for the VPN traffic. As always, you may choose to permit all using the policy, or to restrict the policy and make specific rules for the VPN zone in the rules file. In a corporate environment, a restrictive policy remains best...perhaps you only want to permit access to a specific server over the VPN. In a home environment, you may wish to just permit all VPN traffic. Make sure this setting goes before the net and all statements in the policy.
Firewall:~# nano -w /etc/shorewall/policy
vpn all ACCEPT
That should be the final configuration! Now we have to restart shorewall to take the new configs, followed by starting racoon to begin our IPSec connection:
Firewall:~# /etc/init.d/shorewall restart
Firewall:~# /etc/init.d/racoon start
The best way to test is to send some simple traffic between the local and remote LANs. Try pinging a remote computer or accessing a remote service. Since there was a lot of room for error here, there's a good chance you may have a problem. If traffic fails to cross successfully, there are two good places to search for errors. /var/log/syslog will show you any errors with racoon. Check closely for errors negotiating the IPSec link. Also, check the firewall logs for dropped traffic from the remote network. If you see this, the firewall is still blocking your incoming VPN traffic and needs to be adjusted.
One last important note: Traffic that relies on broadcast will not work over the VPN link. Typing "ping [computer name]" will fail; you must use "ping [ip address]". This is because broadcast traffic only works within your local subnet, and the remote VPN is on a different subnet. To be able to use hostnames across the VPN link you will need to use a local DNS or WINS server to resolve the names.
|
|
|
|
|
|
Proceed to Step 14 - Intrusion Detection (IDS) |
|
|
|
|
|
|
|
