topic Re: Trying to troubleshoot with Packet Trace in Network Security

Trying to troubleshoot with Packet Trace

Shane Riley — Tue, 12 Mar 2019 02:31:56 GMT

Hi Folks,

Having a bit of issues, i am trying to access a http/https server from the Guest interface (10.10.10.0/24) to the Inside interface (192.168.190.0/24)

I can ping the server, but when i try to access it with http/https.. no luck

So when i am on the 192.168.190.0/24 network i have no problem using http/https to the server.

Inside: Security level 100 (VLAN1)

Guest: Security level 40 (VLAN23)

ASA version: 8.0(4)

ASDM version: 6.1(5)57

I have attached an image when trying to troubleshoot the access list entry from the 10.10.10.1 to 192.168.190.1.

But for some reason the packet is dropped..So i am wondering if i am able to ping the server when i am on the 10 network. Well then the rule shouldn't be wrong right?

Any tips and tricks, i prob missed something

Thanks

Shane

Re: Trying to troubleshoot with Packet Trace

Jouni Forss — Thu, 29 Aug 2013 06:28:32 GMT

Hi,

I would much rather see the "packet-tracer" output taken from the CLI (or the CLI of the Tools menu in ASDM)

This gives a lot clearer output as the GUI doesnt show all the information.

Since the IP addresses you are using are both .1 , are they by any chance IP addresses of the ASA interfaces? If they are then this result is expected as ASA doesnt allow this.

If they are the actual IP addresses of the devices on the network then they are ok to use naturally.

In that case the output in the picture would seem to mean that you dont have an ACL rule allowing that traffic.

The "packet-tracer" commands CLI format is

packet-tracer input Guest tcp 10.10.10.1 12345 192.168.190.1 443

packet-tracer input Guest tcp 10.10.10.1 12345 192.168.190.1 80

- Jouni

Re: Trying to troubleshoot with Packet Trace

Jouni Forss — Thu, 29 Aug 2013 06:43:45 GMT

Hi,

Think I put the wrong interface in the "packet-tracer" commands. I edited the above post with the correct interface name.

- Jouni

Re: Trying to troubleshoot with Packet Trace

Shane Riley — Thu, 29 Aug 2013 07:19:35 GMT

Yes sorry about that, you were right the output in the CLI is much better

Yeah and your were right about the .1, my bad Feel stupid..

I tried with 10.10.10.10 to 192.168.190.27 and the packet was allowed

Here is the output from

# packet-tracer input inside tcp 10.10.10.10 12345 192.168.190.27 443

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 4

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.190.0 255.255.255.0 inside

Phase: 5

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

So i see that its drop at Phase 5..

I added another rule on the inside interface

Allow packet from the guest network to 192.168.190.27 which is the https server.

Get the output:

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 4

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.190.0 255.255.255.0 inside

Phase: 5

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group Outgoing in interface inside

access-list Outgoing extended permit tcp 10.10.10.0 255.255.255.0 host 192.168.190.27 object-group DM_INLINE_TCP_4

object-group service DM_INLINE_TCP_4 tcp

port-object eq www

port-object eq https

Additional Information:

Phase: 6

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT-EXEMPT

Subtype: rpf-check

Result: ALLOW

Config:

match ip inside 192.168.190.0 255.255.255.0 inside 10.10.10.0 255.255.255.0

NAT exempt

translate_hits = 0, untranslate_hits = 1

Additional Information:

Phase: 8

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside) 1 192.168.190.0 255.255.255.0

match ip inside 192.168.190.0 255.255.255.0 inside any

dynamic translation to pool 1 (No matching global)

translate_hits = 0, untranslate_hits = 0

Additional Information:

Phase: 9

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,outside) x.x.x.x 192.168.190.27 netmask 255.255.255.255

match ip inside host 192.168.190.27 outside any

static translation to x.x.x.x

translate_hits = 739399, untranslate_hits = 2012692

Additional Information:

Phase: 10

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 11

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 36837297, packet dispatched to next module

