- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
07-06-2010 07:58 AM
Try as I might, I cannot find a way to do the equivalent of the venerable iptables target REJECT --with-icmp-ureachable or --with-tcp-reset for basic firewalling on a 4020.
This is handy for bouncing internal clients quickly, whereas DROP is better to make things slower for adversaries who are scanning our nets from outside.
For example. If I want to prevent smtp/ntp/dns attempts for our internal clients, thus forcing them through the relevant internal services, I don't expect them to have to wait for a timeout, when a simple reject rule can speed things along for them.
It seems the two targets available for basic layer 3 firewalling are simply allow, or drop. Why no reject?
I hope someone knows how. If this is the wrong forum I apologise, but I expect this is a missing feature. I feel it's quite a basic essential.
07-13-2010 01:16 PM
Priyan -
The deny action used in a security policy will either ‘drop’ or ‘drop-reset’ based on the app being used in the policy.
For most browser-based apps, it is drop-reset - this prevents the browser from spinning while retrying.
For client-server apps that are based on http (or other protocols that we have decoders for), we generally use drop-reset if the app is considered harmless. We don't currently support icmp-host-unreachable for udp/icmp but it is on the cards.
Srinivas
07-13-2010 01:16 PM
Priyan -
The deny action used in a security policy will either ‘drop’ or ‘drop-reset’ based on the app being used in the policy.
For most browser-based apps, it is drop-reset - this prevents the browser from spinning while retrying.
For client-server apps that are based on http (or other protocols that we have decoders for), we generally use drop-reset if the app is considered harmless. We don't currently support icmp-host-unreachable for udp/icmp but it is on the cards.
Srinivas
07-13-2011 01:27 AM
Hello,
any news on this topic ? I would to see this implemented, I have some special conditions where it would help.
Regards
02-07-2012 11:51 AM
I would also like the ability to select the type of drop manually.
03-19-2012 12:32 AM
We'd also like to select the type of deny. In some cases, we need to explicitity send RESET instead simply DROP the packet.
03-19-2012 12:51 AM
I would also like to place myself in this feature-line regarding ability to (per security rule) define if the traffic should be denied (drop) or rejected (drop-reset). Perhaps it could be called just "deny" vs "deny-rst" in the gui.
Would also be nice to be able to define if icmp-unreachable should be sent or not.
06-27-2012 06:50 AM
I also need the ability to select the type of drop manually.
"We don't currently support icmp-host-unreachable for udp/icmp but it is on the cards."
Any news about this feature ?
07-09-2012 05:42 AM
The same here...
It is disastrous how much time I've spend on debugging timeouts...
tcp-reject from internal net to external/between zones is a must !
Best regards,
Pawel
07-30-2012 12:07 PM
I second this. This is a huge oversight on part of Palo Alto. One neat feature of ScreenOS is the ability to specify RST on a per-zone basis...
01-23-2014 04:26 PM
You mention that there is work in progress to provide further options for reject. I didn't see anything specific mentioned in the 6.0 release notes. Can you tell me whether there have been any improvements upon this? We also require the ability to set a specific reject for a particular policy. We'd like to let some things remain drop, but for specific subnets that we still want to block, we'd like to do a reject.
01-24-2014 10:10 AM
What happens when the drop rule has both application and service set to "any"? Drop or reject?
08-06-2014 02:02 AM
Hello,
Any news about this topic?
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!