If you use a tunnel interface, then you can put an ACL directly on it. If you don't, then think about it, but if you allow only the traffic that should be authorized in your tunnel on your crypto ACL, then I think traffic not matching will be dropped, or at least it won't be encapsulated then your ISP will drop it.
The problem is the other end of the tunnel is not in our control.
The VPN is currently setup using (what I call) the standard VPN setup, therefore I am reluctant, even unsure, as to whether the tunnel interfaces would help us, as we have no shared IP ranges to use as the tunnnel interface IP address.
Also, restricting the traffic on the phase 2 ACL doesnt seem to work. Do you, or anyone else have any other ideas?
Hi, I think you can still use a tunnel interface even if the other end use a crypto map, but that should be tested before.
Other solutions I see would be to put an ACL on the insides interfaces, as once the traffic is tunneled, you won't be able to filter it on the outside if, but you can still modify the crypto acl to cipher only one part of the traffic, and drop it with an outside ACL.
Another solution would be to use PBR to null0 interface for traffic that shouldnt leave by the tunnel.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...