Okay, I got it figured out.
The solution was to add a static route on both ASAs pointing at the outside interface of the other ASA.
So, from ASA-1
route outside 126.96.36.199 255.255.255.255 188.8.131.52 1
and from ASA-2
route outside 184.108.40.206 255.255.255.255 220.127.116.11 1
Originally, I had set up static routes this way when doing the original configuration and setting up basic connectivity:
route outside 18.104.22.168 255.255.255.255 22.214.171.124 1
route outside 126.96.36.199 255.255.255.248 188.8.131.52 1
When the routes using the network range were in place, OSPF would not form neighbor relationships between the ASAs. When I removed the static route the neighbor relationship would form but cause the IPsec tunnel to flap. Re-adding the static routes by pointing directly at each outside interface appears to have solved the problem. The IPsec tunnel has been stable and OSPF is working correctly between the ASAs.
... View more
I had forgotten - and should note - that apparently when you remove a network from being advertised via OSPF on the ASAs it will also remove any related static neighbor settings. It took me a minute to figure this out as the static neighbor still appears in ASDM but not in the actual config. Also, you cannot set static neighbors without advertising the network you're setting the static neighbors for. (I'm running ASA 9.1(6) and ASDM 7.9(2)152 on both ASAs.)
So, that would explain why the neighbor relationship isn't forming when configured with static routes between the tunnel endpoints and I'm not advertising the network the tunnel endpoints are in via OSPF.
This is a quote from one of the forum posts I linked to in the original post:
"If the tunnel interface learns that the best path to the tunnel destination is through the tunnel itself, the interface shuts down temporarily."
Again, it seems like a catch-22. I can't set static neighbors without advertising the tunnel endpoint network, but I can't form neighbor relationships between the ASAs without doing so.
... View more
Hey all. I'm attempting to get OSPF running over an IPsec tunnel between two ASA 5510s. However, I seem to be running into a catch-22 kind of scenario. I'm guessing there is something really simple I'm missing here and I hope someone can provide some insight as to what that could be.
Please note, I am currently setting this up in a test network. There are two "sites" in the setup and two routers acting as a fake ISP between the two ASAs.
This is the current physical topology:
HP 5406 --> ASA-1 inside
ASA-1 outside --> Ubuntu VM router 1 eth0
Ubuntu VM router 1 eth1 --> Ubuntu VM router 2 eth1
Ubuntu VM router 2 eth0 --> ASA-2 outside
ASA-2 inside --> Enterasys N3
The two Ubuntu VMs acting as routers are the fake ISP. SITE-1 consists of the HP 5406 and ASA-1. SITE-2 consists of the Enterasys N3 and ASA-2.
10.1.0.0/20 are SITE-1 internal networks
192.168.10.0/29 is the SITE-1 to ASA transit network
ASA-1 inside: 192.168.10.2
172.16.100.0/24 is SITE-1's management network
184.108.40.206/29 is the ASA-1 outside to Ubuntu VM router 1 transit network
ASA-1 outside: 220.127.116.11
Ubuntu VM router 1: 18.104.22.168
22.214.171.124/29 is the transit network between the two Ubuntu VM routers
126.96.36.199 is Ubuntu VM router 1
188.8.131.52 is Ubunti VM router 2
184.108.40.206/29 is the ASA-2 outside to Ubunti VM router 2 transit network
ASA-2 outside is 220.127.116.11
Ubuntu VM router is 18.104.22.168
172.16.200.0/24 is SITE-2's management network
192.168.20.0/29 is the transit network between ASA-2 and the N3
192.168.20.1 is the N3
192.168.20.2 is the ASA-2 inside interface
10.2.0.0/20 are SITE-2 internal networks
Both SITE-1 and SITE-2 are in OSPF area 0.0.0.0. The HP 5406 has router-id 0.0.0.1. ASA-1 is router-id 0.0.0.2. The N3 is router-id 0.0.0.3 and ASA-2 is router-id 0.0.0.4.
I have been able to form the IPsec tunnel between the two ASAs and set static OSPF neighbors between the two ASA outside interfaces. As long as I am advertising the transit network associated with the outside interface with OSPF, am redistributing static routes and have OSPF static neighbors set on each ASA pointing at the other ASAs outside interface I am able to form a neighbor relationship between the two ASAs and obtain routes. However, this setup appears to cause the IPsec link to flap, which in turn causes the OSPF neighbor relationship to time out and drop routes. This happens about every 3 to 5 minutes.
I've found a few forum posts/articles stating that you should statically route between the two tunnel endpoints and not advertise the tunnel transit networks between the ASAs in OSPF (or other dynamic routing protocols). But when I do it this way, the ASAs never see each other as OSPF neighbors, even when set as static neighbors. I can see LSA1 entries for the far ASA on each ASA when it's configured this way, but relationship never forms. However, when I stop advertising the networks with the tunnel endpoints between the ASAs and I set the route between the endpoints static on each one then the IPsec tunnel is solid and doesn't flap.
These are the forum posts/blog entries I'mr referring to specifically:
I've attached sanitized configs for each test ASA. I'm also happy to provide whatever other info might be useful in troubleshooting this issue.
I appreciate any assistance! Thanks!
... View more
I'm trying to set up SNMPv3 on one of my production ASA 5525-Xs. From what I'm seeing, the ASA is never responding to the SNMP GET requests being sent from my NMS. I've also tried configuring SNMPv2c and have gotten the same result.
I am running ASA version 9.2(2)4 and ASDM version 7.3(1)101 on this device currently.
On this particular ASA, my network management subnet is associated with an interface called "P-Config". It is not using the "Management" port, but a regular gigabit Ethernet port. This interface is separate from my "Inside" interface. Additionally, the "Inside" interface is designated as the "Management Access Interface" in ASDM under "Management Access > Management Interface". As part of my testing, I have configured hosts in the "SNMP Host Access List" section of the SNMP config to use the "Inside" interface and the issue occurred on that interface as well. I am normally trying to set up the SNMP Host Access List entries using the P-Config interface. Both the "P-Config" and the "Inside" interface are security level 100.
On the P-Config interface, I have rules allowing UDP ports 161 and 162 from the network management subnet to my NMS and vice versa. I have also added a "permit ip any any" rule at the top of the ACL for the P-Config interface as part of testing. Unfortunately, none of these rules make a difference. Just in case it wasn't clear - the P-Config interface and my NMS are on the same subnet.
I have another ASA - a 5510 - that I use for testing purposes. It is running a similar code base, 9.1(5), and I was able to get SNMPv3 up and running for that device. It is communicating on my network management subnet and is using the same SNMPv3 credentials that I am entering into my production ASA. Same USM, same SNMP user, same SNMP user group.
Doing a wireshark packet trace from the NMS to the ASA shows SNMP GET packets getting to the P-Config interface on the ASA, but I never receive a response. And yes, I have turned on SNMP on the ASA. Using the Packet Trace tool in ASDM and from the CLI, when I trace with the Source IP set as the IP of the P-Config interface to the IP of the NMS, I get an ACL-drop response due to the "Implicit Deny" rule... even when I have the "permit ip any any" rule enabled at the top of my P-Config ACL.
Here is a santizied version of my SNMP config (not including location, traps, etc):
snmp-server group snmp-asa v3 priv snmp-server user nms snmp-asa v3 encrypted auth md5 HASH priv des HASH snmp-server user-list snmp-grp-asa username nms snmp-server host P-Config 172.x.x.x version 3 nms
At this point, I'm stumped. I've been through all the documentation, forums, blog posts, etc, I can find. I have an open case with Cisco TAC as well and so far they've been unable to find the problem.
Any assistance is appreciated.
... View more
Hey all, I'm attempting to set up a site-to-site IPsec VPN tunnnel between two ASAs in a test environment. I'm attempting to recreate my production environment (to a degree), with the ultimate goal of testing OSPF static neighbors between the test ASAs in hopes of rolling that out to my production network eventually. Before I can do that, however, I need to get the tunnel working in my test network. Right now, the tunnel is the problem. OSPF can wait. As I'm sure you will be able to tell, I'm not super well versed in the ASA or creating VPN tunnels. The two test ASAs are 5510s. One is running IOS 8.4(7) and the other is running 9.1(5). Both are using ASDM 7.3. I've been through multiple setup guides, instructions, blogs, forums, etc and one would think by reading that stuff that setting up a simple IPSec tunnel is as easy as just using the Site-to-Site VPN wizard (which I've tried multiple times), but apparently not. I have a Windows server 2012r2 box running RRAS sitting between the two test ASAs to act as my faux-internet connection (bascially to give me a hop between the two ASAs). RRAS just has static routes set up for connectivity between the two ASAs. This has been tested and is working. In attempting to set up the site-to-site VPN, I've tested a number of configurations, none of which have worked so far. I've tried using both IKEv1 and IKEv2, individually and with both enabled, with a simple pre-shared key. I've tried using PFS with D-H group 2 and 5. I've tried using specific IKE proposals. I've tried using specific group policy as well as the default. It doesn't need to NAT, since it's not actually going to the internet, so I've disabled NAT-T (although I've tried it both ways). Since this is a test environment, the ACLs are all permit any any for IP and ICMP. I'm sending interesting traffic by pinging from two different devices across the connection where I want the VPN to form. However, from what I can tell, it's not even forming the phase 1 tunnel.When wiresharking on the interfaces on the Windows server the two ASAs are connected to, I don't see any packets that look like they're trying to establish a tunnel or exchange keys, etc. Also, I've got debugging turned on for IKEv1, IPsec and the crypto engine and I'm only seeing the following messages: [IKEv1]Ignoring msg to mark SA with specified coordinates <outside_map, 1> dead and CTM ERROR: Invalid input parameters, ctm_get_scb_prot_stats:1565 I've done research on both errors but haven't found anything so far that has helped. This morning I wiped both test ASAs back to factory defaults. Since then, I've added the basic config for addressing and accessing ASDM and to allow ICMP, in addition to attempting to set up the VPN yet again. I've attached the configs for both of my test ASAs. The configs reflect a pretty simple VPN configuration attempt, with just IKEv1 enabled. As I've mentioned, I've tried multiple other variations on the configuration. What is reflected in the configs is what I would consider my "base"config. Additionally, here is how the RRAS static routing is configured: NIC 1: 192.168.99.2/30 NIC 2: 192.168.100.2/30 Routes: 10.1.1.0/24 GW: 192.168.100.1 10.1.2.0/24 GW: 192.168.100.1 192.168.56.0/29 GW: 192.168.100.1 172.20.1.0/24 GW: 192.168.99.1 172.20.1.0/24 GW: 192.168.99.2 192.168.55.0/29 GW: 192.168.99.2 *** The 172.20.x.x and 10.1.x.x networks are the networks I want to send through the VPN Any and all help and suggestions are appreciated. If more details, configs, etc, are needed, I am happy to oblige.
... View more