Ive run into on at least two occasions where a customer has reched my tcp connection limit and the connections to them never drop. they stay active in the the firewall connections area.
right now i have the action set to reject-tcp reset. is that incorrect? should i be using drop instead? the default timeout values place a drop @ 60 seconds the tcp-reset should be instintainous shouldnt it?
here is the rule in all its printed glory:
2 ;;; tcp connection limit
chain=forward action=reject reject-with=tcp-reset protocol=tcp connection-limit=60,32
try action=reject, but reject-with=icmp-something
so in theory, the connection should die immediatly since it was rejected. ill try it with icmp port unreachable.
so it looks like the connections are still sticking in the firewall even tho the host has long since been turned off.
I was using reject icmp: host unreachable.
The wierd thing im noticing… howcome these tcp connections have a 24 hour timeout? thats not normal is it?
should i try using drop instead of reset?
The difference between reject and drop is whether the requesting ip is notified about the failure. I use drop if there is a chance the source ip has bad intentions. If you feel that is the case, use action=drop. If it is a trusted network, then use action=reject.
typically filesharing or viral. next time i see it ill try changing the rule to drop and see what happens.
According to some texts it is better to use reject instead of drop in case of failure…because DROP could kill your router…and make it unreachable
Sometimes tarpit can be effective also.
under attack tarpit made my router unresponsive and internet went down…for local users, not for attacker…
what kind of attack? brute? DDOS?
limiting may not be so usefull for DDOS. as i saw in one of thread before
I am not sure, but seemed like DDOS…