Dealing with Firewalls
There is much debate among security experts about how and where to firewall traffic. The old theory of putting a firewall on the perimeter and considering all internal traffic trusted has changed over the past few years. More often these days, software firewalls are also installed on hosts that need special protection. IPsec makes the old secure perimeter model even more difficult, since the outer firewall cannot decrypt the packets for further inspection. It has to make a decision without being able to read the content of the packets, meaning they can't always be trusted.
It is best to protect your IPsec gateway with some form of packet filtering. But since most packets the IPsec gateway receives will be encrypted, there is not much a firewall in front of it can do, since it cannot do any application-level firewalling as it cannot read the encrypted packets. At most, a firewall in front of the IPsec gateway can perform basic packet filtering. For simple packet filtering you do not need a fully fledged stateful application firewall—it can easily be done by the router in front of the IPsec gateway, since almost all modern routers can perform basic packet filtering.
More advanced packet filtering can be performed on the IPsec gateway itself, using host-based rules. With a Linux machine, you can combine iptables with Openswan to provide both packet filtering and IPsec capabilities. Such host-based firewalling is becoming more common, as most firewall vendors are now shipping IPsec stacks built into the firewall, so those IPsec devices have packet filtering available.
A further variation is to place a firewall on the inside of the network, between the IPsec gateway and the internal network. This allows the firewall to inspect traffic after it has been decrypted by the IPsec gateway, ensuring all policies are enforced.
We'll cover how to set up these types of configurations, and provide sample iptables rules for each.
Allowing IPsec Traffic
Chapter 2 explains in detail the IPsec protocols used to permit secure communication between hosts. From the firewall perspective, this comes down to:
Protocol |
Port |
Description |
|
|
|
ESP (50) |
N/A |
ESP (Encrypted Secure Payload) |
AH (51) |
N/A |
AH (Authentication Header) |
UDP (17) |
500 |
IKE |
UDP (17) |
4500 / high port |
IKE, ESPinUDP encapsulation |
|
|
|
Note that ESP is protocol 50, not port 50!
148
Chapter 7
For IPsec to establish a full tunnel, you will need to permit both ESP and UDP port 500 traffic between peers. If you have IPsec peers behind NAT devices, you will also need to permit UDP port 4500, which is used by both IKE and ESPinUDP encapsulation to pass through the NAT device. Authentication Header (AH) is rarely used these days. It only provides authentication without encryption, and has come under recent attack by crypto experts as a possible vulnerability in the IPsec specification.
The rules that need to be added to the firewall rules to allow IPsec packets are shown below:
#Firewall Configuration to allow IPsec traffic to pass
#from a remote IPsec server (193.111.228.1) to our local
#IPsec server (12.110.110.204)
iptables -I FORWARD -s 193.111.228.1 -d 12.110.110.204 -p udp --dport 500 -j ACCEPT
iptables -I FORWARD -s 12.110.110.204 -d 193.111.228.1 -p udp --dport 500 -j ACCEPT
iptables -I FORWARD -s 193.111.228.1 -d 12.110.110.204 -p udp --dport 4500 -j ACCEPT
iptables -I FORWARD -s 12.110.110.204 -d 193.111.228.1 -p udp --dport 4500 -j ACCEPT
iptables -I FORWARD -s 193.111.228.1 -d 12.110.110.204 -p 50 -j ACCEPT iptables -I FORWARD -s 12.110.110.204 -d 193.111.228.1 -p 50 -j ACCEPT
For a firewall that does not do NAT, this is all that is required to permit the two IPsec peers to establish any number of tunnels between them.
NAT and IPsec Passthrough
The IPsec protocols rely on traffic passing unchanged by intermediary devices, such as routers and firewalls. If a device changes the contents of packets (IP addresses, ports, checksums, and so on) as they pass between two IPsec peers, then the packet's cryptographic signature will no longer be correct and the packet will be rejected by the receiving peer.
This makes it difficult for NAT and IPsec to work properly together. The IETF IPsec Working Group identified this as a problem and wrote several drafts and RFCs to resolve the problem. The collection of drafts is known as NAT Traversal, or NAT-T, and they describe how two IPsec
endpoints can determine if there is a NAT device between them, and how to deal with the situation.
During the IKE negotiation, if a peer can do NAT-T, it indicates this capability by adding VendorID information for each IETF NAT proposal it supports to the initiator. The responder also advertises its NAT-T capabilities via VendorID.
If both sites support a common proposal, the two sides send each other their real IP addresses, and then compare that with the header information in the IKE packets they have been receiving from the other end. If there is a mismatch, then whichever side detects the mismatch informs the other side that there is a NAT device in the path. The two sides then encapsulate outgoing ESP packets within UDP packets, using port 4500 (depending on the proposal), to complete the IKE negotiation.
IPsec passthrough (sometimes called VPN passthrough) was a kludge pre-dating the NAT Traversal proposals, and is performed by the NAT device itself without an understanding of the IPsec protocol at all. The NAT device tries to correlate IPsec traffic that is passed through it, and tweak the NAT accordingly. Usually these devices have a limit as to how many IPsec devices they can handle—many are limited to only a single host behind the NAT device. Unfortunately, IPsec passthrough breaks NAT Traversal.
149