ASA routing problem for internal networks

[miles0001]

Hi folks,

I'm setting up an ASA 5512-X, replacing our old Linux firewall/router.

In the old firewall, I had a port opened to an OpenVPN server inside the network. I've opened access to the same port in the ASA. The OpenVPN server is reachable from the outside through the ASA, but clients connecting through the OpenVPN server cannot connect to any devices on the internal network. Neither can devices on the internal network connect to OpenVPN clients.

This is understandable, as the ASA is the default gateway for the network, and all packets from devices intended for the OpenVPN clients, are sent to the default gateway. I have tried to create a static route to the OpenVPN server for traffic to/from VPN clients on the ASA inside interface, but the ASA does not seem to route the appropriate traffic to the OpenVPN server.

Our internal network is a 192.168.0.0/16 network, and OpenVPN has got a 10.0.1.0/24 network

I'm going to replace the OpenVPN server with AnyConnect subsequently, but the OpenVPN solution must unfortunately be in place for quite some time yet.

What am I doing wrong?

Best regards,

Peter

[deyster94]

Do you see anything in the ASA log files that the traffic is getting to the ASA?

[miles0001]

Hi,

Yes, I can see that packets from the inside network with destination to the OpenVPN client, are denied at the ASA inside interface. I have got an access rule that allows ip and icmp on the inside interface, with destination to the OpenVPN network, but it doesn't seem to help.

Peter

[deyster94]

If you run packet tracer on the ACL's you have created for the traffic, do they pass? 

[miles0001]

No, they do not pass. They get dropped by the implicit rule.

Peter

[miles0001]

It seems the global implicit rule (deny all) is executed before the inside incoming rule in this case. And the rule that should allow the packets is the first incoming rule on the inside interface. It's weird...

Peter

[fb_webuser]

You may need to open several more ports. Check what openvpn is using beyond the initial port. My guess is you need to allow isakmp/500 and possible other ports too.

Look at the client and server side of the openvpn to see where things are breaking.

---

Posted by WebUser Jesper Klit Jensen from Cisco Support Community App

[miles0001]

Hi Jesper,

From tracing and logging it's completely clear that this is not a OpenVPN problem. The packets get dropped by the ASA. The global deny rule is erroneously applied before my rule that allows packets to the OpenVPN network.

Thanks for your input

Peter

[Jouni Forss · Accepted solution]

Hi,

I am not 100% sure about your setup but from what I gather you have the users and the VPN server in the same LAN network behind the ASA. The VPN users get an IP address from a VPN pool which in turn causes the LAN hosts/servers to send their traffic to the default gateway which is ASA.

This in turn causes asymmetric routing and the ASA doesnt see the full TCP connection 3 way handshake and drops the connections.

At this point it might even drop the to lacking the global configurations "same-security-traffic permit intra-interface" which is required for traffic to enter and leave the same interface on the ASA.

If all this is true then it would seem to me that there are a couple of options atleast.

• Configure TCP State Bypass on the ASA for traffic between the LAN and the VPN Pool. This will naturally eliminate some security that the ASA provides for this traffic but considering we are talking about 2 networks which should already be secure I guess it would suffice for as long as you have to keep the OpenVPN setup.
• Other options would be to move the server out of the LAN and move it on a DMZ on the ASA so that there is no way that the ASA could not see all the traffic between the VPN users and LAN users. This would seem to me better choice than the above.

Here is a link to a Cisco document describing TCP State Bypass.

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

Its for the old 8.2 software but should give you the basic idea of how to configure it.

Hope this helps

- Jouni

[miles0001]

Thanks again Jouni!

I applied the same-security-traffic rule, but that alone did not help (well, from inside to the VPN clients, but that wasn't what was intended). Then I applied the TCP bypass, which did the trick! Your assumption about the network topology is completely right. Moving out some of the servers to a DMZ had been overkill, and for some it's not even practically possible.

I wish you a nice day,

Peter