IPSEC policy match wrong tunnel

126 0 1 0

We have two tunnels set up, one for forwarding the traffic to 10.195.X.X/16 and the other tunnel should forward the traffic to 10.195.X.X/32 which is included in the range from the first tunnel, and when the traffic should go through the second tunnel is going only on the first one. Different ACL's were set up for this scenario as follows :

MAIN tunnel:

IPsec policy XX 1 isakmp

security acl 3000

ike-peer XX

proposal XX

tunnel local XX

 

SPECIFIC TUNNEL

ipsec policy XX 2 isakmp

security acl 3001

ike-peer XX

proposal XX

tunnel local XX


MAIN ACL

acl number 3000

rule 10 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0.0.255.255


SPECIFIC ACL

acl number 3001

rule 5 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0


Since the second IP /32 is already included in the first one, /16, it will always match the first ACL resulting in matching the first tunnel.


There was an attempt to block the traffic for the first tunnel with the hope that it will go on the second one :


MAIN ACL

acl number 3000

rule 5 deny ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0 

rule 10 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0.0.255.255


After this was made the traffic would not work at all, because it will match the deny policy and it will not work at all anymore.


The solution is as it follows :


For this to be done and to work properly a change to the IPSec policy ISAKMP  sequence must be changed between them and the logic is as follows.


MAIN tunnel:

ipsec policy XX 2 isakmp

security acl 3000

ike-peer XX

proposal XX

tunnel local XX

 

SPECIFIC TUNNEL

ipsec policy XX 1 isakmp

security acl 3001

ike-peer XX

proposal XX

tunnel local XX


MAIN ACL

acl number 3000

rule 10 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0.0.255.255


SPECIFIC ACL

acl number 3001

rule 5 permit ip source 10.190.X.X 0.0.255.255 destination 10.195.X.X 0


The logic is that the traffic is clearly matching the first tunnel because the /32 IP is already included in the /16, so it will match and not proceed to the next SEQUENCE.

If we deny from the first ACL that IP on the first sequence, again it will match and will not proceed on the next SEQUENCE


If we change the SEQUENCE between them as shown before, on the ACL it will be permitted only the specific IP /32, the other IPs from the range /16 presented will not, so will get to the next SEQUENCE and match the ACL there.


If any match will be done on a specific ACL from an ISAKMP sequence, it will not proceed to the next sequence.

  • x
  • convention:

Comment

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