[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using state and routing inbound traffic




On 08/05/2005 03:43:07 PM, Daniel Hartmeier wrote:
On Fri, Aug 05, 2005 at 06:04:08PM +0000, Karl O. Pinc wrote:

If I understand it correctly, you're asking whether you could use
route-to loopback and queueing on loopback to queue incoming packets
(on
their way through the firewall) on one central interface (lo0).

Exactly, although I'm using lo0 for a ftp-proxy rdr so I figured I'd just make and use a lo1, 127.0.0.2

The
lack
of responses may indicate that you're simply the first person to ever
attempt this, and there is noone who can tell you in advance whether
it's going to work out exactly as you want it to.

I was also hoping to get some comment from somebody who'd tried queueing inbound traffic from a WAN link using a 2 port box to see how successful they were in improving perceived bandwidth. Not a lot of point in jumping through hoops if nobody's going to appreciate it. (I think maybe if you're sophisticated enough to try queueing inbound traffic you've already got mutiple ports.)

So, you might have to try it and see for yourself.

I went ahead this morning, there are enough problems that I wonder whether the correct solution is to enable queueing on an interface's inbound traffic. (Something like: '"queue" string "in"|"out" ...' where the default is "out".) Again, before undertaking such a thing I'd like to know it would be useful.

The first thing I found was that
route-to was not working as a way to deliver all the packets
coming from the WAN to the loopback interface.
The trouble was traffic initiated on the LAN side.
On reflection I think I now _must_ use a policy based
routing setup, done with tags like this:

  block all
  # Users requesting web pages
  pass in on $internal_if from any to any port http tag h keep state
  pass in on $external_if all tagged h route-to lo0 keep state
  pass out on $external_if all tagged h keep state

(Question: will the above work if I reverse the order of
the last two rules?)

I had been replicating the 'hosts' part:

  block all
  pass in on $internal_if from any to any port http keep state
  pass out on $external_if from any to any port http keep state

which seems to have no place to put a 'route-to' -- no way to get
the return packets from the WAN into the loopback device.

('route-to' is not
sticky like tags so there's no way to start the ruleset
with something like:

  pass in on $external_if route-to lo0
  block all
  ...

which might solve my immediate problem but I don't think that
route-to should be sticky, although I might want to do more
thinking.)

I'd be inclined to have a route-to as an
'action' in the grammer.  I find it a bit ugly to have to
have a separate rule like "pass in on $external_if all tagged h
route to lo0 keep state" for all the different filter conditions,
as well as having to add "route-to" to all the 'pass in' rules
for traffic intiatated on the WAN side.  This seems error prone.
While the fine-grained control of 'route-to' as a 'route'
grammer element is nice, 'route-to' as an 'action' grammer
element acknowledges that routing is orthgonal to filtering.


There seem to be two unrelated issues, which can be tested seperately.


If you route
incoming packets to lo0,
.. does loopback act like a black
hole for any traffic which is not destined for a daemon running
locally
and bound to 127.0.0.1?

If that works, try queueing on lo0.
I've never tried queueing on
loopback. It might just work.

Then there's tags. Policy based routing is nice. Will tags be kept through the loopback? If not this won't work:

  block all
  # Traffic to webserver.
  pass in on $external_if from any to $webserver port http \
       route-to lo0 tag w keep state
  pass out on $dmz_if all tagged w keep state

It's a bit ugly if
initiated from LAN traffic _must_ use tags for policy
based routing where initiated from the WAN traffic
must not use tags and instead duplicate the 'hosts'
grammer element.

I'd try 'set skip on lo0', so pf itself won't see packets on the
loopback interface. You can assign queue tags on the real interface,
and
packets will still get queued accordingly, even if pf is not filtering
them anymore on lo0.

Ok, thanks.


The loopback interface is special in many ways.

I could see solving any loopback problems, save maybe the tagging issue, by hacking up a special loopback device. But would this really be any cleaner than enabling inbound queueing?

Thanks for the reply, it was just what I was looking for.


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