Specify Which Protocols You Want to Tunnel Using Filtering Rules 144

In order to specify which nodes and protocols will use each tunnel, you will have to configure special filter rules. These rules will be like normal rules (with source, target, protocol, ports and port operations), but they will also have a tunnel ID. So when a packet must be transfered, the IBM Firewall will search the filtering rules. If it matches a rule, and this rule has a specific tunnel ID, the packet will be sent according to the authentication/encryption rules specified in this specific tunnel.

Figure 121 on page 145 shows the configuration that we used in our tests.

Figure 121. Test Network for Secure Tunnels

The test network has two firewalls, protecting the secure networks 9.0.0.0 and 192.168.253.0. Their nonsecure IP addresses are 150.53.104.27 and 200.0.253.180, respectively.

We defined two tunnels between the firewalls. Through tunnel 307 we will send TCP and UDP packets authenticated and encrypted and through tunnel 308 we will send ICMP packets authenticated but not encrypted. Figure 122 shows the tunnel configuration.

Figure 122. Tunnel Configuration for Testing

Following the procedure we described earlier, we first defined the tunnels in F1, exported the definitions, moved them to F2 and imported them there. Next we

defined filtering rules at both ends in order to specify which packets will go through each tunnel.

In order to be able to understand the rules better, we use the symbolic names (FW1 and FW2) instead of the actual IP addresses (150.53.104.27 and

200.0.253.180) in the rules illustrated below.

The filtering rules have to cater for three types of traffic: UDP packets between ports 4001 for the session key update protocol, ESP for encryption of the real data and AH for authentication of the real data.

Figure 123. Protocols Used by Secure Tunnel

For each tunnel, packets come in the clear from the secure side, then they are sent through one of the tunnels, received at the second end of the tunnel and go again in the clear to the final destination.

Figure 124 shows the filter rules that we used in Firewall 1 for the tunnels.

# UDP Packets between Tunnel End Points, for the Session Key Update

permit FW1 0xffffffff FW2 0xffffffff udp eq 4001 eq 4001 nonsecure local outbound f=n permit FW2 0xffffffff FW1 0xffffffff udp eq 4001 eq 4001 nonsecure local inbound f=n

# ESP Packets between Tunnel End Points

permit FW1 0xffffffff FW2 0xffffffff esp any 0 any 0 nonsecure local outbound f=n permit FW2 0xffffffff FW1 0xffffffff esp any 0 any 0 nonsecure local inbound f=n

# AH Packets between Tunnel End Points

permit FW1 0xffffffff FW2 0xffffffff ah any 0 any 0 nonsecure local outbound f=n permit FW2 0xffffffff FW1 0xffffffff ah any 0 any 0 nonsecure local inbound f=n

# ICMP Packets, send them Authenticated but Non Encrypted (Tunnel 308) permit SN1 SM1 SN2 SM2 icmp any 0 any 0 secure both inbound f=n permit SN1 SM1 SN2 SM2 icmp any 0 any 0 nonsecure both outbound f=n t=308

# ICMP Packets, receive them Authenticated but Non Encrypted (Tunnel 308) permit SN2 SM2 SN1 SM1 icmp any 0 any 0 nonsecure both inbound f=n t=308 permit SN2 SM2 SN1 SM1 icmp any 0 any 0 secure both outbound f=n

# Other Packets (TCP, UDP), send them Authenticated and Encrypted (Tunnel 307) permit SN1 SM1 SN2 SM2 all any 0 any 0 secure both inbound f=n

permit SN1 SM1 SN2 SM2 all any 0 any 0 nonsecure both outbound f=n t=307

# Other Packets (TCP, UDP), send them Authenticated and Encrypted (Tunnel 307) permit SN2 SM2 SN1 SM1 all any 0 any 0 nonsecure both inbound f=n t=307 permit SN2 SM2 SN1 SM1 all any 0 any 0 secure both outbound f=n Figure 124. Filter Rules Used on Firewall 1 for the Tunnels

The first pair of rules allows the session key update protocol between the

firewalls. The second pair of rules allows the ESP protocol between the firewalls for encryption of packets. The third pair of rules allows the AH protocol between

the firewalls to authenticate the packets. The fourth pair of rules allows ICMP packets from Secure Network 1 to go to Secure Network 2 through tunnel 308 (they are received in the clear through the secure interface and sent through the tunnel on the nonsecure interface). The fifth pair allows incoming ICMP packets from Secure Network 2 through tunnel 308. The sixth pair allows other IP

packets (TCP, UDP) to be sent from Secure Network 1 to Secure Network 2 using tunnel 307. Finally the seventh pair of rules allows incoming replies from Secure Network 2 through tunnel 307.

The rules for the other end of the tunnel are a mirror image. Figure 125 shows the filter rules that we used in Firewall 1 for the tunnels.

# UDP Packets between Tunnel End Points, for the Session Key Update

permit FW2 0xffffffff FW1 0xffffffff udp eq 4001 eq 4001 nonsecure local outbound f=n permit FW1 0xffffffff FW2 0xffffffff udp eq 4001 eq 4001 nonsecure local inbound f=n

# ESP Packets between Tunnel End Points

permit FW2 0xffffffff FW1 0xffffffff esp any 0 any 0 nonsecure local outbound f=n permit FW1 0xffffffff FW2 0xffffffff esp any 0 any 0 nonsecure local inbound f=n

# AH Packets between Tunnel End Points

permit FW2 0xffffffff FW1 0xffffffff ah any 0 any 0 nonsecure local outbound f=n permit FW1 0xffffffff FW2 0xffffffff ah any 0 any 0 nonsecure local inbound f=n

# ICMP Packets, receive them Authenticated but Non Encrypted (Tunnel 308) permit SN1 SM1 SN2 SM2 icmp any 0 any 0 nonsecure both inbound f=n t=308 permit SN1 SM1 SN2 SM2 icmp any 0 any 0 secure both outbound f=n

# ICMP Packets, send them Authenticated but Non Encrypted (Tunnel 308) permit SN2 SM2 SN1 SM1 icmp any 0 any 0 secure both inbound f=n permit SN2 SM2 SN1 SM1 icmp any 0 any 0 nonsecure both outbound f=n t=308

# Other Packets (TCP, UDP), receive them Authenticated and Encrypted (Tunnel 307) permit SN1 SM1 SN2 SM2 all any 0 any 0 nonsecure both inbound f=n t=307 permit SN1 SM1 SN2 SM2 all any 0 any 0 secure both outbound f=n

# Other Packets (TCP, UDP), send them Authenticated and Encrypted (Tunnel 307) permit SN2 SM2 SN1 SM1 all any 0 any 0 secure both inbound f=n

permit SN2 SM2 SN1 SM1 all any 0 any 0 nonsecure both outbound f=n t=307 Figure 125. Filter Rules Used on Firewall 2 for the Tunnels

7.3.6 Refresh Manual Tunnel When Key Expired

This step is required for manual tunnels only. When the tunnel lifetime is reached, the tunnel will cease operation until it is refreshed. Figure 126 on page 148 shows the VPN Administration screen with an expired manual tunnel.

Figure 126. Re-activating the Secure Tunnel

To refresh the tunnel, simply select the tunnel and click the Activate button.

However, refreshing a tunnel would only re-activate it to an operational state.

The keys used in the tunnel remain the same. To re-establish the tunnel with new session keys, you need to delete the tunnel, and then add a new tunnel with the same tunnel ID and characteristics back into the firewall. After that, you export the new tunnel definition to the tunnel partner. New session keys are stored inside the definition files. Your tunnel partner is also required to delete the existing tunnel and then re-import the new definition.