05-25-2012 11:25 AM - edited 03-11-2019 04:11 PM
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
Solved! Go to Solution.
05-25-2012 12:51 PM
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
05-25-2012 12:06 PM
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
05-25-2012 12:21 PM
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?
05-25-2012 12:51 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide