Just to be clear, we are not looking for changing the logic of the main
routing table. That works fine. We are looking at having the
default routes in the additional routing tables, and filtering traffic
to them based on application's explicit request.
I had a look at the session code, and I think this could be relatively
easily added to the session config functionality, rather than to policy.
Session config currently has "bearers" and "type" fields.
We could add "ifname" and "source_route" options.
"ifname" would specify which service should be used (based on if name, e.g.
This would be an AND with "bearers". And source route would be a boolean
which would add a iproute2 rule for interface's src ip address.
This way, any standard socket, not bound to any interface ip would use the
main routing table, and if application does bind(ip) before connect(),
it would use the alternative routing table set up by a session.
This looks like a reasonably small change in session.c and inet.c (to add the src
On 04/11/16 08:11, Patrik Flykt wrote:
On Thu, 2016-11-03 at 14:00 +0000, Lukasz Nowak wrote:
> So I had a good look at the sessions. If I understand correctly,
> each session sets an iproute2 rule to forward packets
> with a session-specific fwmark to the correct routing table.
> The marks are added with iptables based on UID, GID or SELINUX.
> This is quite a bit off from what we need: having one application
> freely choosing which interface to send traffic through.
IIRC sessions are also ending up with only one default route. This has
been the current best practise so far. But that does not mean it cannot
be changed. The user expectation when connecting to a WiFi is that
traffic moves over to WiFi from e.g. cellular; with this in mind the
corner case then is whether a connection is still kept on cellular or
whether it is to break and re-establish itself over WiFi.
> Firstly, can a single application connect multiple sessions?
> (one for each interface)
The code seems to be happy with multiple sessions being created.
> Even if yes, all the sessions would then receive the same policy,
> so only one iptables marking entry would be active, i.e. only
> one routing table would be used. The application would not have
> a way to change that.
> Also, if I understand correctly, if an application opens a session
> with a UID/GID policy, the iptables/iproute rules will immediately
> affect all processes with the same UID/GID - is that correct?
Yes. So something additional is needed as the first UID, GID or Selinux
> Ideally, what we need would is either:
> - set an iproute2 rule to use correct routing table based on packet
> source ip
> - use iptables to mark packets based on source ip
> In either case, I cannot see how it can be easily added to the
> policy model. Unless the application could choose a specific policy
> when creating a session.
> For the AlwaysConnectedTechnologies: this change does not do
> a lot. We can achieve the same effect by the application manually
> connecting all services. In either case, the routing table will
> only be established for one service. So the services in Ready
> state will not be usable for sending external traffic.
This is the first step towards connecting more than one service
automatically; the same will be achieved right now by connecting every
other service manually.
> Automatically adding additional routing tables for each
> and iproute2 rules based on source ip, would do the job. But it
> would have to be independent of the Sessions.
That'd be the next issue to sort out.