03-27-2009 01:15 PM - edited 03-11-2019 08:11 AM
I don't believe I will, but when creating acls in the dmz, I'll have to all the device in the dmz access to the internal network.
permit ip dmz-host internal-host
Why don't I have to create an entry for the dmz host on an acl that's applied to the inside interface, or will I?
I've got an existing ACL on my inside interface. Won't I need to allow the dmz to talk to it??
Thanks,
John
Solved! Go to Solution.
03-27-2009 01:55 PM
John
2 different things really.
Assuming you have not disabled NAT with "no nat-control" then for a packet to be allowed from a lower to a higher security interface you need
1) An acl that permits that access
2) a static NAT translation
So for the dmz or outside to access the inside there would have to be a NAT. But that alone would not allow access. You would need an acl on the relevant interface ie. dmz or outside.
Now going back to previous post -
"traffic initiated from the dmz to the inside is not checked against that inside acl."
I should have been more specific. Assuming the acl on the inside is applied inbound on the interface then what i wrote is correct because the return traffic from the inside to the dmz is checked against the firewall state table.
But if the inside acl was applied outbound on the interface then traffic initiated from the DMZ would be checked against it.
Jon
03-27-2009 01:45 PM
John
Not sure i fully understand. With a pix/ASA it's all to do with where the connection was initiated from. In addition by default traffic is allowed to go from a higher to lower security interface without an acl.
So if you have no acl on the inside interface then
1) traffic should be allowed from inside to the dmz and the return traffic will be allowed back in.
2) traffic initiated from the dmz would need an acl on dmz interface. But this traffic once allowed thru that acl would be allowed back to the dmz.
If you apply an acl on your inside interface
1) traffic from inside to anywhere needs to be explicitly permitted by the acl
2) traffic initiated from the dmz to the inside is not checked against that inside acl.
It's all to do with the stateful nature of firewalls. Note the above applies to TCP/UDP traffic. So if you used GRE for example, this is not stateful and you would need to allow it both ways.
Jon
03-27-2009 01:49 PM
"traffic initiated from the dmz to the inside is not checked against that inside acl."
The statement above that you wrote is what I was wondering. I know that lower security levels aren't allowed to higher security levels without a static and an acl. I was looking at it like outside interface (unknown traffic) to inside interface, and how the outside needs the acl.
Since the dmz (unknown traffic) to the inside (compared to outside), I wondered if the inside needed an ace to allow the dmz subnets into it, but I realized that this is where the static translations come from (at least I think).
Thanks,
John
03-27-2009 01:55 PM
John
2 different things really.
Assuming you have not disabled NAT with "no nat-control" then for a packet to be allowed from a lower to a higher security interface you need
1) An acl that permits that access
2) a static NAT translation
So for the dmz or outside to access the inside there would have to be a NAT. But that alone would not allow access. You would need an acl on the relevant interface ie. dmz or outside.
Now going back to previous post -
"traffic initiated from the dmz to the inside is not checked against that inside acl."
I should have been more specific. Assuming the acl on the inside is applied inbound on the interface then what i wrote is correct because the return traffic from the inside to the dmz is checked against the firewall state table.
But if the inside acl was applied outbound on the interface then traffic initiated from the DMZ would be checked against it.
Jon
03-27-2009 02:00 PM
Well, I learned something. I've always applied my acls inbound, and if you look at it like a router, it makes more sense.
Thanks!
John
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