On Wed, Jun 17, 2015 at 1:17 PM, Marius Petrescu <marius(a)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.