cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3718
Views
8
Helpful
36
Replies

IPSEC VPN

fmugambi
Spotlight
Spotlight

Hello Team,

I have a network as below,

fmugambi_0-1721294430756.png

Asa peers with isp using bgp.

theres ospf for downstream and upstream routing.

there is natting on asa public interface to ftd 40.18  interface, with 4500,500 services.

Is it possible to use this FTDs 40.18 interface to peers with remote site to form a site - to - site vpn?

Your support will be appreciated.

Thank you.

 

36 Replies 36

Can I see 

Show ip ospf database external <<- in core SW

MHM

there is too much output, do you wanna grep anything in particular?

Show ip ospf database external <static route prefix>

MHM

fmugambi_0-1721656504878.png

 

Here is my input after reading this post with what others have said. Yes, you can use the FTD's 40.18 interface to create a site-to-site VPN with remote sites as long as they support NAT-Traversal (NAT-T). NAT-T allows VPN endpoints behind Network Address Translation (NAT) devices to establish IPSec tunnels.

Pinging ASA Public IP from FTD 40.18 Interface:

Yes, the FTD's 40.18 interface should be able to ping the ASA's public IP address, assuming the following:

-The ASA permits pings from the FTD's subnet.
-The IPSec VPN tunnel is established and operational.
-There are no firewall rules blocking pings on either device.

OSPF route redistribution over a policy-based VPN is not possible. Policy-based VPNs only allow specific traffic (like web browsing or email) to traverse the tunnel, not routing information.

To redistribute routes over the IPSec VPN, you need a route-based VPN. A route-based VPN configures a tunnel interface and runs OSPF over it. This allows OSPF routing information to be exchanged between the networks.

Changing from a policy-based to a route-based VPN may require configuration changes on both the FTD and the remote devices.

few pointers to consider:

Reverse Route Injection: By default, Firepower Management Center (FMC) has Reverse Route Injection enabled. This injects routes for the remote network into the FTD's routing table and allows them to be redistributed to other routing protocols like OSPF.

Troubleshooting OSPF Redistribution Issues:

some steps to troubleshoot why OSPF route redistribution for IPSec VPNs might not be working as expected:

Ensure OSPF redistribution is enabled on the FTD for the appropriate process (e.g., redistribute type 2).
Check if static routes learned from the VPN are being redistributed into OSPF.

Verify OSPF database entries on both the FTD and the downstream switch for the remote network routes.

Confirm that the OSPF neighbor relationship between the FTD and the downstream switch is established and functional.

Enable Reverse Route Injection (if using policy-based VPN):
Even though route-based VPN is recommended for OSPF redistribution, on a policy-based VPN, enable Reverse Route Injection on the FTD to inject routes for the remote network.

Refer to Cisco's documentation for troubleshooting OSPF: https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/12151-trouble-main.html

 

please do not forget to rate.

the routes are static from the FTD perspective, correct?

so that on its process id i redistribute static? and should i extend to subnets for classless scope?

Thank you

fmugambi_0-1721658576571.png

this is on the vFTD, the remote network is there. neighbor 31.31.31.31 is what the vFTD should redistribute the route to;

but when you check the route on the core;

fmugambi_1-1721658656978.png

 

fmugambi_2-1721658791293.png

its redistributing via process id 1 = 31.31.31.31

fmugambi_3-1721658859525.png

 

process id 2 has no redistribution;

 

fmugambi_4-1721658886262.png

 

Show ip ospf database external <<- in ftd

Do that after you add 

Redistrubte connected subnet 

MHM

fmugambi_0-1721660540828.pngfmugambi_1-1721660570229.png

 

sorry these are two entry 

can you elaborate both are for ftd?

MHM

they are from the same FTD.

the ftd has two opsf process IDs.

sorry why you run two process in FTD ?

MHM

 

ftd refused to add a different p2p network to asa on the same area. so for this i used process id 2, then process id 1 is for ospf downstream to core switch.

ftd refused to add a different p2p network to asa on the same area <<- dont get this point can you more elaborate 

show ospf 
check if both ospf process use same router-id or not ?

I run lab and use RRI and redistribute static subnet into ospf and it work, so it not IPsec RRI issue I think it OSPF dual process issue

MHM