Site to site VPN, unencrypted traffic ACL or ?

Unanswered Question
Apr 25th, 2010

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
skint Sun, 04/25/2010 - 15:44

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

Federico Coto F... Sun, 04/25/2010 - 16:29

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.

Sergej Georgievski Sun, 04/25/2010 - 21:58

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, [email protected]

Jennifer Halim Sun, 04/25/2010 - 22:12

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.

Jon Marshall Mon, 04/26/2010 - 00:22

[email protected]

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, [email protected]

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

skint Mon, 04/26/2010 - 05:37

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

Actions

This Discussion

Related Content