Unexpected insecurity of ASA ipsec VPN clients

[Mabry Tyson]

We have an ASA5510 (running the last s/w for that device) that has long been providing ipsec VPN service to our users whose primary purpose is to give remote users secure access to inside our firewall..  We had a temporary network change a couple of days ago such that we have no control of network devices except our 5510.   The 5510 has an outside (security level 0) & inside (security level 100) interface.    The VPN addresses come from a pool of publicly routed IPv4 address.  Previously these IPs were protected by ACLs on an upstream router from incoming connections, but in the temporary configuration, that protection isn't there.  The VPN is not a split tunnel VPN.

If I am at home and connect to the VPN, I have a public address A.B.C.D.  I am finding that people on the Internet are attempting to ssh into A.B.C.D.   I have found that other ports are exposed as well.

This is unexpected to me.  I thought the ASA would block all incoming connections from the Internet (which is arriving at the 5510 via the outside i/f)  except what I opened by ACLs (or return traffic from outgoing connections).

I searched around and don't see any examples of IPSec VPN configurations in which ACLs were included to protect the VPN IPs.

This is so unexpected to me that I have some doubt that I'm understanding what is happening.  I considered that maybe the connection was entering the 5510 via the inside interface.  I disproved that by putting a block at the inside i/f and was still able to make a connection.

The only thing we are doing differently than most is that our pool contains publicly routable addresses. 

Has anyone run into this?    If I move to a newer ASA device, will it behave the same?  The 5510 is EOL but if a newer, supported device has the same issue, I think Cisco should document this and indicate that additional ACLs are necessary to protect the VPN IPs unless they are private addresses.

[Rob Ingram]

Hi @Mabry Tyson 

By default communication from a lower security level (outside interface) to a higher (inside interface) is blocked, traffic is only permitted if you have an ACL on the outside interface inbound permitting this traffic. Is the traffic actually permitted or denied?

Replicated the connection and use packet-tracer to simulate the traffic flow from outside to the ravpn ip address and determine whether the outcome is allowed or denied.

[Mabry Tyson]

As I said in the original message, a new connection enters the outside interface and is received by the VPN client.  The traffic never is routed to an inside interface (the VPN client is out in the Internet).  There is no ACL permitting or denying the traffic.

Suppose there are 4 IPs

  A.1.1.1  is my client at my home.

  B.2.2.2  is the outside interface ASA 5510 that provides ipsec VPN

  C.3.3.3  is the IP address assigned via the VPN  to my client.

  D.4.4.4  is some bad guy on the Internet.

D.4.4.4 sends packets to C.3.3.3 to open a tcp connection on port X.  Routing causes these external packets to be routed to B.2.2.2.

They enter the ASA.  They match no ACL to permit or block the packets.  Apparently they are then processed by the VPN mechanism.

The packet is encrypted and sent back out the outside i/f to the VPN client on A.1.1.1.

The VPN client decrypts the packet and delivers the decrypted packet to the C.3.3.3 interface (that the VPN has set up).

If the C.3.3.3 host thinks that the ASA was filtering incoming connections (only allowing those from the inside i/f and denying those from the outside i/f), it may allow a connection that wasn't desired.

My temporary network configuration is now gone.  My permanent network configuration blocks the unwanted traffic upstream of the ASA.  

It is too easy to think that the ASA blocks inbound connection attempts to VPN clients when it really doesn't.  That it doesn't do that should be better documented (or fixed).

[ameliascotts80938]

IPsec is a group of protocols that are used together to set up encrypted connections between devices. It helps keep data sent over public networks securely. IPsec is often used to set up VPNs, and it works by encrypting IP packets, along with authenticating the source where the packets come from.