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

5 Aug 2015

...
  Subject:
 Re: [44net] New Linux Boot Scripts for Testing
 From:
 Tom Hayward &lt;esarfl(a)gmail.com&gt;
 Date:
 08/04/2015 09:34 PM

 To:
 AMPRNet working group &lt;44net(a)hamradio.ucsd.edu&gt;

 On Tue, Aug 4, 2015 at 12:19 PM, Rob Janssen&lt;pe1chl(a)amsat.org&gt;  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