[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap

Latest reply: Nov 8, 2016 15:51:06 2289 2 1 1

With IPSec VPNs, there are lots of special features when it comes to security policy configurations; not only will it allow firewall traffic traversal, but it will also allow for IPSec protocol packets. This section is designed to teach us all about the precise security policy configuration methods for IPSec VPNs.

1 IKE/IPSec VPN Scenarios

As shown in Figure 1-1, an IPSec tunnel is established between host FW_A and sub-host FW_B so that PC_A and PC_B can interact through the IPSec tunnel. Suppose that FW_A and FW_B connect to a private network through the GE0/0/1 interface; this is the trust zone; when connecting to the Internet through the GE0/0/2 interface, this is the untrust zone.

Figure 1-1 IKE/IPSec networking

[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap-1285961-1

 

The security policy configuration process is as follows:

2.         First configure the broadest domain security policy to commission the IPSec.

Set the FW_A domain default packet filtering to permit:

[FW_A] firewall packet-filter default permit all

Set the FW_B domain default packet filtering to permit:

 [FW_A] firewall packet-filter default permit all

3.         Once the IPSec is configured on the firewalls, PC_A will initiate access to PC_B; by ***yzing the firewall session table, we can obtain the security policy match conditions.

l   Host FW_A session table

[FW_A] display firewall session table verbose

 Current Total Sessions: 3

 udp VPN: public --> public

 Zone: local--> untrust TTL: 00: 02: 00 Left: 00: 00: 55

 Interface: GigabitEthernet0/0/2 NextHop: 1.1.1.2 MAC: 00-e0-fc-e4-65-58

 <--packets: 4 bytes: 692 -->packets: 6 bytes: 944

 1.1.1.1: 500-->2.2.3.2: 500 //Corresponds to ISAKMP negotiation packet, port 500

 

 icmp VPN: public --> public

 Zone: trust--> untrust TTL: 00: 00: 20 Left: 00: 00: 16

 Interface: GigabitEthernet0/0/2 NextHop: 1.1.1.2 MAC: 00-e0-fc-e4-65-58

 <--packets: 0 bytes: 0 -->packets: 1 bytes: 60

 192.168.0.2: 14235-->172.16.2.2: 2048 //Corresponds to original IP packets

 

 esp VPN: public --> public

 Zone: untrust--> local TTL: 00: 10: 00 Left: 00: 09: 59

 Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00

 <--packets: 0 bytes: 0 -->packets: 2 bytes: 224

 2.2.3.2: 0-->1.1.1.1: 0 //Corresponds to IPSec packets. If AH and ESP encapsulation are both configured, there will be two sessions.

There's a strange phenomenon herein; the session direction that corresponds to host FW_A sending an ESP packet is untrust-->local (2.2.3.2: 0―>1.1.1.0); on the table, there seems to be an inconsistency with the session direction when FW_A receives ESP packets. Why is that? It turns out that when FW_A sends the encrypted ESP packet, it does not establish a session and so it does not go through the firewall forwarding process; naturally, it won't check the security policy either. However, when the firewall receives the ESP packet for encryption, it must first establish a session for the forwarding process and check the security policy; as we can see, this session corresponds to an ESP packet receipt. Whether ISAKMP negotiation packets are sent or received, the forwarding process must be performed both times, so this issue does not occur.

By ***yzing the session table we can obtain the FW_A packet path, as shown in Figure 1-2.

Figure 1-2 Host FW_A packet path

[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap-1285961-2 

As can be seen in the figure above, FW_A must configure the trust zone--->untrust zone security policy to allow PC_A to PC_B access packets to go through; it must also configure the local zone--->untrust zone security policy to allow ISAKMP negotiation packets to go through; an untrust zone--->local zone security policy must also be configured to allow ESP packets to go through.

l   Sub-host FW_B session table

[FW_B] display firewall session table verbose

 Current Total Sessions: 3

 udp VPN: public --> public

 Zone: untrust--> local TTL: 00: 02: 00 Left: 00: 00: 36

 Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00

 <--packets: 1 bytes: 200 -->packets: 2 bytes: 280

 1.1.1.1: 500-->2.2.3.2: 500

 

 esp VPN: public --> public

 Zone: untrust--> local TTL: 00: 10: 00 Left: 00: 09: 59

 Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00

 <--packets: 0 bytes: 0 -->packets: 4 bytes: 448

 1.1.1.1: 0-->2.2.3.2: 0

 

 icmp VPN: public --> public

 Zone: untrust--> trust TTL: 00: 00: 20 Left: 00: 00: 16

 Interface: GigabitEthernet0/0/1 NextHop: 172.16.2.2 MAC: 54-89-98-39-60-e2

 <--packets: 1 bytes: 60 -->packets: 1 bytes: 60

 192.168.0.2: 61095-->172.16.2.2: 2048

By ***yzing the session table, we can obtain the FW_B packet path, as shown in Figure 1-3.

Figure 1-3 Sub-Host FW_B packet path

[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap-1285961-3 

As can be seen in the figure above, FW_B must configure an untrust zone--->trust zone security policy to allow PC_A to PC_B access packets to go through; it must also configure an untrust zone--->local zone security policy to allow ISAKMP negotiation packets to go through; an untrust zone--->local zone security policy must also be configured to allow ESP packets to go through.

When PC_B initiates access to PC_A, the packet path is the opposite of the PC_A access path to PC_B, so we don't need to discuss it again.

In conclusion, in the IKE/IPSec scenario, FW_A and FW_B should configure security policy match conditions, as shown in Table 1-1.

Table 1-1 Host and Sub-host FW security policy match conditions

Service Direction

Device

Source Security Zone

Destination Security Zone

Source Address

Destination IP Address

Applications (Protocol+Destination Port)

PC_A access to PC_B

Host FW_A

Untrust

Local

2.2.3.2/32

1.1.1.1/32

AH and/or ESP (ESP for this example)

Local

Untrust

1.1.1.1/32

2.2.3.2/32

UDP+500

Trust

Untrust

192.168.0.0/24

172.16.2.0/24

*

Sub-Host FW_B

Untrust

Local

1.1.1.1/32

2.2.3.2/32

AH and/or ESP (ESP for this example)

UDP+500

Untrust

Trust

192.168.0.0/24

172.16.2.0/24

*

PC_B access to PC_A

Host FW_A

Untrust

Local

2.2.3.2/32

1.1.1.1/32

AH and/or ESP (ESP for this example)

UDP+500

Untrust

Trust

172.16.2.0/24

192.168.0.0/24

*

Sub-Host FW_B

Untrust

Local

1.1.1.1/32

2.2.3.2/32

AH and/or ESP (ESP for this example)

Local

Untrust

1.1.1.1/32

2.2.3.2/32

UDP+500

Trust

Untrust

172.16.2.0/24

192.168.0.0/24

*

*: This depends on the specific service type and can be configured based on the actual situation, e.g. tcp, udp, icmp, etc.

 

NOTE: Manual IPSec VPNs differ from IKE IPSec VPNs in that they do not have an ISAKMP session and as such, there is no need to configure a UDP+500 security policy.

4.         Finally, change the default packet filtering action to deny.

Set the FW_A domain default packet filtering to deny:

[FW_A] firewall packet-filter default deny all

Set the FW_B domain default packet filtering to deny:

[FW_B] firewall packet-filter default deny all

2 IKE/IPSec VPN+NAT Traversal Scenarios

With IKE/IPSec VPN+NAT traversals, the security policy configuration also has several unique characteristics. We'll introduce this characteristic with Scenario 2 from "6.8.1 Overview of NAT Traversal Scenarios".

As shown in Figure 1-4, an IPSec tunnel has been established between host FW_A and sub-host FW_B; there is an NAT device between the two; the post-NAT transformation address is 2.2.2.10 (an address set in the address pool). Suppose that FW_A and FW_B connect to a private network through the GE0/0/1 interface; this is the trust zone; the upstream device connects through the GE0/0/2 interface; this is the untrust zone.

Figure 1-4 IKEv1/IPSec VPN+NAT traversal networking

[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap-1285961-4 

The security policy configuration process is as follows:

5.         First configure the broadest domain security policy to commission the IPSec.

Set the FW_A domain default packet filtering to permit:

[FW_A] firewall packet-filter default permit all

Set the FW_B domain default packet filtering to permit:

[FW_A] firewall packet-filter default permit all

6.         Once the IPSec is configured on the firewalls, PC_B will initiate access to PC_A; by ***yzing the firewall session table, we can obtain the security policy match conditions.

l   Host FW_A session table

<FW_A> display firewall session table verbose

 Current Total Sessions: 3

 udp VPN: public --> public

 Zone: untrust--> local TTL: 00: 02: 00 Left: 00: 01: 52

 Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00

 <--packets: 1 bytes: 296 -->packets: 1 bytes: 296

 2.2.2.10: 2052-->1.1.1.1: 500

 

 udp VPN: public --> public

 Zone: untrust--> local TTL: 00: 02: 00 Left: 00: 01: 58

 Interface: InLoopBack0 NextHop: 127.0.0.1 MAC: 00-00-00-00-00-00

 <--packets: 1 bytes: 228 -->packets: 5 bytes: 740

 2.2.2.10: 2049-->1.1.1.1: 4500

 

 icmp VPN: public --> public

 Zone: untrust--> trust TTL: 00: 00: 20 Left: 00: 00: 14

 Interface: GigabitEthernet0/0/2 NextHop: 192.168.0.2 MAC: 54-89-98-7f-1e-b2

 <--packets: 1 bytes: 60 -->packets: 1 bytes: 60

 172.16.1.2: 34201-->192.168.0.2: 2048

Host FW_A has a total of three sessions: two udp sessions and one icmp session. Of the two udp sessions, one port is 500, and one is 4500; this means that after the IKE detected the NAT gateway, the ISAKMP outer packet added UDP encapsulation, and the negotiation port also switched from 500 to 4500. The subsequently transferred ESP packet also has an added UDP header, so FW_A cannot see the corresponding ESP packet session.

By ***yzing the session table, we can obtain the host FW_A packet path, as shown in Figure 1-5.

Figure 1-5 Host FW_A packet path

[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap-1285961-5 

As can be seen in the figure above, host FW_A must configure an untrust zone--->trust zone security policy to allow PC_B to access PC_A packets; it must also configure an untrust zone--->local zone security policy to allow host FW_A and sub-host FW_B to establish an IPSec tunnel.

l   Sub-host firewall FW_B session table

<FW_B> display firewall session table verbose

 Current Total Sessions: 3

 udp VPN: public --> public

 Zone: local--> untrust TTL: 00: 02: 00 Left: 00: 01: 45

 Interface: GigabitEthernet0/0/2 NextHop: 172.16.0.2 MAC: 00-00-00-d3-84-01

 <--packets: 1 bytes: 296 -->packets: 1 bytes: 296

 172.16.0.1: 500-->1.1.1.1: 500

 

 udp VPN: public --> public

 Zone: local--> untrust TTL: 00: 02: 00 Left: 00: 01: 50

 Interface: GigabitEthernet0/0/2 NextHop: 172.16.0.2 MAC: 00-00-00-d3-84-01

 <--packets: 5 bytes: 708 -->packets: 1 bytes: 260

 172.16.0.1: 4500-->1.1.1.1: 4500

 

 icmp VPN: public --> public

 Zone: trust--> untrust TTL: 00: 00: 20 Left: 00: 00: 07

 Interface: GigabitEthernet0/0/2 NextHop: 10.1.5.1 MAC: 00-00-00-d3-84-01

 <--packets: 1 bytes: 60 -->packets: 1 bytes: 60

 172.16.1.2: 34201-->192.168.0.2: 2048

By ***yzing the session table, we can obtain the sub-host FW_B packet path, as shown in Figure 1-6.

Figure 1-6 Sub-Host FW_B packet path

[Dr.WoW] [No.38] IPSec VPN Security Policy Configuration Roadmap-1285961-6 

As can be seen in the figure above, sub-host FW_B must configure a trust zone--->untrust zone security policy to allow PC_B to PC_A access packets to go through; it must also configure a local zone--->untrust zone security policy to allow host FW_A and sub-host FW_B to establish an IPSec tunnel.

If the NAT device is only configured for source NAT, then this scenario will only allow sub-host FW_B to actively establish an IPSec tunnel with host FW_A. If this is the case, the match conditions for host FW_A and sub-host FW_B security policy configurations are as shown in Table 1-2.

Table 1-2 Host and sub-host fw security policy match conditions

Service Direction

Device

Source Security Zone

Destination Security Zone

Source Address

Destination IP Address

Applications (Protocol+Destination Port)

PC_B access to PC_A

Host FW_A

Untrust

Local

172.16.0.1/32

1.1.1.1/32

UDP+500 and 4500

Untrust

Trust

172.16.1.0/24

192.168.0.0/24

*

Sub-Host FW_B

Local

Untrust

172.16.0.1/32

1.1.1.1/32

UDP+500 and 4500

Trust

Untrust

172.16.1.0/24

192.168.0.0/24

*

*: This depends on the specific service type and can be configured based on the actual situation, e.g. tcp, udp, icmp, etc.

 

If the host has not configured a template IPSec policy and NAT Server is configured on the NAT device, host FW_A is allowed to actively establish an IPSec tunnel with sub-host FW_B; we can summarize the match conditions for this security policy for PC_A access to PC_B based on the method above.

7.         Lastly, change the default packet filtering to deny.

Set the FW_A domain default packet filtering to deny:

[FW_A] firewall packet-filter default deny all

Set the FW_B domain default packet filtering to deny:

[FW_B] firewall packet-filter default deny all

 

 

Questions from Dr. WoW:

1.         Which two encapsulation modes does IPSec support?

2.         Of IPSec's two security protocols AH and ESP, which supports encryption?

3.         Which two identity authentication methods does IKEv1 support?

4.         When establishing an IPSec SA, what differences are there between IKEv1 and IKEv2 in terms of the number of exchange messages sent?

5.         If an NAT gateway device is present in the network in which an IPSec tunnel is established between two firewalls, what should be done in terms of the AH and ESP security protocols?

6.         Which two IKE peer detection functions do firewalls support?

7.         In the GRE over IPSec scenario, when the IPSec defines the ACL, should the original packet source and destination IP address be used or should the GRE encapsulated source and destination IP address be used?

 

 

 

 

To view the list of all Dr. WoW technical posts, click here.

  • x
  • convention:

user_2790689
Created Sep 17, 2015 07:17:19 Helpful(0) Helpful(0)

Good.
  • x
  • convention:

CippaLippa
Created Nov 8, 2016 15:51:04 Helpful(0) Helpful(0)

Nice
  • x
  • convention:

Reply

Reply
You need to log in to reply to the post Login | Register

Notice Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " Privacy."
If the attachment button is not available, update the Adobe Flash Player to the latest version!
Login and enjoy all the member benefits

Login and enjoy all the member benefits

Login