Deny - Drop - Reject
Hi.
I'm still looking for a solution to a long lasting problem.
We want internal hosts to get immediately be notified if a connection attempt to the outer world is being blocked to avoid timeout problems.
For this we have a "TCP" rule with action "Denied (send reset)" at the end of the rule set ("Auto-Order Mode" disabled).
We can see from "Traffic Monitor" that the rule hits, however there is still a delay of about 15 seconds until the client recognizes that the connection is denied.
This can easily be verified by using telnet and opening a "blocked" port on an internet host.
Doing the same with an internal server on the same network segment with a port no service is listening on, we get an immediate response. Same works with no delay if using IP-tables on a Linux box.
How can we get this behaviour and what is the reason for the delay when doing this with a Firebox?
Thanks for your suggestions.
Answers
To answer your question, I set up a similar test policy, and the ran a Putty connection to my denied external IP addr.
Wireshark shows the reply from the firewall on the blocked packet, see below:
it sent retry packets, and eventually timed out. So it seems to me to meet your goal, that it is the application which needs to respond differently to [RST, ACK] instead of waiting for the timeout to be reached.
You would need to do a packet capture to see the difference between what returns from a local device and from the firewall to understand the difference in the results seen.
93 11.606676 10.0.1.2 1.2.3.4 TCP 66 53339 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
94 11.614659 1.2.3.4 10.0.1.2 TCP 56 22 → 53339 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
95 12.127968 10.0.1.2 1.2.3.4 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 53339 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
99 14.132480 10.0.1.2 1.2.3.4 TCP 66 [TCP Retransmission] [TCP Port numbers reused] 53339 → 22 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM
@Bruce_Briggs
Thanks for sharing you findings.
What seems strange to me is that we tested with Telnet and saw different behaviour for Firebox on the one and IP-tables or direct server connection on the other side.
So as client is the same the difference must be on the Firebox and server / IP-tables side.
Just thought that others already came across the same finding, that resetting a connection with Firebox ruleset does not prevent ugly timeouts on the client side and expect similar behaviour like with direct server connection to Windows or Linux boxes.
Regards
Just for the records:
I made some tests with Putty - same results.
Against a server I get an immediate "connection refused" - with Firebox there is a 15 seconds delay.
A packet capture should how the difference, one would hope.
Yes but would be of academic nature.
If WatchGuard would not change the behaviour the understanding would not be of any help. Maybe they will if they were aware of the fact. I assume that the "Denied (send reset)" was implemented to address timeout problems on the client side which is not the case.
Would also be interesting how other firewalls behave. Some have similar functionality. IP-tables also distinguishes between REJECT and DROP.
Maybe the reason it works as intended with IP-tables is the following:
"Some routers will respond with and ACK/RST on behalf of servers which are down."
https://serverfault.com/questions/157375/reject-vs-drop-when-using-iptables