Subject: Re: [44net] AMPRNet Interoperability with BGP From: "Cory (NQ1E)" cory@nq1e.hm Date: 06/17/2015 11:02 PM
To: AMPRNet working group 44net@hamradio.ucsd.edu
On Wed, Jun 17, 2015 at 1:17 PM, Marius Petrescumarius@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:)
Indeed... I was never talking about a 44/8 route, it is a 0.0.0.0/0 route.
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.
That is why it is there! it is required for IPIP gateways on a source address filtered connection.
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.
The reason that it is there: when you make an outgoing connect from a socket that is not bound to a specific address, the kernel will decide on the local address based on the route. When you do nothing, traffic to 44.0.0.0/8 will be routed to your normal default route to your ISP, and the source address will be your public IP. The traffic will be routed "outside" via UCSD or a BGP-announcing gateway. Of course you want to make such connections via a tunnel, so there is the first rule that will match the 44.0.0.0/8 destinations, select table 44, and find the tunnel routes there. Then, your 44.x.x.x source address will be selected.
Rob
On Thu, Jun 18, 2015 at 1:07 PM, Rob Janssen pe1chl@amsat.org wrote:
## 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
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.
The reason that it is there: when you make an outgoing connect from a
socket that is
not bound to a specific address, the kernel will decide on the local
address based
on the route.
Bingo!!! There's the use-case I was missing in my head: YourGWHost(Forcing44SourceIP) -> OtherIPIPLANs
Because a gateway host has three IP addresses (ISP, Private, 44net), any outbound connection you make directly from that host (not including the rest of the hosts in your assigned 44 subnet) will have a source IP based on the interface the packet leaves from. This would normally be your ISP address, but some people may want to run a program on that same gateway host that talks to hosts on other 44 nets and force the source address to be their 44 interface instead.
The correct way to do that is obviously to tell the program you're using that you want to bind to the specific 44 network interface. Forcing it to happen for all traffic with a 44/8 destination is an easy workaround to make that work, but as you can see it can have unintended consequences.
I can understand the desire to put in that workaround since it's easy to do, but it's not really how IP networking is supposed to work. IPs and routes are always typically chosen based on what would make the packet likely to reach the destination, not who you want it to pretend to be from. Unless there's a way to get more specific and apply that rule only to destinations you have an IPIP tunnel to, then choosing to apply that configuration line on your gw host means your entire assigned 44 subnet, your private subnet, and your gw host will all have trouble connecting to some 44/8 destinations.
My recommended solution for those who want to be able to connect to as many 44 nets as possible is: Remove the 'to 44/8' rule and if you want to talk to a 44 host from a 44 IP, use a host behind your gateway, not the gateway host itself.
The 44 hosts behind your gateway may still not be able to reach some BGP-only 44 nets until the UCSD gw issue is solved, but you'll start being able to reach them using your gateway host and your private network. You'll also be able to start talking to the larger nets that need to use 44-based IPIP gateways (like HamWAN) from your 44 hosts.
Whew... I know that's a mouthful, but I hope it makes just as much sense to everyone else as it does to me now. ;)
-Cory NQ1E
-
Cory (NQ1E) -
Rob Janssen