Block Outgoing VPN Access

[dlitteer]

I need to prevent the ability of visitors who connect laptops into the network and access the Internet via VPN client software. I can block regular web browsing through our Websense server, but it does not block users who initiate VPN sessions from inside the network.

Thanks for any help.

[Jesterino]

access-list acl_outside deny udp any any eq 500

where acl_outside is your outside access list. This will effectively stop IKE traffic from the VPN peer they are connecting to.

Alternatively, you can apply this to an inside access list, if you have one.

[srue]

you need to block *outgoing* connections to udp port 500. It won't do any good to block the incoming connections.

[Jesterino]

I'm aware of that. However in the past I have found I had to open port 500 externally on my outside access list to allow VPN connections to be made from inside my network.

[dlitteer]

That's the problem. We recently had a visitor that was able to bypass our security policy by connecting to the Internet from a VPN client installed on his laptop from inside our facility. I'm trying to block that in order to prevent that from happening again.

[Jesterino]

Correct - the VPN device they are connecting to sends ESP traffic back through your firewall on port 500/udp. I have found by blocking this port the traffic does not come back to the client on my network, which is your desired result.

[rigoberto.cintron]

Just block ESP and ISAKMP in your inside interface. That will take care of it.

e.g.

access-list access_inside_in extended deny ip any any 50

access-list access_inside_in extended deny udp any any 500

[Jesterino]

Which is something else I mentioned in my first reply!

'Alternatively, you can apply this to an inside access list, if you have one.'

In quite a few cases I have seen no inside access list, which is why I suggested the outside interface first.

[rigoberto.cintron]

Actually there is always an ACL apply to inside even if it is.

access-list inside_acces_in extended permit ip any any

Just insert the deny ACL's before the permits.

[Jesterino]

Are you sure about that? It works even without an 'access-group inside_access_in in interface inside' config line?

I do not agree with your statement.

[rigoberto.cintron]

Any PIX/ASA, FWSM by default will have an acl apply to the inside interface allowing all the traffic unless the user delete the acl and remove the access-group statement in the interface.

[Jesterino]

Incorrect.

Interfaces have a security level. The higher the number, the more 'secure' it is.

By default traffic on a higher security level interface is permitted to pass onto a lower security level interface.

This is why traffic on your inside interface (security 100) is automatically permitted to pass onto your outside interface (security 0) unless you apply an access list to it.

[rigoberto.cintron]

Anybody that know how the Adaptive Security Algorithm works in the PIX/ASA software knows that traffic from a higher security level will flow to a low security level without acl' or if there is no acl restricting the traffic. Still when you get the device out of the box it come with an acl apply to the inside allowing any traffic. If the device don't have an acl apply to inside it's because the user removed the acl. Which I really don't see a reason to don't have an acl in the inside of a firewall. So normally the most efficient and secure way to block traffic is blocking it in the nearest interface to the source, in this case the inside.

[dlitteer]

I don't know very much about this, but there are only two acl's on this device, one for NAT and one for VPN split-tunneling. I would rather block it from the inside and absolutely not effect the external vpn users coming in. Would you guys mind taking a look at the configuration if I add it with the public addresses omitted?

[acomiskey]

Rigoberto,

This is not correct...

access-list access_inside_in extended deny ip any any 50

access-list access_inside_in extended deny udp any any 500

It should be...

access-list access_inside_in extended deny esp any any

access-list access_inside_in extended deny udp any any 500

access-list access_inside_in extended permit ip any any

access-group access_inside_in in interface inside