cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
278
Views
0
Helpful
2
Replies

Need help configuring somewhat complex nat

jkrawczyk
Level 1
Level 1

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:

static (dmz,outside) 172.20.1.44 172.20.1.44 netmask 255.255.255.255

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 99.99.99.62 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?

Regards

Jeff

access-list OUTSIDE_IN permit tcp 192.168.1.0 255.255.255.0 host 172.20.1.44 eq 3389

access-list WWW permit tcp host 172.20.1.44 any eq 80

access-list VPN-NONAT permit tcp host 172.20.1.44 192.168.1.0 255.255.255.0

ip address outside 99.99.99.1 255.255.255.192

ip address dmz 172.20.1.1 255.255.255.0

global (outside) 30 99.99.99.62 netmask 255.255.255.192

nat (dmz) 0 access-list VPN-NONAT

nat (dmz) 30 access-list WWW

2 Replies 2

Fernando_Meza
Level 7
Level 7

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 hope it helps .. Please rate it if it does !!!

Hi;

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.

Regards