Policy routing with OLSR

[DrLove73]

I am trying to find a way to incorporate policy routing with either static or OLSR routing (I never done OLSR before).

I tested policy routing, and found some features that make my life hell.

I you want to insert policy routing for all traffic of one or more IP's, or for entire subnet, before static routes, You have to writes ALL the routes (already in static routes), or that IP/subnet from that point on will not be able to see any other IP/subnet that is not on the default route written in policy routing script.

Example:

eth0:
inet 192.168.1.2/24 brd 192.168.1.255 scope global eth0
inet 192.168.110.200/24 brd 192.168.110.255 scope global eth0
wpci0:
inet 192.168.212.100/24 brd 192.168.212.255 scope global wpci0
inet 192.168.201.100/24 brd 192.168.201.255 scope global wpci0
wpci1:
inet 192.168.120.100/24 brd 192.168.120.255 scope global wpci1
wpci2:
inet 172.25.14.100/24 brd 172.25.14.255 scope global wpci2
inet 172.25.15.100/24 brd 172.25.15.255 scope global wpci2
inet 172.25.200.100/24 brd 172.25.200.255 scope global wpci2
wpci3:
inet 172.25.10.100/24 brd 172.25.10.255 scope global wpci3

STATIC ROUTES:
192.168.240.0/24 via 172.25.200.200 dev wpci2
192.168.131.0/24 via 192.168.120.200 dev wpci1
192.168.130.0/24 via 192.168.120.200 dev wpci1
192.168.211.0/24 via 172.25.10.200 dev wpci3
192.168.210.0/24 via 172.25.10.200 dev wpci3
192.168.119.0/24 via 172.25.14.200 dev wpci2
192.168.215.0/24 via 172.25.15.200 dev wpci2
192.168.32.0/24 via 192.168.120.200 dev wpci1
192.168.230.0/24 via 192.168.120.200 dev wpci1
192.168.214.0/24 via 172.25.14.200 dev wpci2
192.168.132.0/24 via 192.168.120.200 dev wpci1
192.168.231.0/24 via 192.168.120.200 dev wpci1
192.168.31.0/24 via 192.168.120.200 dev wpci1
192.168.232.0/24 via 192.168.120.200 dev wpci1
192.168.200.0/24 via 172.25.200.200 dev wpci2
192.168.233.0/24 via 192.168.120.200 dev wpci1
192.168.219.0/24 via 172.25.14.200 dev wpci2
192.168.234.0/24 via 192.168.120.200 dev wpci1
192.168.250.0/24 via 192.168.120.200 dev wpci1
192.168.220.0/24 via 192.168.120.200 dev wpci1
192.168.235.0/24 via 192.168.120.200 dev wpci1

