Remote VPN via the internal network

[Kishore Chennupati]

Hi All,

I have a small request.  I have a setup where the internal users within the corporate network need to remote VPN into the VPN concentrator.

The setup is as below

                            inside

(202.x.x.x)VPN ASA 5520 ----------------    FW ------------- intenal network

                         ----------------

                          outside

The problem is that the 10.0.0.0/8 internetl network establishes the connection via the outside interface. However, the return path is via the inside interface. But the vpn concentrator keeps showing next-hop not reachable for USP 500. Why does it show that when it has a route via the inside interface.

6|Jan 29 2013 13:44:38|110003: Routing failed to locate next hop for udp from NP Identity Ifc:202.x.x.x..29/62465 to outside:10.163..x.x/5892

Also, since we are trying to send traffic from outside to the inside interface, I tried to NAT the source ip i.e 202.x.x.x and left the source unaltered.

But it still doesnt work.

I am wondering why is the ASA not routing via the inside interface and looks for the return traffic via the same outside interface the traffic entered in.

The outside has a security-level of 0 and the isnide has a sec-level of 100.

Any help would be appreciated.

If you need any config etc , please let me know

Regards

[Kishore Chennupati]

still no one?

100 ppl have viewed this thread but no input?

Jenny Halim, can you provide your expert input please?

[Jennifer Halim]

Yes, pls kindly provide configuration.

To summarise your question, users connected to the internal network needs to VPN into the ASA5520, and access resources within the same internal network?

Or, are you trying to connect to another device (a Cisco VPN Concentrator 3000 series)?

Are they able to connect to the VPN device, or after they are connected, they are not able to access any resources?

Also, what ip address are they trying to access the VPN server with?

[Kishore Chennupati]

Thanks heaps Jenny. Knew you would help :-)

You are right. The users want to establish VPN from internal network and access some partner servers which allow access only from the remote VPN pool. And you are right that the partner subnets are located somewhere in the internal network.

When the internal users try and connect to the ASA 5520(vpn concentrator), I do a "sh isakmp sa" on the ASA and can see that the conn status message as AM_MSG3. Also, when I check the logs i see the below msg.

6|Jan 29 2013 13:44:38|110003: Routing failed to locate next hop for udp from NP Identity Ifc:202.x.x.x..29/62465 to outside:10.163..x.x/5892

The users connect using the internal IP which is in the 10.163.x.x range and try and establish to the ASA's outside Ip which is 103.x.x.x.

On the ASA there is a route to 10.0.0.0 via the inside interface. However the ASA is trying to look for the return path via the outside interface and hence i get the above message. I dont get it why? There is default route via the outside interface but 10.0.0.0 is more specific , therefore i belive it should route the return via the inside interface but its not.

I cannot route 10.0.0.0 via outside interface as that could break some other stuff but if its a must then i need to take it to the design team.

I have sent the config as PM to your inbox.

once again. thanks heaps

Regards,Kishore

[Jennifer Halim]

If the users are connecting from the inside, then they can't VPN to the ASA outside interface. They can only VPN to the interface where they are connecting from, ie: the inside interface. However, if they are trying to access an outside resources after they VPN in, then it won't work as well because they are VPN into the inside interface which is a private IP.

BTW, i haven't got your config yet.

[Kishore Chennupati]

True, but the ASA has both inside and outside connected to the FW and the  traffic from internal users to the outside IP on the ASA goes via the outside interface on the FW to the outside interface of the ASA. The log from the above shows that the users are able to reach the  ASA 5520 but the ASA5520 is not able to reach the users back.

I simualted this in GNS3 and could replicate  the same issue. What I then did was to put the static route via the outside interface and it worked

before

route 10.0.0.0 via inside

After

route 10.0.0.0 via outside

and it worked.

So the question is why is the ASA looking for the 10.0.0.0 via the outside interface when there is already a static route via the inside interface.

I did send you te config just then. Must be on the way :-)

[Jennifer Halim]

Ok, I think i know what the issue is.

