03-02-2025 05:22 AM - edited 03-02-2025 05:54 AM
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:
The result of the command: show vpn-sessiondb detail l2l
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.
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.
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
Solved! Go to Solution.
03-03-2025 09:38 AM
@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.
03-02-2025 06:07 AM
@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.
03-03-2025 08:47 AM
Okay, thanks for this information. However, do you perhaps have an idea why the AD 4th and AD 8th test results differ?
03-03-2025 09:38 AM
@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.
03-03-2025 09:50 AM
Yeah, you're right, I forgot that fact....
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide