cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
671
Views
2
Helpful
4
Replies

Different behaviour of policy and route-based VPN between FTD and vASA

I'll start by saying that both VPN tunnels set up correctly, however, I observe different behaviour in certain situations. FTD is the physical devices, while vASA is the image in GNS3. The FTDs are bundled into an HA, while the vASA is a single device. A Route-Based tunnel is established from one vASA to an FTD, and a Policy-Based tunnel is established from another vASA to an FTD. The VPN tunnels are set up over a LAN in a lab environment, I am only using private IP addresses on both sides of the tunnel. I would like to know if this behaviour is normal or if it is an error in my configuration. Configuration is at an end.

Adres IP FTD: 192.168.60.17.
Adres IP vASA (Route-Based): 192.168.61.9
Adres IP vASA (Policy-Based): 192.168.61.12

Topology:
krzysztofmaciejewskiit_0-1740923508250.png

The result of the command: show vpn-sessiondb detail l2l
krzysztofmaciejewskiit_1-1740915300561.png

Differences:
Route-Based:
1. Ping from 192.168.1.2 to 33.33.33.11 - success
2. Ping from 192.168.1.1 to 33.33.33.11 - fail 
3. Ping form 33.33.33.11 to 192.168.1.2 - success
4. Ping form 33.33.33.1 to 192.168.1.2 - success

Policy-Based:
5. Ping from 192.168.2.2 to 33.33.33.11 - success
6. Ping from 192.168.2.1 to 33.33.33.11 - fail
7. Ping from 33.33.33.11 to 192.168.2.2 - success
8. Ping from 33.33.33.1 to 192.168.2.2 - fail

It seems to me that in both cases (AD 2. and AD 6.) it's not a bad thing, because I know that there are mechanisms in ASA and FTD that, for example, I won't be able to ping from an external network to an internal interface, so I expect it works the other way around, i.e. that I won't be able to ping from an interface from an internal interface to an external network.
However, I'm wondering why FTD (33.33.33.1) allows me to ping the host (192.168.1.2) form internal interface for Route-Based VPN, but I can't do it for Policy-Based VPN (look closely AD 4. and AD 8.).
In summary, the ASA does not allow pinging from the internal interface, and FTD only allows it in the case of Route-Based VPN, but I don't know why.

AD 2.                                                                           AD 6.
krzysztofmaciejewskiit_7-1740919463262.pngkrzysztofmaciejewskiit_6-1740919366058.png

As you can see in Route-Based VPN the ping succeeds but Packet Tracer says it should fail.
In Policy-Based VPN the ping fails and Packet Tracer says it should fail.
In both cases when I check "Bypass security checks for the simulated packet" the ping is successful.

AD 4.
                                                                            AD 8.
krzysztofmaciejewskiit_0-1740922267079.pngkrzysztofmaciejewskiit_0-1740921643660.pngkrzysztofmaciejewskiit_1-1740921679867.pngkrzysztofmaciejewskiit_2-1740921716065.png

Route-Based configuration:
interface GigabitEthernet0/0
 nameif OUTSIDE
 security-level 10
 ip address 192.168.61.9 255.255.255.0
!
interface GigabitEthernet0/1
 nameif INSIDE
 security-level 90
 ip address 192.168.1.1 255.255.255.0
!
crypto ikev2 policy 10

encryption des
integrity sha256
group 19
prf sha256
lifetime seconds 86400
!
crypto ipsec ikev2 ipsec-proposal PROPOSAL-TO-FTD
protocol esp encryption des
protocol esp integrity sha-256
!
crypto ipsec profile PROFILE-TO-FTD
set ikev2 ipsec-proposal PROPOSAL-TO-FTD
set security-association lifetime seconds 28800
set security-association lifetime kilobytes 4608000
set pfs group19
!
interface Tunnel10
nameif VTI-ASA
ip address 169.254.2.2 255.255.255.0
tunnel source interface outside
tunnel destination 192.168.60.17
tunnel mode ipsec ipv4
tunnel protection ipsec profile PROFILE-TO-FTD
!
tunnel-group 192.168.60.17 type ipsec-l2l
tunnel-group 192.168.60.17 ipsec-attributes
ikev2 local-authentication pre-shared-key cisco
ikev2 remote-authentication pre-shared-key cisco
!
crypto ikev2 enable OUTSIDE
!
route outside 33.33.33.0 255.255.255.0 169.254.2.1

Policy-Based configuration:
interface GigabitEthernet0/0
 nameif OUTSIDE
 security-level 10
 ip address 192.168.61.12 255.255.255.0
!
interface GigabitEthernet0/1
 nameif INSIDE
 security-level 90
 ip address 192.168.2.1 255.255.255.0
!
access-list VPN-TRAFFIC extended permit ip object LOCAL_NETWORK object REMOTE_NETWORK
!
route OUTSIDE 33.33.33.0 255.255.255.0 192.168.61.1
!
object network LOCAL_NETWORK
  subnet 192.168.2.0 255.255.255.0
object network REMOTE_NETWORK
  subnet 33.33.33.0 255.255.255.0
!
nat (INSIDE,OUTSIDE) source static LOCAL_NETWORK LOCAL_NETWORK destination static REMOTE_NETWORK REMOTE_NETWORK no-proxy-arp route-lookup
!
crypto ipsec ikev2 ipsec-proposal PROPOSAL-TO-FTD
 protocol esp encryption des
 protocol esp integrity sha-256
!
crypto map TO-FTD 10 match address VPN-TRAFFIC
crypto map TO-FTD 10 set pfs group19
crypto map TO-FTD 10 set peer 192.168.60.17
crypto map TO-FTD 10 set ikev2 ipsec-proposal PROPOSAL-TO-FTD
crypto map TO-FTD 10 set security-association lifetime seconds 28800
crypto map TO-FTD 10 set security-association lifetime kilobytes 4608000
crypto map TO-FTD 10 set reverse-route
crypto map TO-FTD interface OUTSIDE
!
crypto ikev2 policy 10
 encryption des
 integrity sha256
 group 19
 prf sha256
 lifetime seconds 86400
!
crypto ikev2 enable OUTSIDE
!
tunnel-group 192.168.60.17 type ipsec-l2l
tunnel-group 192.168.60.17 ipsec-attributes
 ikev2 remote-authentication pre-shared-key cisco
 ikev2 local-authentication pre-shared-key cisco

1 Accepted Solution

Accepted Solutions

@krzysztofmaciejewskiit AD4 ping works because you are not specifying the source of the ping, therefore the ping uses the IP address of the VTI. AD8 fails as per the reponse above, the source of the ping would be the outside interface.

View solution in original post

4 Replies 4

@krzysztofmaciejewskiit packet-tracer is for through traffic not to/from the FTD/ASA itself. A ping would use the IP address facing towards the destination, so in your policy map that won't be an IP address as defined in the crypto ACL.

Okay, thanks for this information. However, do you perhaps have an idea why the AD 4th and AD 8th test results differ?

@krzysztofmaciejewskiit AD4 ping works because you are not specifying the source of the ping, therefore the ping uses the IP address of the VTI. AD8 fails as per the reponse above, the source of the ping would be the outside interface.

Yeah, you're right, I forgot that fact....