Dealing with Firewalls

Vendors tend to promote 'IPsec Passthrough' as an important feature of their device. However, it really means that their device does not actually have an IPsec stack, and instead will mangle IPsec traffic that passes through the device, that should have been left untouched to properly work. If you can't disable this feature, avoid the device entirely!

You can not use IPsec passthrough and NAT-T between two peers at the same time. If you attempt this, you will see a message similar to the following in your log files:

Mar 18 18:29:42 gateway pluto[5096]: "nat_demo"[17] 192.168.89.10 #31: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work.

Mar 18 18:30:47 gateway pluto[5096]: "nat_demo"[17] 192.168.89.10 #32: Warning: peer is NATed but source port is still udp/500. Ipsec-passthrough NAT device suspected -- NAT-T may not work.

If NAT-T is enabled on your IPsec peers, you must disable IPsec passthrough on any NAT device between them.

Configuring the Firewall on the Openswan Host

No matter which kernel stack is used, you still need to permit IPsec traffic in and out of the Openswan host. This portion of the firewall configuration is the same for KLIPS and NETKEY. Note that it is slightly different from the table listed earlier, and now uses the INPUT/OUTPUT tables instead of the FORWARD table:

#Firewall Configuration to allow IPsec traffic to be

#sent and received by this server.

iptables -I INPUT -s 193.111.228.1 -d 205.150.200.209 -p udp --dport 500 -j ACCEPT

iptables -I OUTPUT -s 205.150.200.209 -d 193.111.228.1 -p udp --dport 500 -j ACCEPT

iptables -I INPUT -s 193.111.228.1 -d 205.150.200.209 -p udp --dport 4500 -j ACCEPT

iptables -I OUTPUT -s 205.150.200.209 -d 193.111.228.1 -p udp --dport 4500 -j ACCEPT

iptables -I INPUT -s 193.111.228.1 -d 205.150.200.209 -p 50 -j ACCEPT iptables -I OUTPUT -s 205.150.200.209 -d 193.111.228.1 -p 50 -j ACCEPT

These iptables commands are basic—you can further narrow down traffic by adding additional filtering commands, such as -i eth0, to specify that the packet must come in via your external interface eth0. The rules for ESP packets appear last, using an insert (-I) command. This causes them to appear at the top of the list, which is useful, since there will be many more ESP packets than IKE packets. They will be matched immediately, instead of traveling down the ruleset before getting accepted.

Although NATed IKE packets are sent out with a source port of 500 or 4500, these source ports might be changed by a NAT router in transit that needs to map many machines onto its own ports. Therefore you should not only allow port 500 to 500 and 4500 to 4500 packets, but all packets to and from port 500 and 4500, as in our example above.

150

Chapter 7

One last reminder about firewall rules on your IPSec peer. If your peer is doing NAT itself (as is common in many Linux installations), you will need to exclude traffic for your IPsec tunnels from being NATed. We covered this in Chapter 4, but here it is again. This example assumes that your local network is 192.168.0.0/24, and that the remote side is 192.168.1.0/24—so you need to exclude the traffic destined for 192.168.1.0/24 from being NATed before it becomes encrypted:

iptables -t nat -I POSTROUTING -s 192.168.0.0/24 -d \! 192.168.1.0/24 -o eth0 -j MASQUERADE

Firewalling and KLIPS

When using KLIPS, there is an ipsecX device for each IPsec tunnel, which greatly simplifies the writing of firewall rulesets. When dealing with ipsecX devices, any traffic coming in from the virtual device has already been decrypted and checked by the KLIPS policies, so you can assume it is genuine traffic from the remote peer. Whether it is safe to forward to your network might also depend on the trust you have in that peer. Note that traffic flow with KLIPS is:

Where * denotes where the packet passes through the iptables FORWARD chain. So you can permit all traffic that comes in over the VPN with a single iptables rule:

iptables -I FORWARD -i ipsec0 -j ACCEPT

Another example shows how to only allow POP3 traffic (on TCP port 110) that comes in from a trusted VPN connection, but not from the Internet:

