Re: [44net] New Linux Boot Scripts for Testing - 44net

5 Aug 2015


      ...
Subject:
Re: [44net] New Linux Boot Scripts for Testing
From:
Tom Hayward esarfl@gmail.com
Date:
08/04/2015 09:34 PM
To:
AMPRNet working group 44net@hamradio.ucsd.edu
On Tue, Aug 4, 2015 at 12:19 PM, Rob Janssenpe1chl@amsat.org  wrote:
...
...
...
...
The hamwan.org remain unreachable
It goes via radio to our 44.137.0.0/16 gateway and from there over plain
internet (it is BGP routed).
You may have trouble trying to access this with some of the typical tunnel
setups because they provide no tunnel endpoint.
Indeed, this is what you should be seeing for hamwan.org at the
moment. Since our gateway was deleted from the portal we have not gone
in and rebuilt things.
We are properly BGP routed, so any machine on the internet (and not
behind amprgw) should be able to access it.
The system where I tested this (our gateway system) can send internet traffic from 44.137.0.0/16
without source address filtering issues.   However, the typical ISP line here is source address filtered,
so I cannot send traffic from a 44.137.x.x address directly from my home line to you on your BGP routed
network.
Traffic to other IPIP gateways is encapsulated in an outer header with my public IP and the public IP
of the tunnel endpoint I route to, so my ISP does not filter such traffic.  However, when I want to send
from my 44.137.x.x address to any other system, either outside 44.x.x.x or in the 44.x.x.x network but
not routed via IPIP, I need to encapsulate it and send it to some system that can send that traffic
without source address filter.
Before we had our own gateway, it was usual to send this traffic to AMPRGW.  But that did not work
for this case.   That appears to have been resolved now.   Our own gateway could already do this.
However, there is still the issue of "what to do with traffic" (encapsulate it or not, what source address
to use) sent to 44.x.x.x.
It was difficult to do it right when the tunnel endpoint falls within the 44.x.x.x network.
This was the actual reason why your tunnel endpoint was removed after discussion here.
I think when you bring back the tunnel endpoint (which of course is preferable), you should try to
get an IP outside 44.x.x.x for the tunnel endpoint, as most users have done.  That reduces the risk
of problems.  I do not believe in setting up exception lists for ranges that are BGP routed or are
used as tunnel endpoints but are within 44.x.x.x, that is just making everything complicated and makes
it break down when people are not always on the watch for changes in the network.  The automatic
handling provided by (ampr-)ripd is much preferred over such manually maintained configuration.
Rob