[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