07-18-2024 02:22 AM
Hello Team,
I have a network as below,
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.
Solved! Go to Solution.
07-22-2024 06:41 AM
Can I see
Show ip ospf database external <<- in core SW
MHM
07-22-2024 06:48 AM
there is too much output, do you wanna grep anything in particular?
07-22-2024 06:53 AM
Show ip ospf database external <static route prefix>
MHM
07-22-2024 06:55 AM
07-22-2024 07:21 AM
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
07-22-2024 07:24 AM
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
07-22-2024 07:31 AM
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;
07-22-2024 07:34 AM
its redistributing via process id 1 = 31.31.31.31
process id 2 has no redistribution;
07-22-2024 07:40 AM - edited 07-22-2024 07:42 AM
Show ip ospf database external <<- in ftd
Do that after you add
Redistrubte connected subnet
MHM
07-22-2024 08:03 AM
07-22-2024 09:48 AM
sorry these are two entry
can you elaborate both are for ftd?
MHM
07-23-2024 01:16 AM
they are from the same FTD.
the ftd has two opsf process IDs.
07-23-2024 03:07 AM
sorry why you run two process in FTD ?
MHM
07-23-2024 03:49 AM
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.
07-23-2024 03:56 AM
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
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