DIRECT ROUTES (IP's ARE ON THIS UNIT)
192.168.110.0/24 dev eth0 proto kernel scope link src 192.168.110.200
192.168.120.0/24 dev wpci1 proto kernel scope link src 192.168.120.100
192.168.201.0/24 dev wpci0 proto kernel scope link src 192.168.201.100
172.25.200.0/24 dev wpci2 proto kernel scope link src 172.25.200.100
172.25.14.0/24 dev wpci2 proto kernel scope link src 172.25.14.100
172.25.15.0/24 dev wpci2 proto kernel scope link src 172.25.15.100
192.168.212.0/24 dev wpci0 proto kernel scope link src 192.168.212.100
172.25.10.0/24 dev wpci3 proto kernel scope link src 172.25.10.100
192.168.114.0/24 dev wpci2 proto kernel scope link src 192.168.114.100
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.2

DEFAULT STATIC ROUTE:
default via 192.168.110.100 dev eth0

When I wanted to redirect all traffic to another edge router, on other link (from this unit), by policy routing, I had to enter ALL subnets that this unit knows of in bypass rules in "policy and advanced routing" script :

policy from 192.168.0.0/16 {
# Chiron
net 192.168.110.0/24 via 192.168.110.100
# Panline
net 82.208.0.0/16 via 192.168.110.100
net 10.0.0.0/0 via 192.168.110.100
# Turija
net 172.25.10.0/24 via 172.25.10.200
net 192.168.210.0/24 via 172.25.10.200
net 192.168.211.0/24 via 172.25.10.200
# Centar
net 172.25.15.0/24 via 172.25.15.200
net 192.168.215.0/24 via 172.25.15.200
# Radio
net 172.25.14.0/24 via 172.25.14.200
net 192.168.214.0/24 via 172.25.14.200
# Vrbas
net 192.168.120.0/24 via 192.168.120.200
net 192.168.31.0/24 via 192.168.120.200
net 192.168.32.0/24 via 192.168.120.200
net 192.168.230.0/24 via 192.168.120.200
net 192.168.231.0/24 via 192.168.120.200
net 192.168.232.0/24 via 192.168.120.200
net 192.168.233.0/24 via 192.168.120.200
net 192.168.234.0/24 via 192.168.120.200
net 192.168.235.0/24 via 192.168.120.200
net 192.168.236.0/24 via 192.168.120.200
# Kucura
net 192.168.130.0/24 via 192.168.120.200
net 192.168.220.0/24 via 192.168.120.200
default 172.25.200.200 }

Not even directly connected subnets where accessible if they weren't added as a exclusion from policy routing.

Is there any other resolution other then entering heap of rules for every single subnet/IP I need custom rules for?

And what is situation with OLSR? can they help avoiding redundant writing?

It would be best if policy routing script could (in one option) just replace default route for desired subnet/IP entered in policy routing script.

[lonnie]

That is precisely what policy routing does. Take a router with 5 Ethernet ports. The first port is the feed from your own network, destined for the Internet. Normally this unit would have a default route to one of the other 4 Ethernet lines and ALL traffic without a static route for it will go out the default port.

You use a policy route with a source IP to send certain traffic out one of the other Ethernet lines that connect to a separate Internet feed. It becomes a selector at certain points with multiple feeds to over rule the default route.

[DrLove73]

It is OK, I used it last 1-2 months on both networks I manage.

But if you do not have all Internet connections in one place, and you do not have redundant links, using policy routing is true hell. If you do not repeat ALL static routes in policy routing, You can not ping other parts of your network from subnet/IP used in policy routing.

That is like you have regular road with intersecting roads with people coming from all directions, and then you upgrade that road to be interstate highway, witch means you cut off all those people from your highway.

Is it possible to enhance policy routing script to accept
rule that would state following:

For this source subnet/IP, replace default route to be thru this gateway, instead of one in static route, but do not change other routes.
policy from 192.168.220.0/24 {0.0.0.0/0 via 192.168.200.100}

So if unit can not find custom static route, instead of sending this packet via static default route, send it where I want it to go.

[tony]

Policy routing never changes static routes, but instead is simply adds another (higher priority) routing table sitting on top of the default static one that OLSR, OSPF, and RIP manipulate.

When traffic is flowing, if the policy routing tables cannot satisfy the route, it is passed down to the default routing table to be routed through conventional means.

Are you simply asking (in your example above) that you would like the network 192.168.220.0/24 to have a fixed default gateway of 192.168.200.100 instead of being processed via the default routing table?

If your answer is Yes, then the rule you show should do that without anything extra.

[lonnie]

With source routing you do lose the site if you try and do anything after the source based router since all packets from the unit will get sent to your source based rule. You can only work as you expect when your site is before the policy based router.

It is OK, I used it last 1-2 months on both networks I manage.

But if you do not have all Internet connections in one place, and you do not have redundant links, using policy routing is true hell. If you do not repeat ALL static routes in policy routing, You can not ping other parts of your network from subnet/IP used in policy routing.

That is like you have regular road with intersecting roads with people coming from all directions, and then you upgrade that road to be interstate highway, witch means you cut off all those people from your highway.

Is it possible to enhance policy routing script to accept
rule that would state following:

For this source subnet/IP, replace default route to be thru this gateway, instead of one in static route, but do not change other routes.
policy from 192.168.220.0/24 {0.0.0.0/0 via 192.168.200.100}

So if unit can not find custom static route, instead of sending this packet via static default route, send it where I want it to go.

[DrLove73]

Policy routing never changes static routes, but instead is simply adds another (higher priority) routing table sitting on top of the default static one that OLSR, OSPF, and RIP manipulate.

Yes, but also, policy routing is added above ALL static routes. I have game server in the core of my network. I also go on the field all over my network. In current setup, I have to maintain large set of policy routes if I want to redirect someone on different exit point, but also want to be able to ping and manage my units across my network.

If there is a way that special sort of policy routes would sit bellow all normal static or dynamic routes, but above default static/dynamic route, I could with one policy rule added achieve whole network accessibility, but at the same time change the way customers go outside my network.

When traffic is flowing, if the policy routing tables cannot satisfy the route, it is passed down to the default routing table to be routed through conventional means.

Are you simply asking (in your example above) that you would like the network 192.168.220.0/24 to have a fixed default gateway of 192.168.200.100 instead of being processed via the default routing table?

If your answer is Yes, then the rule you show should do that without anything extra.

I was just starting with policy routing, but when I tried rule like that, it was just like adding default policy route, afterwards only way for packets was thru policy route, so I lost accessibility to the rest of the network, even clients directly associated to the unit with set policy routing.

Assumption:

a) Without policy routing:

