> it's still possible to setup a VPN to a remote host and interface with
> the IPIP mesh there. It's not idea, but it's a solution. As long as all
> the nearby sites have a route over VPN, it can work. By tuning the VPN
> parameters, latency can be kept down.
That is what we have operating right now. Our 44.137.0.0/16 network
is now BGP announced from a datacenter where we have a MikroTik CCR1009
router that has many users connected via different kinds of VPN
(L2TP/IPsec, GRE, GRE/IPsec, GRE6 (GRE over IPv6)) and the users run
BGP to announce their subnets and receive our subnet.
They can (and do) inter-connect using radio links and setup BGP peering
over there as well, so the routing between users can be over radio and
towards internet over the VPN. We have some BGP communities to steer
the routing, e.g. to prefer a multihop radio path over a path via VPN
which is always two hops at most.
This router is on the IPIP mesh as well, but when that mesh were to be
taken down we only would need to setup some similar VPNs and BGP
peerings, of course one to UCSD where a router would be for the space not
announced separately (44.0.0.0/9 and 44.128.0.0/10), and anyone in the
world would have the possibility to setup a VPN server for some subnet
(be it BGP announced or not, that does not matter) and serve their
local users from it. Users in a region not covered by such a service
could connect to UCSD and have similar performance to what it is now.
Those VPN servers do not need to peer with ALL others, but they can peer
with a couple of them and we still have redundancy.
In addition to this, we also offer OpenVPN VPNs without BGP, for users
that are endpoints only. A single fixed address is routed to the VPN
client when it is connected.
This all is really easy for the users to setup, and when the L2TP/IPsec
VPN is used it works over all internet connections even when they have
dynamic address, are behind CGNAT, have agressive firewalls, or whatever.
Should it prove necessary, an SSL based VPN like SSTP could easily be
added (it uses TCP port 443 so it always works, but of course VPNs using
TCP transport are to be avoided when possible)
BGP in the MikroTik routers is configured in a few mouseclicks or a
cut-and-paste of a small text fragment. Set the local AS and ID, add
a peer with remote address and AS, set 2 or 3 options, and it works.
For best operation, use a small routing filter that can be cut-and-paste.
Rob
> I think this is resolved now.
Yes it looks like it is. Can you explain how this affects the
content of the 44.rev zone file and the configuration of a DNS server
that serves that zone?
I now have the 44.in-addr.arpa configured in a local DNS server and
loaded with that zonefile as downloaded from the FTP server.
Rob
> On 19 Jul 2019, at 12:13, Marc Williams via 44Net <44net(a)mailman.ampr.org> wrote:
>
>
> From: Marc Williams <monsieurmarc(a)btinternet.com>
> Subject: Re: [44net] Time to restructure the network?
> Date: 19 July 2019 at 12:13:06 CEST
> To: Borja Marcos via 44Net <44net(a)mailman.ampr.org>
>
>
> It seems like a an idea worth exploring
I agree. Apart from a slight learning curve, with less "auto configured magic" BGP is
actually easier to manage. I think it's worth the slight effort.
73,
Borja / EA2EKH
>No.
>https://portal.ampr.org/networks.php <https://portal.ampr.org/networks.php>
> 44.224.0.0 / 15 GERMANY
> ..with currently ~9500 assignments.
> But that's no unresolvable problem. Just answering here to state that there is a large allocation and we do our best to move.
> There's no direct bgp announcement for 44.224/15, and connectivity is done ampr-internal via ipip-mesh. Thus except for the dns reverse resolution, we expect no impact and can move step by step to 44.148/15.
> The sold of the /10 netblock we are in is not a showstepper, it just makes (a lot of) work. But we also see the chance to configure things better during the renumbering.
That was already going on for a while, wasn't it?
Of course I saw this coming, by observing changes in the network assignments...
But I wonder if the 44.224.0.0 network wouldn't have been better renumbered to 10.224.0.0, that better reflects the nature of the internet connectivity of that network and probably would solve some problems...
You could then setup the new 44.148 space with true routing.
Rob
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
It's clear we will need to engage with legal counsel regarding the
corruption inside ARDC and perpetuated by the board. The people involved in
this must be called to answer for their treachery.
I have created and email list for strategizing and organizing this:
http://lists.keekles.org/cgi-bin/mailman/listinfo/44-reform
I also call on the community to not be won over by promises of money and
grants from ARDC. The leaders think they will buy the community off. This
is tainted money and I call on the community to reject it when offered and
expose those who take it.
73's
- --
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEaESdNosUjpjcN/JhYTmgYVLGkUAFAl0xjNoACgkQYTmgYVLG
kUARDA//WJ06KmrXkTiWVsP3osUyEX2HKvJaqGwXYlioEnYHBpeaKYM3wzZRdaO9
/ps9ENc5lSGouKA2Zd9SBUjsKu40VWOT0FUi+CXe49XOL7GZ5X6k75X+hZ4PCsCP
5w+1RUXHOtT3SWIOyVXh0l5uwSOW6azKdVeTFcSGYeyE/lxgsOPwz49CtK6K7DvO
O7MxHFbQI2rGCnWmcABuAoz6AImcAFzgGpxe3RwdjWLw+/j7StGyjDT1nEY58cxz
AQZParzz/i/eQVZyLI3mBoHfNlKxJvyyeQ0qVbS6phfash2t9I3vnC1NeU6y1JTp
yJ5q2B72N2e5cwcVfdtZJzBNIXPmd57LkXr0NijNyzl5cr+OSFwbpYvBa49+hzVR
zO4F2RQRvCr1p+i5XZYhH1r+MxaisvcctVzeuMF9Aolz1WoU65AQRqPs/Ek7eefA
pXlGd+RAmVlCeoYzhmyzJSqMP0sGneKWH3JmL9xrFhE7jBBLHPEd1TyJxW+mpWLC
SSVqTZRVG9Oc7AsQ7DZOtk0GnkW9R5qZTEG0Lnjq/9eTpAaeSZ/viXJYMD/4Kahd
QX4Ec21smcw4v7npmGhxAtGvkv//zQsZnMEni51sPdeTa5eZ6+08aEDYvxfRrP8Z
W3L3Q6Lw+/LIbgocSu4P73WCAjiS4LAsBCz3Dl0aeHob1V4GQW0=
=wmG1
-----END PGP SIGNATURE-----
Well once the reverse DNS is fixed then the next most important thing to do is to figure out how to stop them from selling the rest. Greed can be a terrible thing.
Roger VA7LBB
> On Jul 18, 2019, at 20:39, Michael Fox - N6MEF <n6mef(a)mefox.org> wrote:
>
> Folks,
>
>
>
> I'm sure folks will want to express their outrage about the address sale for
> months.
>
>
>
> In the meantime, let's focus on what we can control. How do we get reverse
> DNS working again for the part of 44/8 that wasn't sold?
>
>
>
> Michael, N6MEF
>
>
>
>
Tks for info, getting err_connection_timeout with
ftp://gw.ampr.org/pub/
Can u please attach the file to my email ?
Thanks in advance,
73, lu7abf, Pedro
On 7/19/19, Steve L via 44Net <44net(a)mailman.ampr.org> wrote:
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
So reading: https://www.ampr.org/amprnet/
Has raised the following questions..
"Why did you sell?
We weren’t ever going to use those addresses, and in today’s marketplace,
they could bring in some badly-needed funds.”
Really badly-needed funds by who? for what is there some pressing need that the watchers of the 44/8 space had that they didn’t bother to ask the rest of the community?
"Who decided to sell these? I didn’t get to vote on it.”
It was all hush hush it seems. Because had you brought it to the community that uses the space day in and out it would have been brought with soooo much negativity that people would be asking questions to out the “board” of directors.
The asset of 44/8 was for you guys to protect for Amateur Radio as a whole.. It’s not your personal play toy.. You all just thought about yourself’s and not the legacy and future of any grant programs or the like. 44/8 isn’t a personal piggy bank that you just turned it into. And into the largest piggy bank ever for a small group of hams to control at that. Had you really wanted to help Amateur radio you would have worked with the people who use the asset…. Now you have no clue if traffic from 44/8 is Amateur Radio based or not and that’s so screwed up..
--
Fredric Moses - W8FSM - WQOG498
fred(a)moses.bz
