Please consider the below configuration, which shows only relavant commands to my inquiry. DMZ host 172.20.1.44 will nat to a outside global pat address if ACL WWW is matched or will not nat of the destination is a VPN destination network. Currently this works.
The problem that I have is the remote systems on network 192.168.1.0 needs to access my dmz host at IP 172.20.1.44 using rdp. In order for this to occur, I need two statements. The first I have, the ACL OUTSIDE_IN, but I do not have a static such as:
My concern is that if I put this static in place, I will loose access to the internet from my dmz host.
Does anyone know how I can configure this to allow dmz traffic to traverse a global 220.127.116.11 address, and if destined for the VPN tunnel to remain 172.20.1.44 and allow incoming traffic from 192.168.1.0 255.255.255.0 to hit my dmz host at IP 172.20.1.44?
Hi .. perhaps you can try by adding the DMZ host(s) to the IPsec interesting traffic for the respective destination VPN. You will need to configure similar access at the other end. You will also need to bypass nat for traffic destined to the DMZ host.
Inother words you need:
On hub site
1.- Bypass nat from 172.20.1.44 to 192.168.1.0
2.- Add 172.20.1.44 to the IPsec interesting traffic. You should have a crypto map with a match instruction on it .. that access-list needs to be modified.
3.- Make sure 172.20.1.44 knows how to reach 192.168.1.0
On the remote VPN site:
1.- Bypass nat from 192.168.1.0 to 172.20.1.44
2.- add 172.20.1.44 to the IPsec interesting traffic ..You shoudl have a crypto map with a match instruction on it .. that access-list needs to be modified.
3.- Make sure teh internal hosts know the way back to 172.20.1.44
I do have my VPN configured properly as you mention.
There is no problem going out from 172.20.1.44 to the internet or into the VPN out to the spoke site.
When the spoke site packet returns, if the dynamic translation is still in the cache, then the spoke network 192.168.1.0 will be able to accress host at the hub at IP 172.20.1.44. But, if the translation clears over time, I woiuld have to initiate a ping from 172.20.1.44 yo 192.168.1.X so that the dynamic translation would allow for ingress traffic flow.
Any more ideas? I'm considering opening a case with tac.
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...