Source based routing?

[Erik Norgaard]

Hi,

I was wondering if it is posible to route based on source. The
problem is:

I have a network with with an OpenBSD box acting as a gateway.
On the internal network are students and non-students. The stu-
dents may use the internet connection provided by the university
for free while the non-students must be routed to some commercial
provider (and pay).

I could do this by setting up dhcp to assign ip stattically based
on the mac address, assign two different default gateways and then
set up an extra firewall acting as the second gateway.

But it would be nicer to add an extra nic to the firewall and set
up source based routing. However, what I have read and understood
about route(8) is that it controls routes based on destination.

Is there a solution to this?

Second, since this opens for the motive of spoofing ip address to
get free access then I'd like to know if there is a way of filter-
ing based on mac address.

(I know that mac addresses can also be spoofed, and ideally I
should use pfauth. But, it appears that people don't hessitate to
share passwords. Really, I need to identify the user by ip, mac,
username and password and make sure that everything matches cor-
rectly before allowing traffic, and even then I cannot be sure...)

Best regards, Erik

GnuPG Key: http://www.locolomo.org/home/norgaard/norgaard.gpg.asc
pub 1024D/B02CC311 2004-04-05 Erik Norgaard <***@locolomo.org>
Key fingerprint = 6C11 B9B1 52BD F16D 34AD 9893 D3EC E6DB B02C C311

[Damien Miller]

Post by Erik Norgaard
Hi,
I was wondering if it is posible to route based on source.

Yes, using pf. See the "route-to" keyword in "man pf.conf".

-d

[Denis A. Doroshenko]

Post by Damien Miller

Post by Erik Norgaard
I was wondering if it is posible to route based on source.

Yes, using pf. See the "route-to" keyword in "man pf.conf".

What about changing structure of in-kernel routing table to add one
more level of hierarchy based on the source address? So, the current
radix tree (where the key is the destination addresss) would turn
into a case of bigger radix tree (where the key is the source
address) with the key would be 'default' (or 0.0.0.0 speaking of
IPv4). Also searching for a route would involve the source address.
/sbin/route would get optional parameter for source address (with
'default' if not given)...

OTOH, for an end system (not a router) it would be just overhead.
May be this would be where "option GATEWAY" could get back?.. :-)

I tried to do the above to OpenBSD, but eventually lost my time
resources for digesting the source to understand the routing
implementation in BSD.

[Henning Brauer]

Post by Denis A. Doroshenko
What about changing structure of in-kernel routing table to add one
more level of hierarchy based on the source address?

I absolutely do not want that.
The way I see it it is a gigantic waste of kernel memory for no real
benefit - come on, this is a corner case, and it can be solved without
harm to the usual cases using pf and route-to.

[Denis A. Doroshenko]

Post by Henning Brauer

Post by Denis A. Doroshenko
What about changing structure of in-kernel routing table to add one
more level of hierarchy based on the source address?

I absolutely do not want that.
The way I see it it is a gigantic waste of kernel memory for no real
benefit - come on, this is a corner case, and it can be solved without
harm to the usual cases using pf and route-to.

Henning, in end box case that would add one more structure with
pointers. As I said, it would add overhead to each packet processing,
but I cannot see your "gigantic waste of kernel memory" here.

Imagine one special case with special routing: one extraordinary
source that is not to use in-kernel routing table. Not a problem
here, route-to would do that. Remember that even with one "special"
source, you can have say ten route-to rules.

Then, imagine another: ten, or may be better twenty extraordinary
sources. Well, you may have your pf.conf messy then. Also routing
problem trouble shooting may be fun in such case: do not forget to
look to the both places 'route show' and 'pfctl -s r'...

I stepped in because the approach with one more level of radix tree
hierarchy is more logical, more intuitive 'cause the only place
where routing decisions are done is kernel routing subroutines
according to one routing table. The only real concern I see here
is the mentioned overhead for the systems that do not need this
power... I saw that radix stuff is being modified to allow multipath
routes (hey this is what was discussed in the daemon book, though
I am not sure that the implementation matches!), so why not to take it
further? :-)

[Henning Brauer]

Post by Denis A. Doroshenko

Post by Henning Brauer

Post by Denis A. Doroshenko
What about changing structure of in-kernel routing table to add one
more level of hierarchy based on the source address?

I absolutely do not want that.
The way I see it it is a gigantic waste of kernel memory for no real
benefit - come on, this is a corner case, and it can be solved without
harm to the usual cases using pf and route-to.

Henning, in end box case that would add one more structure with
pointers. As I said, it would add overhead to each packet processing,
but I cannot see your "gigantic waste of kernel memory" here.

"one more structure with pointers" x 130000 = gigantic waste

Post by Denis A. Doroshenko
Then, imagine another: ten, or may be better twenty extraordinary
sources. Well, you may have your pf.conf messy then.

you may have your "wherever all thise routes are set" messy too then.
no real difference.

Post by Denis A. Doroshenko
according to one routing table. The only real concern I see here
is the mentioned overhead for the systems that do not need this
power... I saw that radix stuff is being modified to allow multipath
routes (hey this is what was discussed in the daemon book, though
I am not sure that the implementation matches!), so why not to take it
further? :-)

because your proposal adds up on memory use in the typical cases, and
becomes a killer on bgp full-mesh machines, without much benefit. The
multipath stuff does not add up on kernel memory use for the typical
cases.