One of my favorite Cisco commands is the "packet-tracer" command of the Cisco ASA Firewall. Haven't you ever wanted to know if the ACL you just wrote will accomplish what you intended? And, how many times has somebody asked you, "Am I being blocked by the firewall?" Well, until now you just took an educated guess based on your running-config or looked in the log for their IP address while scratching your head. (You know I'm right, I know I'm right, heck we've all been there!)
Enough blabity blab, let's cut to the chase.
I've been tasked with finding out if tcp port 88 (Kerberos) is allowed out of the network. Since I know the source port and the IP of my webserver I can start to walk through the "packet-tracer" command. (Let's pretend like we've never used the command...)
ASA1# packet-tracer ?
input Ingress interface on which to trace packet
ASA1# packet-tracer input ?
Current available interface(s):
DMZ Name of interface Ethernet0/0
INSIDE Name of interface Ethernet0/1
GUESTS Name of interface Ethernet0/2
DMZ_2 Name of interface Ethernet0/3
ASA1# packet-tracer input INSIDE ?
icmp Enter this keyword if the trace packet is ICMP
rawip Enter this keyword if the trace packet is RAW IP
tcp Enter this keyword if the trace packet is TCP
udp Enter this keyword if the trace packet is UDP
ASA1# packet-tracer input INSIDE tcp ?
A.B.C.D Enter the Source address if ipv4
X:X:X:X::X Enter the Source address if ipv6
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 ?
<0-65535> Enter port number (0 - 65535)
aol
bgp
chargen
cifs
citrix-ica
cmd
ctiqbe
daytime
discard
domain
echo
exec
finger
ftp
ftp-data
gopher
.....
.....
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 88 ?
A.B.C.D Enter the destination ipv4 address
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 88 155.155.155.155 3028
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 DMZ
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group LAN_INCOMING in interface INSIDE
access-list LAN_INCOMING extended permit tcp host 10.10.10.10 any
Additional Information:
Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map classdefault
match any
policy-map global_policy
class classdefault
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (INSIDE,DMZ) source dynamic 10.10.10.10 262.1.2.3
Additional Information:
Dynamic translate 10.10.10.10/88 to 262.1.2.3/415
Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group DMZ_LEAVING out interface DMZ
access-list DMZ_LEAVING extended permit tcp host 10.10.10.10 any
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 54311482, packet dispatched to next module
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow
ASA1#
The bottom line is yes, 88 is allowed out from the 10.10.10.10 address.
Look at all the juicy info we can see, what access-lists and access-groups it had to traverse, the NAT statement in play, and the dynamic translation. Sweet!
(If you really want some verbose output try adding "detailed" to the end of the command.)
If we had failed it would have shown something like this...
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 22 155.155.155.155 3028
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 DMZ
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
See the "Implicit Rule" in the above output? This is the "implicit deny" that catches things you don't "explicitly allow." You've just seen it in play here.
Well, there you go. Have fun with this baby!
Please email this link to a pal. Thanks!
Enough blabity blab, let's cut to the chase.
I've been tasked with finding out if tcp port 88 (Kerberos) is allowed out of the network. Since I know the source port and the IP of my webserver I can start to walk through the "packet-tracer" command. (Let's pretend like we've never used the command...)
ASA1# packet-tracer ?
input Ingress interface on which to trace packet
ASA1# packet-tracer input ?
Current available interface(s):
DMZ Name of interface Ethernet0/0
INSIDE Name of interface Ethernet0/1
GUESTS Name of interface Ethernet0/2
DMZ_2 Name of interface Ethernet0/3
ASA1# packet-tracer input INSIDE ?
icmp Enter this keyword if the trace packet is ICMP
rawip Enter this keyword if the trace packet is RAW IP
tcp Enter this keyword if the trace packet is TCP
udp Enter this keyword if the trace packet is UDP
ASA1# packet-tracer input INSIDE tcp ?
A.B.C.D Enter the Source address if ipv4
X:X:X:X::X Enter the Source address if ipv6
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 ?
<0-65535> Enter port number (0 - 65535)
aol
bgp
chargen
cifs
citrix-ica
cmd
ctiqbe
daytime
discard
domain
echo
exec
finger
ftp
ftp-data
gopher
.....
.....
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 88 ?
A.B.C.D Enter the destination ipv4 address
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 88 155.155.155.155 3028
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 DMZ
Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group LAN_INCOMING in interface INSIDE
access-list LAN_INCOMING extended permit tcp host 10.10.10.10 any
Additional Information:
Phase: 3
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map classdefault
match any
policy-map global_policy
class classdefault
set connection decrement-ttl
service-policy global_policy global
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: NAT
Subtype:
Result: ALLOW
Config:
nat (INSIDE,DMZ) source dynamic 10.10.10.10 262.1.2.3
Additional Information:
Dynamic translate 10.10.10.10/88 to 262.1.2.3/415
Phase: 6
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group DMZ_LEAVING out interface DMZ
access-list DMZ_LEAVING extended permit tcp host 10.10.10.10 any
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 54311482, packet dispatched to next module
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow
ASA1#
The bottom line is yes, 88 is allowed out from the 10.10.10.10 address.
Look at all the juicy info we can see, what access-lists and access-groups it had to traverse, the NAT statement in play, and the dynamic translation. Sweet!
(If you really want some verbose output try adding "detailed" to the end of the command.)
If we had failed it would have shown something like this...
ASA1# packet-tracer input INSIDE tcp 10.10.10.10 22 155.155.155.155 3028
Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 0.0.0.0 0.0.0.0 DMZ
Phase: 2
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: INSIDE
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
See the "Implicit Rule" in the above output? This is the "implicit deny" that catches things you don't "explicitly allow." You've just seen it in play here.
Well, there you go. Have fun with this baby!
Please email this link to a pal. Thanks!
Hi, I like this feature but I'm trying to use this on a production node. My question to you is, when you don't know the source port # how would you use this feature?
ReplyDeleteThanks!
The source port from "packet-tracer's" perspective is always unimportant. It just needs to be an ephemeral port (something above 1024).
DeleteTypically in client-server communication, the client uses an ephemeral port to request something from the server. Different services are associated with different ports on the server. These are referred to as "listening ports." So, a web server usually "listens" on ports 80, 443 (http/https).
Hope that's clear as mud!!
Author
Good and Thank you
ReplyDeleteIn your examples, in phase 2 ACL, you get an allow in the top example, and that packet will be allowed to pass.
ReplyDeleteIn the bottom example using ssh, phase 2 gives you drop with no acl lines or acl name, and you get a drop as the end result.
I'm troubleshooting not being able to get an icmp request back from a host on the inside to the outside. I'm getting an allow in phase 2 with a line from the acl on the inside int, but getting a drop in the end for reason "(acl-drop) Flow is denied by configured rule" with no more explanation given to indicate which acl or rule.
What gives?
So, if I'm reading this right, you're pinging something external from an internal host. Also, you mention an acl on the inside interface. Check your acl applied to the outside interface and make sure you're allowing icmp traffic from the external destination.
ReplyDelete