Phase: 12

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.190.27 using egress ifc inside

adjacency Active

next-hop mac address 000c.2946.f8e5 hits 85

Result:

input-interface: inside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Trying to troubleshoot with Packet Trace

Jouni Forss — Thu, 29 Aug 2013 07:23:00 GMT

Hi,

I think I put the wrong interface in the "packet-tracer" commands as I mentioned after my original reply.

The 10.10.10.10 is behind Guest interface to my understanding so it should be used in the "packet-tracer" command.

- Jouni

Re: Trying to troubleshoot with Packet Trace

Shane Riley — Thu, 29 Aug 2013 07:28:15 GMT

Yes did the:

packet-tracer input Guest tcp 10.10.10.10 12345 192.168.190.27 443

Phase: 1

Type: FLOW-LOOKUP

Subtype:

Result: ALLOW

Config:

Additional Information:

Found no matching flow, creating a new flow

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 192.168.190.0 255.255.255.0 inside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group Guest_access_in in interface Guest

access-list Guest_access_in extended permit ip 10.10.10.0 255.255.255.0 any

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT-EXEMPT

Subtype: rpf-check

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

nat (Guest) 1 10.10.10.0 255.255.255.0

match ip Guest 10.10.10.0 255.255.255.0 outside any

dynamic translation to pool 1 (x.x.x.x [Interface PAT])

translate_hits = 2933, untranslate_hits = 902

Additional Information:

Phase: 7

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside) 1 192.168.190.0 255.255.255.0

match ip inside 192.168.190.0 255.255.255.0 Guest any

dynamic translation to pool 1 (No matching global)

translate_hits = 0, untranslate_hits = 0

Additional Information:

Phase: 8

Type: NAT

Subtype: host-limits

Result: ALLOW

Config:

static (inside,outside) x.x.x.x 192.168.190.27 netmask 255.255.255.255

match ip inside host 192.168.190.27 outside any

static translation to x.x.x.x

translate_hits = 739558, untranslate_hits = 2013350

Additional Information:

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 36862249, packet dispatched to next module

Phase: 11

Type: ROUTE-LOOKUP

Subtype: output and adjacency

Result: ALLOW

Config:

Additional Information:

found next-hop 192.168.190.27 using egress ifc inside

adjacency Active

next-hop mac address 000c.2946.f8e5 hits 553

Result:

input-interface: Guest

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Trying to troubleshoot with Packet Trace

Jouni Forss — Thu, 29 Aug 2013 07:42:56 GMT

Hi,

Would seem to me that the traffic is allowed through the firewall.

It doesnt seem to list any NAT that is actually applied to the traffic. Or perhaps the "inside" interface has a NAT0 configuration for traffic between the 2 networks.

Have you made sure that there is nothing on the actual host/server blocking the connection? Like some software firewall? It would seem the defatult gateway configurations and such are correct as you can ping the server.

Have you checked on the actual server that its listening on ports TCP/80 and TCP/443

If its a Windows machine I think you can use the following command in the command prompt

netstat -a

- Jouni

Re: Trying to troubleshoot with Packet Trace

Shane Riley — Thu, 29 Aug 2013 11:19:48 GMT

Yes it seems that way

Well i checked with the firewall on the windows server and it should allow the connection.. I also turned off the firewall and tried, but still no luck..

I did the netstat -a

Here is some output..the state is syn_received?

TCP 192.168.190.27:443 10.10.10.139:61808 SYN_RECEIVED

TCP 192.168.190.27:443 10.10.10.176:53373 SYN_RECEIVED

TCP 192.168.190.27:443 10.10.10.176:53374 SYN_RECEIVED

TCP 192.168.190.27:443 10.10.10.185:62246 SYN_RECEIVED

Also when i check the log on the asa..

Teardown TCP connection 37034091 for Guest:10.10.10.139/61838 to inside:192.168.190.27/443 duration 0:00:00 bytes 0 TCP Reset-O