192.168.110.0/24 dev eth0 proto kernel scope link src 192.168.110.200
172.25.200.0/24 dev wpci2 proto kernel scope link src 172.25.200.100
172.25.14.0/24 dev wpci2 proto kernel scope link src 172.25.14.100
172.25.15.0/24 dev wpci2 proto kernel scope link src 172.25.15.100
192.168.114.0/24 dev wpci2 proto kernel scope link src 192.168.114.100
192.168.240.0/24 via 172.25.200.200 dev wpci2
192.168.119.0/24 via 172.25.14.200 dev wpci2
192.168.215.0/24 via 172.25.15.200 dev wpci2
192.168.214.0/24 via 172.25.14.200 dev wpci2
192.168.200.0/24 via 172.25.200.200 dev wpci2
192.168.219.0/24 via 172.25.14.200 dev wpci2
default via 192.168.110.100 dev eth0 # DEFAULT STATIC ROUTENote: Whole network is accessible.b) With current policy routing:

policy from 192.168.220.0/24 {default 172.25.200.200}
192.168.110.0/24 dev eth0 proto kernel scope link src 192.168.110.200
172.25.200.0/24 dev wpci2 proto kernel scope link src 172.25.200.100
172.25.14.0/24 dev wpci2 proto kernel scope link src 172.25.14.100
172.25.15.0/24 dev wpci2 proto kernel scope link src 172.25.15.100
192.168.114.0/24 dev wpci2 proto kernel scope link src 192.168.114.100
192.168.240.0/24 via 172.25.200.200 dev wpci2
192.168.119.0/24 via 172.25.14.200 dev wpci2
192.168.215.0/24 via 172.25.15.200 dev wpci2
192.168.214.0/24 via 172.25.14.200 dev wpci2
192.168.200.0/24 via 172.25.200.200 dev wpci2
192.168.219.0/24 via 172.25.14.200 dev wpci2
default via 192.168.110.100 dev eth0 # DEFAULT STATIC ROUTENote: From 192.168.220.0/24, whole network is UNaccessible, except to 172.25.200.200 and further down via 172.25.200.200 .c) With desired policy routing:

192.168.110.0/24 dev eth0 proto kernel scope link src 192.168.110.200
172.25.200.0/24 dev wpci2 proto kernel scope link src 172.25.200.100
172.25.14.0/24 dev wpci2 proto kernel scope link src 172.25.14.100
172.25.15.0/24 dev wpci2 proto kernel scope link src 172.25.15.100
192.168.114.0/24 dev wpci2 proto kernel scope link src 192.168.114.100
192.168.240.0/24 via 172.25.200.200 dev wpci2
192.168.119.0/24 via 172.25.14.200 dev wpci2
192.168.215.0/24 via 172.25.15.200 dev wpci2
192.168.214.0/24 via 172.25.14.200 dev wpci2
192.168.200.0/24 via 172.25.200.200 dev wpci2
192.168.219.0/24 via 172.25.14.200 dev wpci2
policy from 192.168.220.0/24 {default 172.25.200.200}
default via 192.168.110.100 dev eth0 # DEFAULT STATIC ROUTE Note: From 192.168.220.0/24, whole network IS Accessible again.

[jeff]

I'm just talking off the top of my head since I have never tried this, but I believe that policy routing can route based on a mark. Why not just have the firewall mark traffic sourced from the network in question, but destined for not ( ! ) your network. For most people that should be a couple of rules at most. Then policy route the marked traffic to your new gateway.

Your problem is the way you are doing it all traffic from the network in question always takes the new route. Clearly not what you intended.

[DrLove73]

That would do if I do not use 2 Large IP Subnets, both 192.168.0.0/16, AND 172.16.0.0/12. I am in the process of transition from 192. to 172.

In this case, I do not think that creating iptable rule with 2x ! is possible :-(

If my above suggestion is possible, and I do not see why not (except complicated programing code), that would make redundant all those iptable rules, and worrying about what mark is for what IP/Subnet.

Programing is either insert static/dynamic default rule, then insert above special policy route (source based), then insert above the rest of the static/dynamic, or first insert rest of the static/dynamic routes, then add below special policy route (source based), then add below static/dynamic default rule.

[jeff]

Two rules, two marks, two policy routes. Doesn't seem that bad.

[DrLove73]

If I make rule to exclude 192.x.x.x, than that INcludes 172.x.x.x and vice versa. and marking packets works only for one rule, no safety drop-down to the next like in radius servers config.

[DrLove73]

Is there any chance that you consider my suggestions from post #6?

It would add another edge to the software.