|
|
comp.unix.bsd.openbsd.misc |
Kesas > I haven't heard of any firewall that successfully could. If you're Yes, if you're being DDoSed then incoming traffic shaping won't do
> being DDOSd, you're being DDOSd. No firewall with any special set
> of rules can improve your bandwidth in that case. If the pipe is
> filled, it's filled.
anything, but if you're using TCP streams from cooperative hosts you
can shape incoming traffic very effectively; you drop packets, sender
realises packets are getting lost, sender slows down sending packets.
It works when you use the hack of queueing on the internal interface
when you're using NAT, it clearly works, so why can't you do it on a
single interface?
> I don't use IPFW, so I can't speak on its specific technical merits. There's no magic about it :-P
> Maybe you should ask the IPFW devs how they're able to perform this
> magic. Last I heard, the PF devs were technicians, engineers, and
> scientists, not a single magic-user among them. (IRL anyhow. :-))
> I think that you _can_ configure PF to do this, but I believe that As I explained above shaping download traffic works great, but only
> what the developers are trying to say is, `What's the point'? We're
> talking about trying to control traffic _before_ it hits your
> interface. Even if the remote sending host is well-behaved enough
> to slow down its sending rate, it still has to interact with PF
> before PF can decide whether to pass the packets, drop the packets,
> or tell the sending host to `bugger off'.
> So, you can queue the download traffic, but that really has a minor
> to no effect on traffic outside of your firewall. The queuing
> actually occurs on _your_ side of the external interface.
using the two interface hack. People on other boards are telling me I
should put another box beetween the LAN and the internet so I can use
the two interface hack for all traffic, but this seems stupid; if it
works over two interfaces so it can certainly work on one interface, so
why doesn't it?