ASA VPN Injecting wrong route on OSPF when using Remote Access

[Fernando Patzlaff]

Someone already seen the ASA inserting a wrong route in one connection that was established with it?  I'll explain more below:

I've using a Reverse Route Injection. When a Remote Access with IPSEC (CLIENT) connects in the appliance ASA, the ASA create a static route to this Remote Access pointing to the router more near for the ASA to come to this Remote Access. This route is distributed on OSPF. Ok it may be a normal situation. But, the problem is when I ask to another participant from this OSPF area, what is the route to this Remote Access (CLIENT), the answer is to the router more near for the ASA and don't to the ASA. Someone have a solution for this? I've tried create a route-map but didn't work.

[Fernando Patzlaff]

Let me explain to you something .

The client has another IP address. After doing a vpn connection it obtains an IP Address (10.124.240.26). The router2 doesn't know this IP address (10.124.240.26) because this is a VPN IP address. This address (10.124.240.26) is just knowed after I establish the VPN. Who gives this address to the client ? ASA gives. If ASA gives this address, all traffic should need pass to the ASA and don't pass directly to router2.

[slmansfield]

Router1, Router2, and the ASA are on the same multi-access network, 192.168.1.0.  If the ASA advertises a route to the VPN client with Router2 as the next hop towards the VPN client, all the other devices on the 192.168.1.0 network, including the ASA, use Router2 as the best path toward the VPN client.  OSPF does not know that VPN traffic should not be sent to Router2, it should first be sent to the ASA.  The ASA itself is telling its OSPF neighbors that Router2 is the closest to the VPN client.

You have options to differentiate the way that VPN traffic is handled by other routers on this network.  You could put Router2 and the outside interface of the ASA on a separate segment and make the ASA the next hop for all devices on the 192.168.1.0 network toward the VPN client.  You could put a static route or policy route to the VPN client on Router1 (and other routers on that network) pointing to the ASA.  You could alter your OSPF configuration to force VPN traffic to the ASA.

[Fernando Patzlaff]

I'm trying to tell is: the way that ASA inject the route is wrong. I've a Cisco VPN Concentrator 3030 beside this ASA5540 in the same subnet and with just one interface. I'm trying to reproduce the same scenario with ASA to do a migration from Cisco Concentrator to ASA.

When I connect in ASA 5540 the route is pointing to 192.168.1.100 and was injected by 192.168.1.102:

router1# sh ip route 10.124.240.26
Routing entry for 10.124.240.26/32
   Known via ... , distance 110, metric 20, type extern 2, forward metric 1
...
...
   Routing Descriptor Blocks:
* 192.168.1.100, from  192.168.1.102, 00:05:32 ago, via FastEthernet0/0
      Route  metric is 20, traffic share count is 1

Different from this last example, when I connect directly to Cisco VPN Concentrator 3030 (192.168.1.103) the route that was injected is different pointing to itself like this example.

router1# sh ip route 10.124.240.26
Routing entry for 10.124.240.26/32
    Known via ... , distance 110, metric 20, type extern 2, forward metric 1
...
...
    Routing Descriptor Blocks:
* 192.168.1.103, from  192.168.1.103, 00:05:32 ago, via FastEthernet0/0
       Route  metric is 20, traffic share count is 1

In this example, all works fine ! I'm just trying to reproduce this enviroment on ASA and I can see the wrong way that it (ASA) publish the route on OSPF.

[slmansfield]

Looking through this example using the VPN concentrator, it looks like the static route is pointing to the public interface, not the next hop.

http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2284/products_configuration_example09186a0080094a6b.shtml

Try changing the route statement on the ASA to have the next hop of 192.168.1.102.

[Fernando Patzlaff]

The problem was solved by Cisco TAC. The solution was change the network line on the router ospf configuration.

From:

network 192.168.1.96 255.255.255.224 area 0

To:

network 192.168.1.102 255.255.255.255 area 0

After that all routes was published on OSPF correctly.

[tutugreen]

Hi, I just meet the same problem as you.

I definitely agree with you, about Cisco ASA injecting the wrong route.

As you add /24 in the network to solve that problem, my site is quite different.

My purpose is to give every device that connects to ASA bring their single, static IP (assign by the radius server), and because the IP will broadcast in the whole network with OSPF, change the different gateway to joining will still using the same IP, is very convenient for mgmt and IP based ACL.

I set ASA to redistribution all static/connected networks (so that include the Anyconnect client route), the good news is the AnyConnect client IP, for example, 10.0.0.1/32 are successfully visible in all OSPF routers But the problem is that route (10.0.0.1/32) gateway is pointing to the gateway of ASA, not ASA itself.

So the router in the same L2 with ASA will not send the packet to ASA, instead, it sends to the upstream gateway, cause ASA can't receive the packet that should send to 10.0.0.1, the client will get nothing RX.

I'm making a dirty workaround for splitting the VLAN interface, dedicated for client join, with the static route, no OSPF on that interface. And forward the client route to other interfaces with the different gateway that enable OSPF. That makes ASA inject the router with no OSPF, so it will force it pointed to itself.

I'm still looking for a better solution. If someone found. :)