Skip to main content

VPN – asymmetric traffic

Recently I worked on one problem related with asymmetric VPN traffic. It was caused by misconfiguration of encryption domain. We fixed the problem and I would like to document the scenario. My previous post is about my first python script which helped to find issues, more details here.

This is a scenario I will work with:



[rA]g0/1-------g0/2[asaC]g0/1-----------g0/1[asaD]g0/2-------g0/1[rB]

                      |      VPN TUNNEL       |
                       ========================

10.1.0.2 -  10.1.0.1[ ]10.0.0.1       10.0.0.2[ ]10.2.0.1 - 10.2.0.2

LAN1:                                                          LAN2:
10.1.1.0/24                                              10.2.1.0/24
10.1.2.0/24                                              10.2.2.0/24
 
 
 
 
Traffic from 10.1.1.0/24 and 10.1.2.0/24 should go through VPN tunnel set up between two ASAs: ‘asaC’ and ‘asaD’

This is an access list I created. They were implemented in the same way (order too!). As you see there are many overlapping entries (host are overlapped by subnets, subnets are overlapped by another subnets):


 
object network 10.1.2.1
 host 10.1.2.1
object network 10.1.2.0_24
 subnet 10.1.2.0 255.255.255.0
object network 10.1.0.0_16
 subnet 10.1.0.0 255.255.0.0

object network 10.2.2.1
 host 10.2.2.1
object network 10.2.2.0_24
 subnet 10.2.2.0 255.255.255.0
object network 10.2.0.0_16
 subnet 10.2.0.0 255.255.0.0

object-group network LAN1
 network-object host 10.1.1.1
 network-object 10.1.1.0 255.255.255.0
 network-object object 10.1.2.1
 network-object object 10.1.2.0_24
 network-object object 10.1.0.0_16

object-group network LAN2
 network-object host 10.2.1.1
 network-object 10.2.1.0 255.255.255.0
 network-object object 10.2.2.1
 network-object object 10.2.2.0_24
 network-object object 10.2.0.0_16
 
 
The only one difference is the order:

on asaC there is:

 access-list ACL extended permit ip object-group LAN1 object-group LAN2
 
on asaD:
 
 
access-list ACL extended permit ip object-group LAN2 object-group LAN1 
 

With above configuration VPN works fine.

When on one end (asaC) the order of access list is changed, for example ‘network-object host 10.1.1.1’ is moved as last item in ‘object-group network LAN1’ we can see asymmetric traffic:


object-group network LAN1
 network-object 10.1.1.0 255.255.255.0
 network-object object 10.1.2.1
 network-object object 10.1.2.0_24
 network-object object 10.1.0.0_16
 network-object host 10.1.1.1      <- this one was moved from first position
 
 
Traffic is sent from router A and it can’t pass through:
 
 
rA#ping 10.2.1.1 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
.....
Success rate is 0 percent (0/5)
rA#
 
 
On asaC we can see SA between: 10.1.1.0/24 and 10.2.1.1/32 (first match) but traffic goes only in one direction (4 encaps and 0 decaps packets)
 
 
asaC# sh crypto ipsec sa
interface: outside
 Crypto map tag: CM, seq num: 1, local addr: 10.0.0.1

access-list ACL extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1
 local ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
 remote ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/0/0)
 current_peer: 10.0.0.2




#pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4
 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
 
 
ACL is processed top-down and first one which matches the source and destination IPs is:
 
 
asaC# sh access-list ACL
access-list ACL; 25 elements; name hash: 0xdd71d952
access-list ACL line 1 extended permit ip object-group LAN1 object-group LAN2 (hitcnt=3) 0x6d84ee8e
 access-list ACL line 1 extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1 (hitcnt=3) 0x2baae81e
 access-list ACL line 1 extended permit ip 10.1.1.0 255.255.255.0 10.2.1.0 255.255.255.0 (hitcnt=0) 0x847a74cc
 
 
On asaD: 10.2.1.1/32 and 10.1.1.0 as well
 
 
asaD# sh crypto ipsec sa
interface: outside
 Crypto map tag: CM, seq num: 1, local addr: 10.0.0.2

access-list ACL extended permit ip host 10.2.1.1 10.1.1.0 255.255.255.0
 local ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/0/0)
 remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
 current_peer: 10.0.0.1




#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
 
 
 
but looking at ACL counters we can see the problem. The traffic matches different entry (host – host) which was taken as a first match (top down search):
 
 
asaD# sh access-list ACL
access-list ACL; 25 elements; name hash: 0xdd71d952
access-list ACL line 1 extended permit ip object-group LAN2 object-group LAN1 (hitcnt=4) 0x895799c9
 access-list ACL line 1 extended permit ip host 10.2.1.1 host 10.1.1.1 (hitcnt=4) 0x308a3f4d
 access-list ACL line 1 extended permit ip host 10.2.1.1 10.1.1.0 255.255.255.0 (hitcnt=1) 0x439f8c91
 
 
When we change direction and now router B initiate traffic it looks fine:
Router B:


