Tghanks for the quick response. I'm not sure I udnersand your suggestion though. Let me expand my example to cover my real-world scenario so I can properly assess your suggestion.
R1 and R2 have a second interface each. Its actualyl the traffic from these interfaces that I want to encrypt, not actually the traffic between the tunnel endpoints. See below output for calrification:
R1(config-ext-nacl)#do sho ip int br Interface IP-Address OK? Method Status Protocol FastEthernet0/0 220.127.116.11 YES manual up up FastEthernet0/1 18.104.22.168 YES manual up up
R2#sho ip int br Interface IP-Address OK? Method Status Protocol FastEthernet0/0 22.214.171.124 YES manual up up FastEthernet0/1 126.96.36.199 YES manual up up
What I want is for all traffic between 2.0.0..0/24 and 188.8.131.52/24 to be encrypted. What would my ACLs have to look like to achieve this?
You're suggesting that by encrypting traffic peer to peer I encrypto the IP header of the packet and as such it is unreadable by the peer in on receipt? That would make some sense, but thats wy I enabled tunnelling so that it would place an additional (albeit redundant) IP header over the encrypted traffic.. but then I spose the peer is expecting thr trafic encrypted so that wouldnt work - altough it didnt through the usual "expected encrypted packet" error.
I'll take your word for it, without a whiteboard and a good half an hour it might be a bit tough to explain in any more detail.
Thanks for all your help though, much appreciated.
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...