iptables -I FORWARD -i ipsec0 -p tcp --dport 110 -j ACCEPT iptables -I FORWARD -i eth0 -p tcp --dport 110 -j DROP

If your default policy for eth0 is to drop unmatched packets, you can even leave out the last rule.

Firewalling and NETKEY

IP firewalling when using NETKEY is quite different, as there are no ipsecX devices to easily identify IPsec traffic. Furthermore, this part of the networking code is under heavy development at the moment. At the time of writing (Linux 2.6.15), IPsec packets still appear to iptables in strange inconsistent ways. We see incoming encrypted packets and incoming plaintext packets, but there is no relationship between the two that we can observe. Some encrypted packets will cause plaintext packets to appear, others might not. And some plaintext packets might have arrived in plaintext to begin with.

Some packets might get killed by the built-in rp_filter anti-spoof protection if that is not disabled in /etc/sysctl.conf. You would expect a strict separation for encrypted packets to appear in the INPUT/OUTPUT tables, and the decrypted packets to go through the FORWARD table, but it is not that easy. There are patches by Patrick McHardy in the netfilter patch-o-matic to make the packets hit the iptables before and after encryption, but they have not been merged into the mainstream kernel yet. The patches can be found at http://www.netfilter.org/patch- o-matic/pom-extra.html. To accomplish the same as the secure POP rules above for KLIPS, you have to use the FWMARK facility of iptables. You can have the kernel mark IPsec packets.

151

Dealing with Firewalls

This mark stays on the packet even after it has been decrypted. And since only the kernel, meaning you, can mark packets—it is not a state for packets on the network—you can distinguish plaintext traffic from decrypted traffic if you mark the encrypted traffic first:

iptables -t mangle -A PREROUTING -i eth0

-p esp

-j MARK --

set-mark

1

iptables -I INPUT -i eth0 -m mark --

mark

1

-p tcp --

dport

110 -j ACCEPT

iptables -I

FORWARD

-i

eth0

-m

mark

--mark

1 -p

tcp

--dport 110 -j

ACCEPT

iptables -A

FORWARD

-i

eth0

-p

tcp --

dport

110 -j DROP

Alternatively you can split firewalling up for the two ethernet cards. On the external interface you drop port TCP 110, but accept IPsec traffic, and on the internal interface, you allow TCP port 110.

Packet Size

The MTU (Maximum Transmission Unit) size of packets can become a problem, as larger packets may be fragmented when being put into the IPsec tunnel. Also, a device somewhere between the IPsec peers might be silently fragmenting the packets, which, coupled with devices that cannot or will not reassemble the fragmented packets, leads to loss of communication.

Symptoms of this manifest themselves most commonly when loading a single web page is OK, but following any link on the website fails, or when you can log in via SSH, but issuing ls -al in a large directory seems to hang. Any situation where the initial connection works, but all subsequent data gets stuck, is usually an indicator of a packet size problem.

The issue is packet fragmentation—a device somewhere between the two peers is breaking the packets into two or more fragments. While a difficult problem to diagnose, it is not too hard to fix. If you are using KLIPS, simply add the following line to the config setup section of your

ipsec.conf:

overridemtu=1419

This changes the MTU setting on the ipsecX interface. You can also do this manually by issuing the command:

ifconfig ipsec0 mtu 1419

We suggest starting with 1419, as IPsec encapsulated inside UDP using AES adds about 70-80 bytes of overhead to the packet, so by limiting packets to 1419 bytes, we stay inside the 1500 byte limit.

Note: the MTU of the ipsecX interfaces defaults to 16260 bytes. This is so that the ipsecX device can accept packets from any phyiscal media (Ethernet, Token Ring, ATM, etc.) and fragment properly.

Using NETKEY, you must either adjust the MTU of the outer interface:

ifconfig eth0 mtu 1440

or add in specific routes and specify the MTU for the route:

ip route replace 192.112.90.50 via 193.111.228.1 dev eth0 mtu 1440

152