rB#ping 10.1.1.1 source 10.2.1.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:

Packet sent with a source address of 10.2.1.1

.!!!!

Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/1 ms

rB#
 
 
 
SA is defined by ACL entry: host – host (10.2.1.1-10.1.1.1)
 
 
 
asaD# sh crypto ipsec sa

interface: outside

    Crypto map tag: CM, seq num: 1, local addr: 10.0.0.2




      access-list ACL extended permit ip host 10.2.1.1 host 10.1.1.1

      local ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/0/0)

      current_peer: 10.0.0.1







      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
 
 
 
 
what is the first match:
 
  
 
 
asaD# sh access-list ACL

access-list ACL; 25 elements; name hash: 0xdd71d952

access-list ACL line 1 extended permit ip object-group LAN2 object-group LAN1 (hitcnt=3) 0x895799c9

  access-list ACL line 1 extended permit ip host 10.2.1.1 host 10.1.1.1 (hitcnt=3) 0x308a3f4d
 
 
 
 
On asaC SA is created based on ACL: network-host (10.1.1.0/24 and 10.2.1.2):
 
 
 
 
asaC# sh crypto ipsec sa

interface: outside

    Crypto map tag: CM, seq num: 1, local addr: 10.0.0.1




      access-list ACL extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1

      local ident (addr/mask/prot/port): (10.1.1.1/255.255.255.255/0/0)

      remote ident (addr/mask/prot/port): (10.2.1.1/255.255.255.255/0/0)

      current_peer: 10.0.0.2







      #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4

      #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4
 
 
 
and the same ACL has hits:
 
 
asaC# sh access-list ACL

access-list ACL; 25 elements; name hash: 0xdd71d952

access-list ACL line 1 extended permit ip object-group LAN1 object-group LAN2 (hitcnt=1) 0x6d84ee8e

  access-list ACL line 1 extended permit ip 10.1.1.0 255.255.255.0 host 10.2.1.1 (hitcnt=1) 0x2baae81e
 
 
 
The 2nd scenario also contains differences between devices but traffic can pass through. Definition of encryption domain can’t contain any overlapping entries. When the same IP is matched by more than one entry it may cause problem like this described above. Traffic from right to left (rB->rA) can’t pass through but from right to left (rA->rB) can. All access lists should be reviewed and modified if necessary. To speed the process of reviewing ACLs I wrote a script in python which automate the reviewing process.
 
Labels:

Comments

Post a Comment

Popular posts from this blog

What should you know about HA 'override enabled' setting on Fortigate?

High availability is mandatory in most of today's network designs. Only very small companies or branches can run their business without redundancy. When you have Fortigate firewall in your network you have many options to increase network availability. You can use Fortigate Clustering Protocol ( FGCP ) or Virtual Router Redundancy Protocol ( VRRP ). FGCP has two modes: 'override' disabled (default) and 'override' enabled . I'm not going to explain how to set up HA as you can find many resources on Fortinet websites: https://cookbook.fortinet.com/high-availability-two-fortigates-56/ https://cookbook.fortinet.com/high-availability-with-fgcp-56/ Let's recap what is the main difference between them. The default HA setting is 'override' disabled and this is an order of selection an active unit: 1) number of monitored interfaces - when both units have the same number of working (up) interfaces check next parameter 2) HA uptime - an ...
8 comments
Read more

FortiGate and GRE tunnel

Recently I worked on one project where a client requested to re-route web traffic to the GRE tunnel to perform traffic inspection. I would like to share with you what is required if you configure it on FortiGate. We need a new GRE interface and policy base routing (PBR) to change the route for specific source IPs. Of course you need firewall policies to permit the traffic. Let's start with GRE interface. Unfortunately you can't configure it using the GUI, only CLI is the option: config system gre-tunnel edit "gre1" set interface "port1" set local-gw 55.55.55.55 set remote-gw 44.44.44.44 next end When the end peer is Cisco router, you need to set the IP for the GRE interface: config system interface edit gre1 set ip 192.168.10.10 255.255.255.255 set remote-ip192.168.10.20 end In next step we need to fix routing. We need the alternate path via GRE but to keep the route in the active routing table you need to set the same AD (adminis...
Post a Comment
Read more

Inpection of asymmetric sessions on FortiGate

There is one feature available on FortiGate, and I think you should know it, as it modifies a bit what we know about stateful firewalls. In past every packet was treated individually and you had to create policies in both directions. With stateful firewalls we can track connections, and by checking couple of attributes, we can treat them as part of the same session. For example when you initiate connection from a host1 to host2, the returning connection from host2 to host1 will be treated as part of the same connection (session). They have to have the same source/destination and destination/source IPs, port numbers and interfaces.There is an exception from this rule and FortiGate in some specific cases can accept connections on port which was not used in the initial connection. Let me explain how it works on the below example:      The host1 has a default gateway on R1 (10.0.1.2), but you may notice that it is not the optimal path to host2 subnet. When we analyze ...
1 comment
Read more