Since the ASA initially have route for the 10.0.0.0 via the inside, traffic becomes asymmetric, which is why the ASA is dropping the connection.

If you are connecting to the ASA outside interface, the return traffic must be via the outside interface as well, and it can't be via the inside interface. Since your route says to route the traffic towards the inside, then it becomes asymmetric and the ASA drops the connection.

Once you configure route towards the outside interface, then traffic in and out is via the outside interface, and it connects successfully.

Hope that answers your question.

[Kishore Chennupati]

Thanks Jenny. Just curious I am not a big asa expert . But is it a must that the route should be learned via the same interface? I mean is it only a ASA feature. because in case of some other vendors i have noticed that it doesnt matter what interface it leaves and comes back as long as its stateful. Please correct me if I am wrong.

[Jennifer Halim]

Yes, for ASA it must route in and out the same interface, otherwise, it becomes asymmetric and ASA will drop the connection. This is to ensure that there is no routing loop that might possibly happen.

[Kishore Chennupati]

Thanks Jenny. The reason why I asked if it was an ASA feature is because I have been told that on the old VPN concentrator which is a PIX, the same set up worked. Below is the routing setup

route outside 0.0.0.0 0.0.0.0 103.X.X.1 1

route inside 10.0.0.0 255.0.0.0 10.170.x.x 1

But we replaced that with a ASA 5520. So I want to be sure before i tell the business that the current setup will not work because the ASA will not permit assymetric routing and would drop it. Can you please advise?

[Jennifer Halim]

It shoudn't have worked with the PIX as well. What version of PIX were you running before?

I never tested TCP connection terminating towards the ASA itself, but you can try to enable TCP encapsulation for the VPN, and configure TCP state bypass for those specific traffic. That case, ASA will not check for the TCP state and will allow asymmetric connection. But that really defeats the purpose of having a firewall as it supposed to check for misbehave traffic.

[Kishore Chennupati]

The PIX we had was this

PIX Version 6.3(3).

I agree with you, however, I was told it worked before and now it doesn't and we have a few trouble tickets within our ticketing system for this  .

The thing is we have to believe these guys because they are just  users and they dont mess around with any network stuff. Also the vpn client on the laptops is all  hard coded. Therefore, I will have to trust them when they say they are connecting to the 103.x.x.x addresss which is outside interface and it worked before and not anymore.

[Jennifer Halim · Accepted solution]

6.3.3 was kinda old, and if it does work before, it most probably shouldn't have worked and it's probably a bug that it actually works.

The correct behaviour is it shouldn't have worked for both PIX and ASA firewall.

[Kishore Chennupati]

Excellent. So based on what you have seen so far. What would be your recommendations if we were to fix this issue.

Below is what i think.

1. We might have to add another profile with the inside ip address for the users on their VPN clients if they want to connect from internal network.

2.  Add route 10.0.0.0 via outside. I cannot add the route to 10.0.0.0 via outside as it might break some other stuff , therefore the current setup will not work.

3. Use TCP state bypass. This might need further research as it defeats the purpose of FW.

Have you got any links or something talking about this assymetric stuff etc on the ASA 5520 which i can send off to the design team so that they can take corrective actions.

Also, what was that TCP state bypass thing. Its interesting. I might try on GNS3. can you kindly send something for that as well when you can.

I really apreciate all your help. I know its late in the night but you stil took the initiative to help. I cant thank enough.

I wish there were more than just 5 stars

[Jennifer Halim]

Option 1 is probably the easiest to implement and the most correct way to implement it. I would also configure a different vpn pool for user who connect from internal network so it doesn't conflict with the existing outside user as well as it doesn't conflict with the internal addressing scheme.

Option 2 as you have mentioned might break other access so it is best to steer away from.

Option 3 also defeats the purpose of having a FW, but here is the configuration guide for your reference:

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a0080b2d922.shtml

--> Actually after further thought, the TCP State bypass will only work if the asymetric routing is actually on another device, not on the ASA itself. For ASA, traffic needs to have symmetric routing unfortunately.

In that case, looks like Option 1 would be the only solution you have.