I'm disappointed iproute doesn't do it.. its so powerful.. close, but not cigar!

It turns out you could almost do it with policy routing if you moved the ppp / wlan interface definitions from table 255 (local) or inserted a rule with priority -1.. either way it just won't let you do it.. and frankly what we'd like to achieve is a bit counter-intuitive.. so I can't really blame it

As for the ipt_route code, it is actually really very simple. It wasn't dropped for reliability problems, it was dropped because iproute2 should be used instead.. and I agree.. however, what we want is REALLY out of the ordinary..

What I propose is porting ipt_ROUTE to xtables module. I think this is trivial and should take an afternoon.

Plus side
no kernel changes
iptables will work with the new module without a recomile (I think)
it is a single, small module

down sides:
It *is* a module
It *IS* a unsupported kernel module!
It *IS* an unsupported kernel module that is unlikely to make it back into the kernel as namespaces would probably be the way forward :P

If I can clean up the code and get a copy running on my N810 some time today (ARM testing first) there is one more thing to think about..

When ppp0 is brought up, it can either obtain local peer IPs automatically, OR they can be set manually.. what would be great is if they could be set manually.. but.. report what the remote end wanted them to be set too..

This means we can use that information to create/customise NAT rules.. and we can hard code our interface to non-clashing addresses. I'll look at that too..

You've raised some great points.. and its the weekend and I enjoy a good challenge!

I'm going to throw about some VMs and see if I can make something work..


MMSC --- RTR --- [PPP0 DEV WLAN0] --- WIFI --- HOST

Each is an IP and I'm hoping I can make any on the left match with any on the right and it'll all keep working.. I'll get to work