[c-nsp] ASA Nat 0 != Statefull inspection... ?

Andrew Yourtchenko ayourtch at cisco.com
Fri Dec 1 07:33:56 EST 2006


...Apologies for jumping into the thread... Thought I might contribute a 
little bit and make a couple of things clearer :)

First, it is IMHO useful to separate the two things:

1) Access control
2) Address translation

The Access control is as follows:

1) if there is no ACL and the connection is outbound (higher security to 
lower security) => it is permitted.
2) if there is no ACL and the connection is inbound - it is denied
3) if there is an ACL then the connection will be permitted or denied 
following the same logic as usual ACL on IOS - either explicit permit, 
explicit deny, or implicit deny "past the end" of the ACL.

(digression: on the FWSM you *always* need an ACL to permit the traffic, 
likewise to do a ping to/from the box)

The address translation is as follows, in the order of decreasing 
preference. This assumes the absence of the policy NAT/outside NAT - which 
is the most common case.

1) nat (interfacename) 0 access-list foo

This disables the translation for the traffic ingress on interfacename 
which matches the ACL foo. NB: *also* it disables the translation for the 
mirrored traffic - so in some sense, it is "symmetric".

So having on a 2-interface (inside&outside) box:

access-list foo permit ip any any
nat (inside) 0 access-list foo

is identical to not have any translations at all.

2) static (intfI, intfO) O1.O2.O3.O4 I1.I2.I3.I4

this specifies that the incoming connection attempts from someone behind 
intfO, destined to the address O1.O2.O3.O4, will be forwarded to the real 
host I1.I2.I3.I4 which is sitting behind the interface intfI. Note that 
the interface selection is based the "static" command itself, so if in 
reality the host is behind the intfX - then you will get "no route" syslog 
and it won't work.

Note, that this translation rule is symmetric - it will also translate the 
outgoing connections from I1.I2.I3.I4 towards hosts on outside interface 
such that they appear to those hosts as if they come from O1.O2.O3.O4

3a) nat (intfI) X a.a.a.a m.m.m.m.
    global (intfO) X o.o.o.o[-o1.o1.o1.o1]

This creates the "funnel" with the "wide" end being the real hosts 
behind the "intfI" and the "small" end being the mapped addresses 
when connecting to the hosts behind the "intfO" interface.

This one is not symmetric as you can not figure out how you would create 
the xlate when attempting to connect to o.o.o.o address.
However, if the matching translation entry has already been created 
before (e.g. if you use NAT rather than PAT) - then if the access rules 
(see above) already permit it, the connection will 
succeed.

3b) nat (intfI) 0 x.x.x.x

This one declares that the hosts should not be translated.

However, it is not symmetric in a sense that you can not create the 
translation if there is no translation and the first packet arrives 
inbound. On the other hand, if you already had the first connection 
outbound and the identity (1:1) translation entry is there - then again 
everything depends on the access rules.

Now looking at your configuration:

Inside IP: 192.168.1.0/24
DMZ IP: 192.168.2.0/24
DMZ security 50
Inside security 100
------------------------------------------------
access-list inside_nat0 permit ip any 192.168.2.0 255.255.255.0
nat (inside) 0 access_list inside_nat0
------------------------------------------------

I see the rules for the translation (which basically says that there 
should be no translation for anything on inside going to 192.168.2.0, and 
for 192.168.2.0 going to anything on inside), but I do not see the access 
rules. I would be inclined to say that you have an inbound ACL on the DMZ 
interface which permits the traffic from DMZ to the addresses within the 
inside range - which is why the connection from the DMZ to 
inside host can establish.


Important thing to note, is that in 6.3 and before, if you did not have 
the translation rules, the connection would not go through, so in some 
sense the access-control and translation were blended together.

This behaviour has changed in 7.0 with the introduction of the 
nat-control, which allows to more distinctly split the functions of 
*translation* and *access-control*.

Hopefully this clarifies the things....


Also, if you have 7.2, and would like to verify the life of the packet, 
there is a "packet trace" feature, here's a sample output:

ciscoasa# packet-tracer input inside tcp 1.1.1.1 12345 2.2.2.2 80

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
%ASA-6-305011: Built dynamic TCP translation from inside:testing/12345 to 
outside:1.2.3.4/1024
%ASA-6-302013: Built outbound TCP connection 0 for outside:2.2.2.2/80 
(2.2.2.2/80) to inside:testing/12345 (1.2.3.4/1024)
%ASA-6-109001: Auth start for user '???' from testing/12345 to 2.2.2.2/80
%ASA-6-110001: No route to testing from 2.2.2.2
Additional Information:
MAC Access list

Phase: 2
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 3
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   0.0.0.0         0.0.0.0         outside

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: AAA
Subtype: aaa-auth
Result: ALLOW
Config:
aaa authentication match foo inside LOCAL
Additional Information:

Phase: 6
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
   match ip inside any outside any
     dynamic translation to pool 1 (1.2.3.4 [Interface PAT])
     translate_hits = 1, untranslate_hits = 0
Additional Information:
Dynamic translate testing/12345 to 1.2.3.4/1024 using netmask 
255.255.255.255

Phase: 7
Type: NAT
Subtype: host-limits
Result: ALLOW
Config:
nat (inside) 1 0.0.0.0 0.0.0.0
   match ip inside any outside any
     dynamic translation to pool 1 (1.2.3.4 [Interface PAT])
     translate_hits = 1, untranslate_hits = 0
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 0, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow

