cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3815
Views
5
Helpful
20
Replies

ASA VPN Injecting wrong route on OSPF when using Remote Access

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.

5 Accepted Solutions

Accepted Solutions

slmansfield
Level 4
Level 4

If I understand your question, my question to you is whether the OSPF route to the remote VPN client is sourced by the ASA or by another device?

Is the IP address in the space that I wrote ASA_ROUTER_ID the router ID of the ASA or is it the router ID of another device?  What I listed below is an example of the output of "show ip route".  The bolded value should be the ASA's router ID if it is originating the route to the VPN client.  The other OSPF routers will forward packets destined for the VPN client to the ASA.

#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
  Known via "ospf 1", distance 110, metric 310, type intra area
  Last update from 1.2.2.2 on GigabitEthernet0, 2w ago
  Routing Descriptor Blocks:
  * 1.2.2.2, from ASA_ROUTER_ID, 2w ago, via GigabitEthernet0
      Route metric is 310, traffic share count is 1

View solution in original post

You're saying that the static route created by RRI on the ASA is pointing to the inside of your network instead of the outside?

Here is an example of using RRI on the ASA.  Perhaps it will help you to determine the cause of this problem.

http://www.cisco.com/application/pdf/paws/107596/asa_reverseroute.pdf

View solution in original post

The RRI creates a static route that points to the next hop on the interface to which the crypto map is applied.  Have you applied the crypto map to your inside interface?

View solution in original post

Sorry, but I don't understand what you are referring to when you say you are only using one interface.  How is your configuration different from the one in the RRI URL that I referenced?

View solution in original post

I'm sorry if I'm not understanding you, but in your diagram it indicates that the .100 address is the next hop towards the VPN client from the ASA.

View solution in original post

20 Replies 20

slmansfield
Level 4
Level 4

If I understand your question, my question to you is whether the OSPF route to the remote VPN client is sourced by the ASA or by another device?

Is the IP address in the space that I wrote ASA_ROUTER_ID the router ID of the ASA or is it the router ID of another device?  What I listed below is an example of the output of "show ip route".  The bolded value should be the ASA's router ID if it is originating the route to the VPN client.  The other OSPF routers will forward packets destined for the VPN client to the ASA.

#sh ip route 1.1.1.0
Routing entry for 1.1.1.0/24
  Known via "ospf 1", distance 110, metric 310, type intra area
  Last update from 1.2.2.2 on GigabitEthernet0, 2w ago
  Routing Descriptor Blocks:
  * 1.2.2.2, from ASA_ROUTER_ID, 2w ago, via GigabitEthernet0
      Route metric is 310, traffic share count is 1

My equipament ASA has a 192.168.1.102 IP address and participate in OSPF process. 10.124.240.26 is the vpn client IP address.

When I'm looking into ASA I can see the static route below pointing to another equipament (192.168.1.100). This static route was created when I establish my vpn session. My client vpn started his session behind this router (192.168.1.100).

asa-vpn# sh route | grep 10.124.240.26
S    10.124.240.26 255.255.255.255 [1/0] via 192.168.1.100, rprbbe

The problem occurs when I'm looking in another router participant of this OSPF area. The route to 10.124.240.26 (vpn client) is to 192.168.1.100 router and don't to 192.168.1.102 (asa), what it will be correct.

This is an example of this problem:

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

You're saying that the static route created by RRI on the ASA is pointing to the inside of your network instead of the outside?

Here is an example of using RRI on the ASA.  Perhaps it will help you to determine the cause of this problem.

http://www.cisco.com/application/pdf/paws/107596/asa_reverseroute.pdf

I'm using just one interface. I've already see this paper and alredy tried to create the route-map like the example on this paper. But didn't work.

The RRI creates a static route that points to the next hop on the interface to which the crypto map is applied.  Have you applied the crypto map to your inside interface?

No I just applied to my outside interface because I'm using just use one interface.

Sorry, but I don't understand what you are referring to when you say you are only using one interface.  How is your configuration different from the one in the RRI URL that I referenced?

I've just one interface in use on my ASA.

When someone from the internet comes to my ASA VPN I permit entering to my network and comes to my machine 172.28.1.1 for example.

I can see icmp (icmp-request) packets comes from 10.124.240.26 to 172.28.1.1 but the packet (icmp-reply) doesn't return to 10.124.240.26. Because the router1 learning from ospf that the return is to 192.168.1.100. The correct way will be to 192.168.1.102.

I'm sorry if I'm not understanding you, but in your diagram it indicates that the .100 address is the next hop towards the VPN client from the ASA.

No problem. You understand very well. The problem in this case is when the ASA injects the route to this client. The ASA should inject the route in OSPF pointing to itself and don't to .100 ip address. Do you understand?

When I look at the output of "show ip route" for the VPN client route, the source of the route is 192.168.100.102, which is the ASA.  Its next hop towards the VPN client is 192.168.1.100, Router2.  I believe that is the correct route.  Are you not getting traffic back to the VPN client?

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

Typo there, the correct address of the ASA is 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

The correct 'show ip route' should be:

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.102, from 192.168.1.102, 00:05:32 ago, via FastEthernet0/0
      Route metric is 20, traffic share count is 1

This should occur because the VPN connection was established with ASA (192.168.1.102). Other participants of this OSPF area should come to the VPN client using the ASA and don't directly to another router.

Router2 has a better metric to reach the VPN clients than the ASA.  Instead of sharing the 192.168.1.0 subnet, if Router2 can be on a separate segment connecting to the outside interface of the ASA then the other devices will use the ASA as their next hop to reach the VPN clients.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: