How to REJECT instead of DROP?

Reply
Highlighted
Not applicable

How to REJECT instead of DROP?

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.


Accepted Solutions
Highlighted
L4 Transporter

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

View solution in original post


All Replies
Highlighted
L4 Transporter

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

View solution in original post

Highlighted
Not applicable

Hello,

any news on this topic ? I would to see this implemented, I have some special conditions where it would help.

Regards

Highlighted
Not applicable

I would also like the ability to select the type of drop manually.

Highlighted
L0 Member

We'd also like to select the type of deny. In some cases, we need to explicitity send RESET instead simply DROP the packet.

Highlighted
L6 Presenter

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.

Highlighted
L2 Linker

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 ?

Highlighted
Not applicable

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

Highlighted
Not applicable

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...

L0 Member

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.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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 Live Community as a whole!

The Live Community thanks you for your participation!