10.1.1.1/24 10.1.1.5 Untrust Zone Internet VPN1 Trust Zone Untrust Zone Tokyo LAN Paris LAN Trust Zone Tokyo Office ethernet1 ethernet1 10.2.2.1/24
Outgoing Interface: ethernet3, 1.1.1.1/24 External Router: 1.1.1.250
tunnel.1, 10.1.2.1/24
tunnel.2, 10.2.1.1/24 Outgoing Interface: ethernet3, 2.2.2.2/24
External Router: 2.2.2.250
Paris Office
The path of a packet coming from 10.1.1.5/32 in the Tokyo LAN and going to 10.2.2.5/32 in the Paris LAN through an IPsec tunnel proceeds as described in the following subsections.
Tokyo (Initiator)
1. The host at 10.1.1.5 sends a packet destined for 10.2.2.5 to 10.1.1.1, which is the IP address ethernet1 and is the default gateway configured in the TCP/IP settings of host.
2. The packet arrives at ethernet1, which is bound to the Trust zone.
3. If you have enabled SCREEN options such as IP spoof detection for the Trust zone, the security device activates the SCREEN module at this point. SCREEN checking can produce one of the following three results:
• If a SCREEN mechanism detects anomalous behavior for which it is configured to block the packet, the security device drops the packet and makes an entry in the event log.
• If a SCREEN mechanism detects anomalous behavior for which it is configured to record the event but not block the packet, the security device records the event in the SCREEN counters list for ethernet1 and proceeds to the next step.
• If the SCREEN mechanisms detect no anomalous behavior, the security device proceeds to the next step.
If you have not enabled any SCREEN options for the Trust zone, the security device immediately proceeds to the next step.
4. The session module performs a session lookup, attempting to match the packet with an existing session.
If the packet does not match an existing session, the security device performs First Packet Processing, a procedure involving the remaining steps.
If the packet matches an existing session, the security device performs Fast Processing, using the information available from the existing session entry to process the packet. Fast Processing bypasses the route and policy lookups because the information generated by the bypassed steps has already been obtained during the processing of the first packet in the session.
5. The address-mapping module checks if a Mapped IP (MIP) configuration uses the destination IP address 10.2.2.5. Because 10.2.2.5 is not used in a MIP configuration, the security device proceeds to the next step. (For information about packet processing when MIPs, VIPs, or destination address translation [NAT-dst] is involved, see Packet Flow for NAT-DST.)
6. To determine the destination zone, the route module does a route lookup for 10.2.2.5. (The route module uses the ingress interface to determine which virtual router to use for the route lookup.) It finds a route entry directing traffic to 10.2.2.5 through the tunnel.1 interface bound to a VPN tunnel named “vpn1”. The tunnel interface is in the Untrust zone. By determining the ingress and egress interfaces, the security device has thereby determined the source and destination zones and can now do a policy lookup.
7. The policy engine does a policy lookup between the Trust and Untrust zones (as determined by the corresponding ingress and egress interfaces). The action specified in the policy matching the source address and zone, destination address and zone, and service is permit.
8. The IPsec module checks if an active Phase 2 security association (SA) exists with the remote peer. The Phase 2 SA check can produce either of the following results:
• If the IPsec module discovers an active Phase 2 SA with that peer, it proceeds to step 10.
• If the IPsec module does not discover an active Phase 2 SA with that peer, it drops the packet and triggers the IKE module.
9. The IKE module checks if an active Phase 1 SA exists with the remote peer. The Phase 1 SA check can produce either of the following results:
• If the IKE module discovers an active Phase 1 SA with the peer, it uses this SA to negotiate a Phase 2 SA.
• If the IKE module does not discover an active Phase 1 SA with that peer, it begins Phase 1 negotiations in main mode, and then Phase 2 negotiations.
10.The IPsec module puts an ESP header and then an outer IP header on the packet. Using the address specified as the outgoing interface, it puts 1.1.1.1 as the source IP address in the outer header. Using the address specified for remote gateway, it puts 2.2.2.2 as the destination IP address in the outer header. Next, it encrypts the packet from the payload to the next header field in the original IP header. Then, it authenticates the packet from the ESP trailer to the ESP header.
11. The security device sends the encrypted and authenticated packet destined for 2.2.2.2 through the outgoing interface (ethernet3) to the external router at 1.1.1.250.
Paris (Recipient)
1. The packet arrives at 2.2.2.2, which is the IP address of ethernet3, an interface bound to the Untrust zone.
2. Using the SPI, destination IP address, and IPsec protocol contained in the outer packet header, the IPsec module attempts to locate an active Phase 2 SA with the initiating peer along with the keys to authenticate and decrypt the packet. The Phase 2 SA check can produce one of the following three results:
• If the IPsec module discovers an active Phase 2 SA with the peer, it proceeds to step 4.
• If the IPsec module does not discover an active Phase 2 SA with the peer but it can match an inactive Phase 2 SA using the source IP address but not the SPI, it drops the packet, makes an event log entry, and sends a notification that it received a bad SPI to the initiating peer.
• If the IPsec module does not discover an active Phase 2 SA with that peer, it drops the packet and triggers the IKE module.
3. The IKE module checks if an active Phase 1 SA exists with the remote peer. The Phase 1 SA check can produce either of the following results:
• If the IKE module discovers an active Phase 1 SA with the peer, it uses this SA to negotiate a Phase 2 SA.
• If the IKE module does not discover an active Phase 1 SA with that peer, it begins Phase 1 negotiations in main mode, and then Phase 2 negotiations.
4. The IPsec module performs an anti-replay check. This check can produce one of two results:
• If the packet fails the anti-replay check, because it detects a sequence number that the security device has already received, the security device drops the packet.
• If the packet passes the anti-replay check, the security device proceeds to the next step.
5. The IPsec module attempts to authenticate the packet. The authentication check can produce one of two results:
• If the packet fails the authentication check, the security device drops the packet.
• If the packet passes the authentication check, the security device proceeds to the next step.
6. Using the Phase 2 SA and keys, the IPsec module decrypts the packet, uncovering its original source address (10.1.1.5) and its ultimate destination (10.2.2.5). It learns that the packet came through vpn1, which is bound to tunnel.1. From this point forward, the security device treats the packet as if its ingress interface is tunnel.1 instead of ethernet3. It also adjusts the anti-replay sliding window at this point.
7. If you have enabled SCREEN options for the Untrust zone, the security device activates the SCREEN module at this point. SCREEN checking can produce one of the following three results:
• If a SCREEN mechanism detects anomalous behavior for which it is configured to block the packet, the security device drops the packet and makes an entry in the event log.
• If a SCREEN mechanism detects anomalous behavior for which it is configured to record the event but not block the packet, the security device records the event in the SCREEN counters list for ethernet3 and proceeds to the next step.
• If the SCREEN mechanisms detect no anomalous behavior, the security device proceeds to the next step.
8. The session module performs a session lookup, attempting to match the packet with an existing session. It then either performs First Packet Processing or Fast Processing. If the packet matches an existing session, the security device performs Fast Processing, using the information available from the existing session entry to process the packet. Fast Processing bypasses all but the last two steps (encrypting the packet and forwarding it) because the information generated by the bypassed steps has already been obtained during the processing of the first packet in the session.
9. The address-mapping module checks if a Mapped IP (MIP) or Virtual IP (VIP) configuration uses the destination IP address 10.2.2.5. Because 10.2.2.5 is not used in a MIP or VIP configuration, the security device proceeds to the next step.
10.The route module first uses the ingress interface to determine the virtual router to use for the route lookup; in this case, the trust-vr. It then performs a route lookup for 10.2.2.5 in the trust-vr and discovers that it is accessed through ethernet1. By determining the ingress interface (tunnel.1) and the egress interface (ethernet1), the security device can thereby determine the source and destination zones. The tunnel.1 interface is bound to the Untrust zone, and ethernet1 is bound to the Trust zone. The security device can now do a policy lookup.
11. The policy engine checks its policy list from the Untrust zone to the Trust zone and finds a policy that grants access.
12.The security device forwards the packet through ethernet1 to its destination at 10.2.2.5.