login
Search
Ryan McBride announced that he has committed code to PF, OpenBSD's stateful packet filter, adding support for tracking stateful connections based on the source IP address. Ryan explains that this allows a firewall administrator to "ensure that clients get a consistent IP mapping with load-balanced translation/routing rules, limit the number of simultaneous connections a client can make, [and] limit the number of clients which can connect through a rule".
Read on for Ryan's announcement which includes examples of how to configure this new functionality.
From: Ryan McBride [email blocked]
To: pf
Subject: Source Tracking in PF
Date: Mon, 15 Dec 2003 00:23:58 +0000
I just committed code which adds support to track stateful connections
by source IP address. This allows a user to:
- Ensure that clients get a consistent IP mapping with load-balanced
translation/routing rules
- Limit the number of simultaneous connections a client can make
- Limit the number of clients which can connect through a rule
As always, the more people who test this and provide feedback, the
happier I am. Read below for details.
-Ryan
SYNTAX:
The 'sticky-address' keyword applies to translation rules; the
translation address will be selected from the list, but once a client
makes a connection, all subsequent connections are translated the same
way.
nat on $ext_if from $int_net to any -> \
{ 10.1.2.1, 10.1.2.3 } round-robin sticky-address
Similarly in the following case, connections to a server are mapped
randomly, but all connections from a client are mapped the same way.
rdr on $ext_if from any to $ext_if -> \
{ 192.168.0.4/30 } random sticky-address
In the case of tracking states per rule, the syntax is slightly
different. The 'source-track' state option is used to enable tracking,
limits can also be set there: 'max-src-states' limits how many states
from a single source can exist simultaneously and 'max-src-nodes'
limits how many source nodes can exist (effectively this is a limit
on how many clients can connect at once).
The following rule allows a maximum of 1000 source ip's to connect to a
webserver, each with a maximum of 3 simultaneous states:
pass in on $ext_if proto tcp to $webserver port www flags S/SA \
keep state (source-track, max-src-states 3, max-src-nodes 10)
By default, the source node is removed when all the states which
reference it are removed. However the timeout 'src.track' regulates
how long the source node is retained after all it's states have died.
set timeout src.track 900
A list of src nodes can be retrived with pfctl -sS, pfctl -vsS;
pfctl -vsi provides statistics on src-node useage (similar to the
statistics provided for states)
yes and,... ?
Netfilter has been capable of configurations like this for years,. unless theres something I'm missing, whats so unique or new here?
re: yes and,... ?
Do you have links documenting this functionality? I've searched through the netfilter documentation, and found nothing about load balancing uplinks, nor throttling connections by source IP address...
Yes it can
First the bad point it is in patch'o'matic, but I think it can be done with regular stuff.
So let's go to the good things :
by using the nth patch you can do any weighted load balancing you want and it works with nat (See http://www.netfilter.org/documentation/pomlist/pom-combined.html#nth)
> throttling connections by source IP address : do you mean shaping by IP ?
It can be done easily by marking connection. Furthermore, if yo need someting really fine tuned you can use the fantastic CONNMARK which is able to put the same mark on every packets of a connection (See http://www.netfilter.org/documentation/pomlist/pom-combined.html#CONNMARK and http://home.regit.org/connmark.html for usage).
At least but not least, with NuFW (http://www.nufw.org) you can do packet filtering and marking by user and not by IPs.
re: Yes it can
Great, that's what I was looking for. Thanks for the links.
Thanks
Hello
There's an easier way if the dist ips are sequential.
(Round Robin)
iptables -t nat POSTROUTING -o *DEV* -j DNAT *1st IP*:*Last IP*
Works with ports too.
HTH
Speaking of uplink ?
I think jeremy speaks of uplink, so it is more a Source NAT related problem.
But this is true that you can do a good round-robin server by using DNAT as you said.
--
Regit
Nufw, Now User Filtering Works (http://www.nufw.org)
Sry my bad
I just checked out your site looks cool.
Can't u just use --user though?
Why would u want this on the fw(not app) level?
Please excuse my ignorance.
using --user is not enough
--user or equivalent has it exists on netfilter is only usable on local connection. NuFW brings this notion to the whole network.
If you want to do user level filtering, you have to be able to authenticate each packets. To do so you have to have supplementary informations on packets. Here you've got two ways :
- Or you use an encapsulation (it's the ipsec solution) but this require a system level access to the machine and you can't have multiple users on the same tunnel.
- Or you have to provide information externally.
NuFW has choosen the second way. Information is brought by client software and that's why a daemon is necessary to get this information.
If you have a daemon you can do it in the kernel like khttpd but the standard way is to do it in userspace ;-)
--
Regit
Nufw, Now User Filtering Works (http://www.nufw.org)
Hello
So this is protocol in specific and allows accounting per user?
Sound's great. I'll check you site for details but is there a mailing list( i guess that's on the site too :) )?
J
Well, netfilter and its ances
Well, netfilter and its ancestors have certainly been able to "Track Stateful Connections by Source IP" for ages... and I imagine openbsd's PF has been able to do this as well. Being able to limit the number of connections per rule is what's new.
You may be able to do something like this under linux with the iproute2 package:
http://lartc.org/howto/
But that's all magic to me, you really need to have a PHD in CS to understand all that stuff IMHO.