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
_______________________________________________
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
