topic Re: Does vwire mode still send TCP reset after drop packet ? in General Topics

Does vwire mode still send TCP reset after drop packet ?

neilwu — Fri, 18 Apr 2014 06:13:17 GMT

I can see the traffic status show "reset-server" but I can not receive RST packet for this session on the server.

So I have a question, does vwire mode still send TCP reset after drop packet ?

Thank you.

Re: Does vwire mode still send TCP reset after drop packet ?

HULK — Mon, 21 Apr 2014 06:42:17 GMT

Hello Sir,

PAN firewall will not send a TCP RST packet after dropping a packet,( it will be silently drop).

FYI...

Currently, we can configure our security policy to allow or deny packets only. We do not have a third option called "Reject", when selected can send a TCP Reset, ICMP Destination Unreachable and so on. There is a feature request already submitted for the same,

Feature Request: reject action support in security rule

Request details: "Reject" action support in security policy rule setting so that PAN device would send TCP-Reset when rejecting session.

FR ID: 408

Thanks

Re: Does vwire mode still send TCP reset after drop packet ?

neilwu — Mon, 21 Apr 2014 09:03:35 GMT

Hi Hulk,

Thanks for your description.

But In Vulnerability Profile Actions, It's have this option.

so if I use vwire mode and set the Vulnerability Profile Actions to be reset-server, does it can still send RST ?

(In my LAB I don't receive the RST on my server)

Re: Does vwire mode still send TCP reset after drop packet ?

HULK — Mon, 21 Apr 2014 15:28:32 GMT

Hello Neilwu,

You are correct, It should send a TCP RST packet while droping the connection in V-Wire mode too.

Could you please set below mentioned parameter in that profile and take capture at both server and client.

DEFAULT ACTION : Reset-both

DIRECTION- Client-to-Server

AFFECTED SYSTEM: Cliend and server

Thanks

Re: Does vwire mode still send TCP reset after drop packet ?

skrall — Tue, 22 Apr 2014 17:56:59 GMT

If you are blocking an application, about 25% of the applications send a TCP RST. Unfortunately this list is not published.

If you suspect the Paloalto is sending the TCP reset, use this command to verify.

admin@PA-200>

admin@PA-200> show counter global | match RST

flow_action_close 7971 0 drop flow pktproc TCP sessions closed via injecting RST

flow_action_reset 239 0 drop flow pktproc TCP clients reset via responding RST

admin@PA-200>

Since the VWIRE is supposed to be transparent, when the PAN sends the RESET it spoofs the MAC address instead of using a PAN MAC address. The RST will apear to come from one of the next hop gateways. Whatever MAC address is used by the conversation and does not belong to the end point being reset.