- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-17-2014 11:13 PM
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.
04-21-2014 08:28 AM
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
04-20-2014 11:42 PM
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
04-21-2014 02:03 AM
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)
04-21-2014 08:28 AM
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
04-22-2014 10:56 AM
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.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!