Subject: Re: [44net] AMPRNet Interoperability with BGP From: Brian Kantor Brian@UCSD.Edu Date: 06/17/2015 08:01 AM
To: AMPRNet working group 44net@hamradio.ucsd.edu
On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote:
Good question! No, a change to the portal around the same time prohibits adding 44.xx.xx.xx addresses as gateways. I believe there was some noise on this list about it at the time.
That change was made because
- it was reported that 44.x gateway addresses didn't work
- it was reported that 44.x gateway addresses caused problems
- people were entering 44.x gateway addresses for their IPIP tunnels instead of the proper commercial IP address of the endpoint.
The reason (1 and 2) is that for a typical system that has both a public IP and an AMPRnet IP and is to function on the IPIP mesh, you need policy routing when you want the AMPRnet IP to be reachable from public IP addresses on internet. Normal internet traffic is to go out using the public IP, possibly using NAT, and AMPRnet traffic is to go out via the IPIP tunnels. When such a system is on a source-address filtered internet connection, the default route for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh system that has unfiltered internet access. Typically the system at UCSD.
It is preferred that the varying gateway systems are configured only via RIP (usually in a separate route table), and that it is not required to make specific policy routing configuration for gateways. So the policy routing is static for 44.0.0.0/8. This conflicts with the 44.x gateway addresses, because the traffic got incorrectly routed by the routing policy (which is used both for the actual traffic and the encapsulated packets).
When people see a way around that (I don't completely oversee if Jann's suggestion will achieve that), it would be no problem when tunnel endpoints exist within 44.x. Please see the example configuration for Linux systems in the wiki and suggest a way how that could be made working without manual "ip rule" entries dedicated to specific gateways. Or else, those "ip rule" entries maybe could be managed by ampr-ripd, that would be fine as well.
Aside from that, of course it should still be validated that tunnel endpoints are not within the subnet being tunneled (3). That is simply an error condition. There were some networks that were claimed to be reachable via a tunnel at their first address (Sweden, for example) and there were some entries with tunnel endpoint == tunneled address. The portal should refuse that so that applicants are made aware of their error before such entries are broadcast via RIP and result in encapsulation loops.
Rob
Rob, please stop stating the fact below. UCSD is not able to forward tunnel traffic to other networks.
From UCSD's point of view, there either exists a tunnel to the destination,
and then sthe source shall have a direct tunnel to it, or it is unknown, and then neither UCSD, nor the gateway has data on it. So, sending that unknown traffic to UCSD is pointless, since the ampr-gw has the same information as you on the tunnels. If you can not resolve it locally, neither can the UCSD gateway. The only systems that fall into this category are the ones that are BGP announced. And the only way to reach them is via the regular internet, via your public IP to allow full routing, and thus access to them.
NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS.
Marius, YO2LOJ
-----Original Message----- From: 44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu [mailto:44net-bounces+marius=yo2loj.ro@hamradio.ucsd.edu] On Behalf Of Rob Janssen Sent: Wednesday, June 17, 2015 22:49 To: 44net@hamradio.ucsd.edu Subject: Re: [44net] AMPRNet Interoperability with BGP
(...)
When such a system is on a source-address filtered internet connection, the default route for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh system that has unfiltered internet access. Typically the system at UCSD.
On 17.06.2015 22:17, Marius Petrescu wrote:
The only systems that fall into this category are the ones that are BGP announced. And the only way to reach them is via the regular internet, via your public IP to allow full routing, and thus access to them.
Or you tunnel to a non-source route filtered gateway: /sbin/ip rule add from 44.0.0.0/8 table inet prio 22000 /sbin/ip route add default via <non-filtered gateway> dev tunl0 onlink table inet
73, Jann
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.
-
Cory (NQ1E) -
Jann Traschewski -
Marius Petrescu -
Rob Janssen