ciscoasa# %ASA-5-111008: User 'enable_15' executed the 'packet-tracer 
input inside tcp 1.1.1.1 12345 2.2.2.2 80' command.

ciscoasa#

This pretty much allows you to see the "life of the packet" just from CLI.

For doing similar analysis for the "real" traffic there is a "trace" 
option to our beloved "capture" command:

ciscoasa# capture test ?

   access-list      Capture packets that match access-list
   buffer           Configure size of capture buffer, default is 512 KB
   circular-buffer  Overwrite buffer from beginning when full, default is
                    non-circular
   ethernet-type    Capture Ethernet packets of a particular type, default is IP
   interface        Capture packets on a specific interface
   packet-length    Configure maximum length to save from each packet, default
                    is 68 bytes
   trace            Trace the captured packets
   type             Capture packets based on a particular type
   <cr>
ciscoasa#

And then you would do "show capture test trace" to see the similar details 
about your real packets.

While I have this opportunity, I'll piggyback this mail with the command 
"show asp drop" (which does not relate directly to the question but 
nonetheless you might find it interesting in real life) - which allows you 
to see the vast majority of the reasons the packets are being dropped by 
the packet path processing:

ciscoasa# show asp drop

Frame drop:
   No valid adjacency                                          3
   Interface is down                                           2

Flow drop:
ciscoasa#

This is from freshly booted semi-connected box - in real life you will 
have more of non-zero counters, and to verify whether your particular 
traffic is really dropped because of the given reason, you can perform as 
follows:

ciscoasa# capture drops type asp-drop ?

   acl-drop                                    Flow is denied by configured rule
   all                                         All packet drop reasons
   bad-crypto                                  Bad crypto return in packet
   bad-ipsec-natt                              Bad IPSEC NATT packet
   bad-ipsec-prot                              IPSEC not AH or ESP
   bad-ipsec-udp                               Bad IPSEC UDP packet
[2 pages of different reasons skipped] :)

You can clear the current counters using "clear asp drop".

I think this explanation and commands should help you to see what 
happens with the traffic that triggered the original question, feel free 
to unicast me if still something unclear.

cheers,
andrew

----
EMEA TAC
http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml


On Fri, 1 Dec 2006, Peter Krupl wrote:

>
> Hi,
>
> Thank you for your input.
>
> Do I have to think of the acccesslists having 3 outcomes, instead of the 2 outcomes I IOS ?
>
> In ios i always have a implicit deny at the end of my access list, which means that anything not explicitly permitted is denied.
>
> On the ASA I have 4 outcomes, which are:
> 1. Deny by explicit rule
> 2. Permit by explicit rule
> 3.1 Implicit permit from higher to lower security level.
> 3.2 Implicit deny from lower to higher security level.
>
> Is this correct ?
>
>
>
>
> Med venlig hilsen/Kind regards
> Peter Åris Krüpl
> Netværksspecialist
> Ventelo Webpartner
> Direkte:  35 25 47 54
>
>
>
>
> -----Original Message-----
> From: Voll, Scott [mailto:Scott.Voll at wesd.org]
> Sent: 30. november 2006 16:54
> To: Laurent Geyer; Peter Krupl
> Cc: cisco-nsp
> Subject: RE: [c-nsp] ASA Nat 0 != Statefull inspection... ?
>
> And use ACL's to open what needs to be open and close what needs to be
> closed.  I have yet to setup a PIX / ASA and not have some form of ACL
> on an interface.
>
> But the long and short, I believe Laurent is correct with the Static
> command.
>
> Scott
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Laurent Geyer
> Sent: Thursday, November 30, 2006 6:42 AM
> To: Peter Krupl
> Cc: cisco-nsp
> Subject: Re: [c-nsp] ASA Nat 0 != Statefull inspection... ?
>
> On 11/30/06, Peter Krupl <peter.krupl at ventelo.dk> wrote:
>
>>
>> I can connect form the inside to the DMZ without nat, which is what I
>> want.
>> But I can also connect from the DMZ  to the inside, which I not what I
>> wanted.
>
>
> I could be entirely of base here but I always thought that the correct
> way
> to permit traffic between interfaces with differing security levels was
> to
> define static translations. Technically 'nat 0' should work fine but
> I've
> personally always used static translations to facilitate that kind of
> communication.
>
> The only way that I could imagine DMZ hosts being able to establish
> connections to inside hosts if there is an access-group defined for the
> DMZ
> interface that permits traffic to the higher security network.
>
> This is how I would configure the ASA/PIX:
>
> static (<higher security int>,<lower security int>) <higher security
> network> <higher security network> netmask <higher security netmask>
>
> In your case this would like as follows:
>
> static (inside,DMZ) 192.168.1.0 192.168.1.0 netmask 255.255.255.0
>
> When configured in that fashion any host on inside (192.168.1.0/24) will
> have access to DMZ hosts, but hosts on the DMZ network will not be able
> to
> initiate connections to hosts on the inside interface.
>
>
> Is the ASA just an expensive piece of ...@#$!&@#$@! ?
>
>
> It's not cheap, that's for sure but I rather like the PIX/ASAs. Maybe
> I've
> simply grown accustomed to the PIX/ASA ways...
>
> - Laurent
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.430 / Virus Database: 268.15.3/561 - Release Date: 01-12-2006 06:36
>
>
> -- 
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.430 / Virus Database: 268.15.3/561 - Release Date: 01-12-2006 06:36
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>


More information about the cisco-nsp mailing list