I've continued to lab and read about this topic. Looking more carefully at the configuration guide, I believe the statement made "Similarly, if you enable outside dynamic NAT or PAT, then all outside traffic must match a NAT rule when it accesses an inside interface." is only relevant when you have nat-control enabled. The statement is in the section describing nat-control, specifically in the section describing how nat-control works in conjunction with dynamic outside nat.
I conclude that what I am seeing is normal. On Fri, Dec 21, 2012 at 11:26 AM, Joe Astorino <[email protected]> wrote: > Notes - There is an outside ACL inbound that permits all icmp traffic. > There is a default route pointing inside to match the route for > 1.1.1.1. The NAT configuration is as follows and nat-control is > disabled. The packets in the packet tracer do not match the ACL used > for the dynamic policy outside NAT. > My own analysis is this - It appears that if the traffic does NOT > match the dynamic policy outside NAT ACL, and nat-control is disabled > the traffic can flow through anyways. > > However, the config guide states "Similarly, if you enable outside > dynamic NAT or PAT, then all outside traffic must match a NAT rule > when it accesses an inside interface." My guess is that this rule > simply does not apply in the case of a policy dynamic outside NAT. > Thoughts? > > ASA# sh run | i nat|global > global (inside) 1 192.168.10.88-192.168.10.92 netmask 255.255.255.248 > global (inside) 1 192.168.10.93 > global (inside) 1 192.168.10.94 > nat (outside) 1 access-list DYN_NAT outside > > > ASA# packet-tracer input outside icmp 172.20.1.1 8 0 1.1.1.1 > > Phase: 1 > Type: ROUTE-LOOKUP > Subtype: input > Result: ALLOW > Config: > Additional Information: > in 0.0.0.0 0.0.0.0 inside > > Phase: 2 > Type: ACCESS-LIST > Subtype: log > Result: ALLOW > Config: > access-group acl_outside in interface outside > access-list acl_outside extended permit icmp any any object-group > ICMP_PERMITTED > object-group icmp-type ICMP_PERMITTED > icmp-object echo > icmp-object echo-reply > icmp-object time-exceeded > icmp-object unreachable > Additional Information: > > Phase: 3 > Type: IP-OPTIONS > Subtype: > Result: ALLOW > Config: > Additional Information: > > Phase: 4 > Type: INSPECT > Subtype: np-inspect > Result: ALLOW > Config: > class-map inspection_default > match default-inspection-traffic > policy-map global_policy > class inspection_default > inspect icmp > service-policy global_policy global > Additional Information: > > Phase: 5 > Type: INSPECT > Subtype: np-inspect > Result: ALLOW > Config: > Additional Information: > > Phase: 6 > Type: NAT > Subtype: host-limits > Result: ALLOW > Config: > nat (outside) 1 access-list DYN_NAT outside > match tcp outside 172.20.0.0 255.254.0.0 inside 65.54.62.0 > 255.255.255.128 eq 80 > dynamic translation to pool 1 (192.168.10.88 - 192.168.10.92) > translate_hits = 0, untranslate_hits = 0 > Additional Information: > > Phase: 7 > Type: IP-OPTIONS > Subtype: > Result: ALLOW > Config: > Additional Information: > > Phase: 8 > Type: FLOW-CREATION > Subtype: > Result: ALLOW > Config: > Additional Information: > New flow created with id 7551088, packet dispatched to next module > > Result: > input-interface: outside > input-status: up > input-line-status: up > output-interface: inside > output-status: up > output-line-status: up > Action: allow > > > On Wed, Dec 19, 2012 at 9:40 PM, Bruno Silva <[email protected]> wrote: >> Sorry Joe, >> >> Can you try running a packet-tracer so we can see how other traffic is >> matched? You say any other traffic from outside, so for example, if you run >> a packet-tracer like this: >> >> packet-tracer input outside tcp [source] 44444 [inside address] destination >> port >> >> what does it show you? Can you share that? Everytime I am stuck in a >> situation where I can`t really understand the flow that`s been taken I do >> that so I can try mapping either where I am doing something wrong or if >> that`s something darker that`s been hidden in the stars...=P >> >> Let`s break this with the packet-tracer and then analyze the situation...=D >> >> BR, >> Bruno Silva >> >> 2012/12/19 Joe Astorino <[email protected]> >>> >>> I appreciate that , but that does not make any sense to me per this >>> statement in the configuration guide: >>> >>> "Similarly, if you enable outside dynamic NAT or PAT, then all outside >>> traffic must match a NAT rule when it accesses an inside interface." >>> >>> On Wed, Dec 19, 2012 at 3:35 PM, Brian Hooker <[email protected]> wrote: >>> > To me it sounds like the statement from the configuration guide doesn't >>> > apply to outside NAT then, and I have no experience that is applicable to >>> > offer any other insights. >>> > >>> > Brian >>> > >>> > >>> > -----Original Message----- >>> > From: Joe Astorino [mailto:[email protected]] >>> > Sent: Wednesday, December 19, 2012 2:14 PM >>> > To: Brian Hooker >>> > Cc: OSL Security >>> > Subject: Re: [OSL | CCIE_Security] nat-control + dynamic NAT >>> > >>> > Thanks for replying Brian. When I say traffic originating on the >>> > outside interface passes through to the inside with no NAT rule or >>> > exemption I mean all other traffic that is not matched by the >>> > access-list. >>> > >>> > In other words, the dynamic policy outside nat is working as it should >>> > but in addition to that any other outside initiated traffic gets >>> > passed through the firewall fine without doing anything else. >>> > >>> > On Wed, Dec 19, 2012 at 1:57 PM, Brian Hooker <[email protected]> >>> > wrote: >>> >> When you say "traffic originating on the outside interface passes >>> >> through to the inside interface with no NAT rule or NAT exemption >>> >> configured" are you talking about traffic that matches access-list >>> >> DYNAMIC_POLICY_NAT or all traffic? I think "However, everything >>> >> continues >>> >> to work" statement is throwing me, implying that you do something that >>> >> should trigger things not to work. >>> >> >>> >> Brian >>> >> >>> >> >>> >> -----Original Message----- >>> >> From: Joe Astorino [mailto:[email protected]] >>> >> Sent: Wednesday, December 19, 2012 9:20 AM >>> >> To: OSL Security >>> >> Subject: Re: [OSL | CCIE_Security] nat-control + dynamic NAT >>> >> >>> >> Nobody? >>> >> >>> >> On Thu, Dec 13, 2012 at 4:18 PM, Joe Astorino >>> >> <[email protected]> wrote: >>> >>> So in 8.2 code we had this concept of nat-control that when enabled >>> >>> required a nat translation from higher to lower security level >>> >>> interfaces. Fine, no problems. When we disable this feature via "no >>> >>> nat-control" we no longer have that requirement. One caveat to that >>> >>> is that apparently even with nat-control disabled, if you enable >>> >>> dynamic nat/pat on an interface then you must either nat or bypass nat >>> >>> for all traffic sourced from the addresses in the dynamic nat. >>> >>> >>> >>> Specifically, in the configuration guide "Even with NAT control >>> >>> disabled, you need to perform NAT on any addresses for which you >>> >>> configure dynamic NAT" >>> >>> >>> >>> Now, I have a question. Does this apply to dynamic outside NAT, and >>> >>> specifically dynamic outside policy nat? The config guide states >>> >>> "Similarly, if you enable outside dynamic NAT or PAT, then all outside >>> >>> traffic must match a NAT rule when it accesses an inside interface." >>> >>> but does not mention anything about dynamic policy outside NAT. >>> >>> >>> >>> I ask because I see the following happening. I have nat-control >>> >>> disabled. >>> >>> >>> >>> ASA# sh run | i nat|global >>> >>> global (inside) 1 192.168.10.88-192.168.10.92 netmask 255.255.255.248 >>> >>> global (inside) 1 192.168.10.93 >>> >>> global (inside) 1 192.168.10.94 >>> >>> nat (outside) 1 access-list DYNAMIC_POLICY_NAT outside >>> >>> >>> >>> This configuration works great -- traffic matching the ACL >>> >>> "DYNAMIC_POLICY_NAT" is dynamic NAT' to the pool. When the pool is >>> >>> exhausted traffic is NAT/PAT. However, everything continues to work. >>> >>> In other words, traffic originating on the outside interface passes >>> >>> through to the inside interface with no NAT rule or NAT exemption >>> >>> configured. Is this the expected behavior? >>> >>> >>> >>> Thank You! >>> >>> >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> >>> >>> Joe Astorino >>> >>> CCIE #24347 >>> >>> http://astorinonetworks.com >>> >>> >>> >>> "He not busy being born is busy dying" - Dylan >>> >> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> >>> >> Joe Astorino >>> >> CCIE #24347 >>> >> http://astorinonetworks.com >>> >> >>> >> "He not busy being born is busy dying" - Dylan >>> >> >>> >> >>> >> ________________________________ >>> >> >>> >> CONFIDENTIALITY NOTICE: >>> >> This electronic mail message is intended exclusively for >>> >> recipient to which it is addressed. The contents of this message >>> >> and any attachments may contain confidential and privileged >>> >> information. Any unauthorized review, use, print, storage, copy, >>> >> disclosure or distribution is strictly prohibited. If you have >>> >> received this message in error, please advise the sender >>> >> immediately by replying to the message's sender and delete all >>> >> copies of this message and its attachments without disclosing >>> >> the contents to anyone, or using the contents for any purpose. >>> > >>> > >>> > >>> > -- >>> > Regards, >>> > >>> > Joe Astorino >>> > CCIE #24347 >>> > http://astorinonetworks.com >>> > >>> > "He not busy being born is busy dying" - Dylan >>> > >>> > ________________________________ >>> > >>> > CONFIDENTIALITY NOTICE: >>> > This electronic mail message is intended exclusively for >>> > recipient to which it is addressed. The contents of this message >>> > and any attachments may contain confidential and privileged >>> > information. Any unauthorized review, use, print, storage, copy, >>> > disclosure or distribution is strictly prohibited. If you have >>> > received this message in error, please advise the sender >>> > immediately by replying to the message's sender and delete all >>> > copies of this message and its attachments without disclosing >>> > the contents to anyone, or using the contents for any purpose. >>> >>> >>> >>> -- >>> Regards, >>> >>> Joe Astorino >>> CCIE #24347 >>> http://astorinonetworks.com >>> >>> "He not busy being born is busy dying" - Dylan >>> _______________________________________________ >>> For more information regarding industry leading CCIE Lab training, please >>> visit www.ipexpert.com >>> >>> Are you a CCNP or CCIE and looking for a job? Check out >>> www.PlatinumPlacement.com >> >> >> >> >> -- >> Bruno Silva >> Network Consultant >> Cisco CCNA/CCDA/CCNP/CCDP/CCSP Certified >> Arcsight Professional Certified - ACIA/ACSA > > > > -- > Regards, > > Joe Astorino > CCIE #24347 > http://astorinonetworks.com > > "He not busy being born is busy dying" - Dylan -- Regards, Joe Astorino CCIE #24347 http://astorinonetworks.com "He not busy being born is busy dying" - Dylan _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
