Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Site to site VPN, unencrypted traffic ACL or ?

I have established Site to site  IPSEC VPN over public Internet between two private subnets. Is there some other way to prevent unencrypted traffic sourced from these two private subnets beside ESP/UDP500 ACL?

Everyone's tags (3)
6 REPLIES
New Member

Re: Site to site VPN, unencrypted traffic ACL or ?

SSL between them?  Are looking for an option that is not a L2L tunnel?

Re: Site to site VPN, unencrypted traffic ACL or ?

I'm not sure if understand your threat.

You want to restrict both sides to only send encryped traffic?

Through the Site-to-Site tunnel, the only traffic that will be sent is encrypted traffic (that you specify on both ends).

If you want both sites to not send unencrypted traffic, then you can use an ACL to deny all IP traffic besides ESP/UDP 500.

If you deny all unencrypted traffic from both sides, then only communication through the tunnel will be possible.

Is this what you're looking for?

Federico.

Re: Site to site VPN, unencrypted traffic ACL or ?

It seems to me that ISR (1841) I'm using first decrypts packet from my IPSEC peer and than apply ACL for that interface. It is out of my control what other packets may come from public Internet with source and destination addresses that match my IPSEC tunnel source and destination addresses. I was asking if anyone knows how to drop unencrypted packets NOT sourced from my IPSEC peer. Simply placing RFC 1918 ACL and not excluding hereby used private subnets would filter out everything even my tunnel data, and putting ESP/UDP500 ACL will have no effect on it????

I'm using IPSEC in tunnel mode with 3DES encryption and sha1 HMAC.

Thanks for your responses, comm@mt.net.mk

Cisco Employee

Re: Site to site VPN, unencrypted traffic ACL or ?

Assuming that you are running the later version of IOS code, you do not need to explicitly permit traffic between your site-to-site LAN on the outside interface access-list because it is already permitted by default after being decrypted. Hence, you only need to configure ACL for other inbound traffic that you need to permit, and all other clear text traffic apart from the decrypted traffic will be implicitly deny.

Hope that helps.

Hall of Fame Super Blue

Re: Site to site VPN, unencrypted traffic ACL or ?

comm@mt.net.mk

It seems to me that ISR (1841) I'm using first decrypts packet from my IPSEC peer and than apply ACL for that interface. It is out of my control what other packets may come from public Internet with source and destination addresses that match my IPSEC tunnel source and destination addresses. I was asking if anyone knows how to drop unencrypted packets NOT sourced from my IPSEC peer. Simply placing RFC 1918 ACL and not excluding hereby used private subnets would filter out everything even my tunnel data, and putting ESP/UDP500 ACL will have no effect on it????

I'm using IPSEC in tunnel mode with 3DES encryption and sha1 HMAC.

Thanks for your responses, comm@mt.net.mk

Have you tested this to see if it does allow unencrypted packets ?

The reason i ask is that on a pix/ASA if the traffic received matches a crypto map acl then it has to be encrypted otherwise it will be dropped. So packets could not be sent either from the peer or from someone pretending to be the peer unencrypted because the firewall will match these packets to a crypto map acl and see they are not encrypted.

I don't however know if the behaviour is the same on IOS which is why i wondered if you had actually seen that behaviour. I suspect it is but don't have the hardware available to test.

Jon

New Member

Re: Site to site VPN, unencrypted traffic ACL or ?

The ASA is not going to allow traffic coming from a different interface that it knows exists on a different interface.  For the router, uRPF should provide you the protecting you're looking for.  Both devices should process the packet in a similar fashion; interesting traffic that cannot be sent across a tunnel is dropped.

-skint

1582
Views
0
Helpful
6
Replies
CreatePlease login to create content