Re: ALTQ for a process running on PF box

2006-07-12 Thread Karl O. Pinc


On 07/12/2006 02:33:12 AM, Daniel Hartmeier wrote:


We recently had a lenghty thread about the disadvantages (requiring
separate hosts) of lacking inbound queues


FWIW, I've put a separate OpenBSD host in front of my firewall/router
(which has several internal nics)
just for inbound queuing in order to support prioritization of
voip traffic and it's been working well for several months now.
(The real trick was hfsc queuing in rather than cbq.  I'm
sure priority based queuing would work as well.)
So, in practice, the tcp rate limiting successfully throttles
the sender that's on the far end of the narrow pipe.

One of these days I really will do some stats to prove it
works in the hopes that somebody will implement inbound queuing
so I can get rid of the extra box.
(Unless somebody's already planning to support inbound queuing?
Hope springs eternal.  :-)

Karl <[EMAIL PROTECTED]>
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein


Re: ALTQ for a process running on PF box

2006-07-12 Thread Daniel Hartmeier
On Wed, Jul 12, 2006 at 03:25:28PM +1000, Adam Clark wrote:

>   traffic going to hosts behing the box were showing in on pflog0, but
> no traffic to 10.17.10.254 shows. If I put a log-all on a line that
> matches the traffic on the $ext_if interface it shows that in deed
> traffic is heading towards 10.17.10.254.  Which means that even though
> the internal IP address is bound to the internal interface, the internal
> interface never sees traffic for 10.17.10.254 that can be filtered.
> Tcpdump does not show this either
> Is this true or is there a way perform what I need to do in another way?

Yes, that's normal, but you're not the first one to find this
surprising. :)

When the host, on one interface, receives a packet with a destination IP
address that matches one of the host's own IP addresses (assigned to any
interface), the packet is removed from the forwarding path and
dispatched to the local socket instead.

The destination address of the packet can influence what local socket it
is dispatched to (like when you have two different sockets bound to
different addresses), or it doesn't matter at all (when you have a
single socket bound to *), but the kernel doesn't simulate any passage
through $int_if. If it would try to send out the packet through $int_if,
that would mean writing an ethernet frame out onto $int_if's wire.

The simplest solution in your case is to move the bittorrent client
process onto a different host on the internal network, so inbound
packets to it really pass out on $int_if.

We recently had a lenghty thread about the disadvantages (requiring
separate hosts) of lacking inbound queues, see

http://groups.google.com/group/bit.listserv.openbsd-pf/browse_thread/thread/5de1c7731114bdae

If you have to move the process to another host, maybe it's a little
comforting that this is also the wise thing to do from a security
perspective. In the completely hypothetical case where the process has
a remotely exploitable hole, you don't risk the attacker using it to
gain root on the firewall and opening up its ruleset.

Daniel


ALTQ for a process running on PF box

2006-07-11 Thread Adam Clark
Hi,
  I have run into an interesting problem with setup.

I run Azureus on a FreeBSD box to handle downloading stuff for my
household.

We have only 128/512 DSL so it generally is saturated while torrents are
downloaded.  I want to setup Azureus to be low priority and try to limit
the effect of this problem.

I have setup outgoing ALTQ to give priority to ACKs, general traffic,
and then bittorrent last.  This is working fine.

internal_net="10.17.10.0/24"

altq on $ext_if priq bandwidth 120Kb queue { std_out , low_out ,
high_out , tcp_ack_out , ef_out }

queue low_out   priority 1 priq(red)
queue std_out   priority 2 priq(default)
queue high_out  priority 4
queue tcp_ack_out   priority 5
queue ef_outpriority 6

pass out on $ext_if proto tcp from ($ext_if) to any modulate state flags
S/SA queue ( std_out  , tcp_ack_out )
pass out quick on $ext_if proto udp from ($ext_if) to any port 53 keep
state queue ( high_out )
pass out on $ext_if proto { udp, icmp } from ($ext_if) queue ( std_out )

# Outgoing connections from Azureus always originate from port 51002
pass out on $ext_if proto {udp,tcp} from any to 10.17.10.254 port 51002
queue ( low_out ) keep state

# Incoming connections to Azureus is set to port 50002
pass in on $ext_if proto {udp,tcp} from any to 10.17.10.254 port 50002
queue ( low_out ) keep state


Inbound is a different story.  Given I can only set queues on for
outgoing traffic, I bound azureus to the internal IP of the FreeBSD box
(10.17.10.254).
Traffic is passing perfectly fine, azurues is working.

I have defined my queus as follows:

altq on $int_if cbq bandwidth 100Mb queue { internal , internet }
queue internal bandwidth 99.5Mb cbq(default)
queue internet bandwidth 500Kb { general , bittorrent }
queue general bandwidth 80% cbq(ecn)
queue bittorrent bandwidth 20% cbq(borrow red)
Basically, all but 500Kb is for internal traffic, then divide the 500Kb
queue into general and bittorrent, with bittorrent borrowing if
available.

pass in  on $int_if from $internal_net to any
pass in  on $int_if proto udp from any to any port $dhcpd_port
pass out on $int_if
pass out quick on $int_if from $internal_net to $internal_net queue
internal
pass out on $int_if from any to $internal_net queue general
pass out on $int_if proto { tcp, udp } from any to 10.17.10.254 port {
50002 , 51002 } queue bittorrent 


I was watching pfctl -s queue -v, and the bittorrent queue was not being
utilized, so I changed my:
pass out on $int_if
  to
pass log-all out quick on $int_if
  traffic going to hosts behing the box were showing in on pflog0, but
no traffic to 10.17.10.254 shows. If I put a log-all on a line that
matches the traffic on the $ext_if interface it shows that in deed
traffic is heading towards 10.17.10.254.  Which means that even though
the internal IP address is bound to the internal interface, the internal
interface never sees traffic for 10.17.10.254 that can be filtered.
Tcpdump does not show this either
Is this true or is there a way perform what I need to do in another way?





Adam Clark
Network Administrator

National Gallery of Victoria
PO Box 7259 St Kilda Road Vic 8004
Telephone: +61 3 8620 2369 
Fax: +61 3 8620 2565
www.ngv.vic.gov.au

Keep informed of the latest NGV exhibitions, special events and programs at The 
Ian Potter Centre: NGV Australia and NGV International by subscribing to [EMAIL 
PROTECTED], the NGV's free e-newsletter.

DISCLAIMER: This email and any files transmitted with it are confidential and 
intended solely for [EMAIL PROTECTED] If you are not the named addressee you 
should not disseminate, copy or alter this email. WARNING: Although National 
Gallery of Victoria has taken reasonable precautions to ensure no viruses are 
present in this email, the organisation cannot accept responsibility for any 
loss or damage arising from the use of this email or attachment.