Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

DMZ Nat question

I have a setup like this (not real addresses--just testing here)

interface Ethernet0/0

nameif outside

security-level 0

ip address 12.200.200.1 255.255.255.0

!

interface Ethernet0/1

nameif inside

security-level 100

ip address 10.100.1.1 255.255.255.0

!

interface Ethernet0/2

nameif dmz

security-level 50

ip address 12.2.200.1 255.255.255.0

Now internal clients access the dmz, and machines in the dmz access the internal clients. Therefore, we have access-lists like this:

access-list dmz extended permit tcp host 12.2.200.10 host 10.100.1.9 eq 7205

but the internal host is also being natted to an address within the dmz, like this:

static (inside,dmz) 12.2.200.101 10.100.1.9 netmask 255.255.255.255

So how is the host on the dmz (12.2.200.10) accessing the internal host (10.100.1.9) using its private address? I thought ingress access lists always need to point to the public (global) address, not the private (that is the purpose).

It is working, I just don't know how

1 ACCEPTED SOLUTION

Accepted Solutions
Red

DMZ Nat question

No, The order of operation of your statics would be top to bottom, when the inside host access teh dmz, it doesnt need an ACL since higher to lower is alowed by default, then next it would check the static and if your general static is above the specific nat, then always general would be hit and packets would go on real ip's.

May be I am wrong in assuming, but if you can share the output of:

show run static

show run nat

show run global

show run access-list

It should be clear.

Another very good tool to verify "packet-tracer"

packet-tracer input inside tcp 10.100.1.9 23456 12.2.200.10 7205 detailed.

Thanks,
Varun Rao
Security Team,
Cisco TAC

Thanks, Varun Rao Security Team, Cisco TAC
3 REPLIES
Red

DMZ Nat question

HI Colin,

The static statementy that you have is always for bi-dircetional traffic, which means it is both for the traffic initiated from inside to dmz and for dmz to inside, that's y you are abe to ping both ways. The private ip is staticay now binded to your public ip, so no matter which te tarffic is intiated, it would always be binded to that public ip.

Thanks,
Varun Rao
Security Team,
Cisco TAC

Thanks, Varun Rao Security Team, Cisco TAC
New Member

DMZ Nat question

Varun:

Teachnically speaking, shouldn't the host on the dmz (12.2.200.10) only see the internal host (10.100.1.9) at its natted address (12.2.200.101)?

Ther is also a general NAT statement

static (inside,dmz) 10.0.0.0 10.0.0.0 netmask 255.0.0.0

So if the dmz host 12.2.200.10 tries to open a session on port 7205 to inside host 10.100.1.9, it will use the general NAT

but if the inside host has a static NAT to a dmz address to 12.2.200.101, the access list will have to reference that public address, and the general NAT will not be used yes?

Red

DMZ Nat question

No, The order of operation of your statics would be top to bottom, when the inside host access teh dmz, it doesnt need an ACL since higher to lower is alowed by default, then next it would check the static and if your general static is above the specific nat, then always general would be hit and packets would go on real ip's.

May be I am wrong in assuming, but if you can share the output of:

show run static

show run nat

show run global

show run access-list

It should be clear.

Another very good tool to verify "packet-tracer"

packet-tracer input inside tcp 10.100.1.9 23456 12.2.200.10 7205 detailed.

Thanks,
Varun Rao
Security Team,
Cisco TAC

Thanks, Varun Rao Security Team, Cisco TAC
355
Views
0
Helpful
3
Replies