Trying to troubleshoot with Packet Trace

Jouni Forss — Thu, 29 Aug 2013 12:09:32 GMT

Hi,

The Reset-O would seem to indicate that the host behind the lower "security-level" has sent a TCP Reset for the connection. Don't know why though.

- Jouni

Re: Trying to troubleshoot with Packet Trace

Shane Riley — Fri, 30 Aug 2013 11:12:49 GMT

Hi,

hmm ok, i will troubleshoot some more Thanks for your help buddy

/Shane

Re: Trying to troubleshoot with Packet Trace

Harvey Ortiz — Sat, 31 Aug 2013 04:31:44 GMT

Hi shane,

Please provide:

show run nat-control

sh run nat

sh run global

sh run interface

I see that you have this access list:

access-list Guest_access_in extended permit ip 10.10.10.0 255.255.255.0 any

But if Nat control is enabled, you would need to configure a nat rule for this connection.

Please provide those outputs.

Regards,

Harvey.

Re: Trying to troubleshoot with Packet Trace

Shane Riley — Mon, 02 Sep 2013 06:19:22 GMT

Hi,

#sh run nat-control

no nat-control

#sh run nat

nat (inside) 0 access-list NoNAT

nat (inside) 1 192.168.190.0 255.255.255.0

nat (inside) 1 192.168.191.0 255.255.255.0

nat (dmz) 0 access-list NoNAT_DMZ

nat (dmz) 1 192.168.192.0 255.255.255.0

nat (Tele) 0 access-list Tele_nat0_outbound

nat (Guest) 0 access-list Guest_nat0_outbound

nat (Guest) 1 10.10.10.0 255.255.255.0

#sh run global

global (outside) 1 interface

#sh run interface

interface Vlan1

nameif inside

security-level 100

ip address 192.168.190.2 255.255.255.0

interface Vlan2

nameif outside

security-level 0

ip address x.x.x.x 255.255.255.240

interface Vlan3

nameif dmz

security-level 50

ip address 192.168.192.1 255.255.255.0

interface Vlan13

nameif Tele

security-level 100

ip address 10.0.0.1 255.255.255.0

interface Vlan23

nameif Guest

security-level 40

ip address 10.10.10.1 255.255.255.0

interface Ethernet0/0

switchport access vlan 2

interface Ethernet0/1

switchport access vlan 23

interface Ethernet0/2

interface Ethernet0/3

switchport trunk allowed vlan 1,3

interface Ethernet0/4

interface Ethernet0/5

switchport access vlan 13

interface Ethernet0/6

switchport access vlan 3

interface Ethernet0/7

switchport access vlan 3

Trying to troubleshoot with Packet Trace

Jouni Forss — Mon, 02 Sep 2013 06:25:52 GMT

Hi,

Have you configured NAT0 between Guest/inside interfaces? As we cant see the ACL configuration used in the NAT0.

Do you have any "static" configurations? You can use the command "show run static" to list them. We could try Static Identity NAT unless one is already configured.

It would be

static (inside,Guest) 192.168.190.0 192.168.190.0 netmask 255.255.255.0

- Jouni

Trying to troubleshoot with Packet Trace

Shane Riley — Mon, 09 Sep 2013 08:44:12 GMT

Hi,

#sh run static

static (inside,outside) x.x.x.x 192.168.190.27 netmask 255.255.255.255

static (dmz,outside) x.x.x.x pfdsesrv05 netmask 255.255.255.255

static (dmz,outside) x.x.x.x x.x.x.x netmask 255.255.255.255

static (inside,outside) x.x.x.x 192.168.190.73 netmask 255.255.255.255

So i added the static entry:

static (inside,Guest) 192.168.190.0 192.168.190.0 netmask 255.255.255.0

Trying to troubleshoot with Packet Trace

Shane Riley — Wed, 02 Oct 2013 07:07:52 GMT

Hey Folks,

Still having the problem, getting alot of TCP Reset-0 messages in the log. What can be the cause?

Cheers

Shane