On Wed, Jun 17, 2015 at 1:17 PM, Marius Petrescu marius@yo2loj.ro wrote:
NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS.
Whoa... no need to yell :)
I'm finally taking a look at the wiki doc he referred to: http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example
It does mention creating a new routing table with the default route (0/0, not 44/8) pointed at the UCSD gateway. This makes sense as you may want to generate packets with a 44 source and a non-44 destination on the internet. The gateway will forward those correctly. it would also do it for non-tunneled 44 nets if we didn't have the upstream routing issue at UCSD that started this thread.
The problem seems to be with the traffic that gets flagged to use the alternate routing table:
## Configure Policy Based routing # Packets to 44/8 network use routing table 44 ip rule add to 44.0.0.0/8 table 44 priority 44
# Packets from our 44 subnet use table 44 (put your AMPRNet Subnet here) ip rule add from 44.128.10.0/24 table 44 priority 45
The second ip rule makes sense to me. You want all packets sourced from your 44 net to use the alternate routing table so they can egress through UCSD and keep their source IP without NAT. However, the first ip rule (all packets with 44 destinations) seems unneeded and troublesome. Packets that aren't sourced from your own 44 net, but happen to have a 44 destinations shouldn't be forced to use your tunnel. What happens when your non-ham network (as described in the wiki) attempts to connect to a 44 destination other than your own? Does it go through the tunnels with a source address belonging to your private network? That obviously wouldn't work. Is there a benefit to having that first ip rule? I can't seem to think of one.
If that rule wasn't there, the box should correctly NAT traffic bound for 44 destinations as long as it wasn't sourced from any of the devices on your 44 net, making the 44-based gateway addresses work.