I want to thanks all that helped with the setup of my vultr vps with BGP and openvpn to distribute the /24 that was assigned to me.
I played a lot with the openvpn and wireguard software up to a point I had to redo the whole install of the VPS.
here is the receipy I have been able to use for the task. I am running a Debian10 that was updated to the latest software
First I have use the tutorial at https://www.vultr.com/docs/configuring-bgp-on-vultr
Be aware that on my version of bird I was not able to open the "/var/log/bird.log" files because of a propriatary right. the file belongned to root and it was supposed to belong to bird it is a known bug that I hope will be fixed soon.
this helped me create that information into my bird.conf
------------------------------------------------------------------------------
log "/var/log/bird.log" all;
router id xxx.xxx.xxx.xxx ; use the ipv4 address assigned to your vps
protocol device
{
scan time 60;
}
protocol static
{
route 44.xxx.xxx.0/24 via xxx.xxx.xxx.xxx ; use your assigned /24 from ampr and the ipv4 from your vps
}
protocol bgp vultr
{
local as yyyyyyyyyyy; this is the private asn given to you by vultr and availble on your dashboard on myvultr.com for your vps
source address xxx.xxx.xxx.xxx;
import none;
export all;
graceful restart on;
next hop self;
multihop 2;
neighbor 169.254.169.254 as 64515;
password "YourSecretPassword" ;
}
------------------------------------------------------------------------------
On the openvpn side of thing I have use the install script from angristan available at https://github.com/angristan/openvpn-install
just followed the instruction and all was good.
from there I changed some things on my network at etc/network/interfaces
--------------------------------------------------------------------------
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
#source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
auto ens3
allow-hotplug ens3
iface ens3 inet dhcp
iface ens3 inet static
address 44.135.59.1/32
---------------------------------------------------------------------
the last line point at the first address of my /24 put yours into your file.
then on the openvpn server I changed into the server.conf file only one line
the file is at /etc/openvpn/server.conf
i switched the server line from
server 10.8.0.0 255.255.255.0
to
server 44.135.59.0 255.255.255.0
the 44 address is my /24 put yours if you follow my exemple.
that's it!
it was not that complicated. But I had to dig a bit to understand the whole thing.
My next step will be to split my /24 in parts. one section will be for the single connections like now, but I want to have connection that are like blocks of /28 or /29.
I know I will have to make another instence of the openvpn server That is the part that is the less clear for me yet. The conf file is more clear. As I want to strat and stop each instence easily I will have to make a new starting script for systemd And that is where I will need to read more.
If this helps someone I will be happy!
If you see a problem with my setup please let me know!
Pierre
VE2PF
Who is 44.170.120.59? And why is (s)he portscanning for SSH servers?
I think everyone should register their addresses in DNS and have reverse lookup working.
Rob
> If anyone wants to test my incoming access, you can try n2mh.ampr.org
> or http://n2mh-web.ampr.org. Please let me know the results.
Sorry, that web url is a typo. It should be
http://n2mh-web.n2mh.ampr.org
I have received several emails to n2mh(a)n2mh.ampr.org.
73, Mark, N2MH
So, I'm going to continue to harp on the question of what
capabilities/services are we attempting to enable? On that note, I'm
going to point out the ARDC ToS which expressly indicates that the
entirety of connectivity is outside the scope of what ARDC does.
Specifically, section 3, "ARDC DOES NOT provide network services.
Specifically, we do NOT provide network connectivity,"... [1]. While
that document does cover address assignment agreements, it doesn't talk
about the IPIP mesh at all.
Is it out of scope? Is the IPIP tunnel service in scope and a thing
that should be covered by the ToS?
Secondly, and less critically, that document has an inaccurate
assessment of AMPRNet as far as I understand:
> “AMPRNet” means the network 44/8; that is, all Internet IP addresses
from 44.0.0.0 through 44.255.255.255.
So, is the IPIP mesh network gateway an actual service from ARDC?
Should it be? How is it related to address assignment service?
I'm putting forward this question because of the following reasoning:
The primary resource of interest is the IPv4 address space. Those that
already know how to work with allocations of address on the internet,
either personally or by proxy, can and do get allocations of /24 and
greater regularly and utilize them. Anybody who can do this prefers to
do this. (I'm willing to be told that I'm wrong here, but I haven't seen
that case.).
The substantial problems show up in the form of addresses being used
over IPIP or VPN connections, due to bandwidth, latency (to California
and back!), and configuration complexity (610 IPIP tunnels last I
counted). What if we give up on that, and just start pushing users to
regional operators with local connectivity solutions?
What if we spent the time here building the parts for those local
connectivity solutions? To some extent, that's already the discussions
underway. Because I think regional operators will be completely happy
to just announce address space out of their existing infrastructure.
Seeing the variety of framings regarding protocol and hardware choices
leads me to think that there's not much agreement at all about the scale
(Hardware vs Software, ISP / Enterprise / SMB / roll-your-own devices)
of the solution that's needed. How those regional operations
interconnect, also a regional to regional question. Is this whole
question out of scope for ARDC/AMPRnet?
[1] https://www.ampr.org/terms-of-service/
I need to contact Ian - VE7BST urgently.
Ian, if you are reading this please can you contact me off list asap.
If anyone knows how to contact Ian, please could they pass this on.
Thank you,
Chris - G1FEF
Hello
I am using the UFW firewall on Debian Buster. What rule do I have to use
to enable protocol 4 (ipencap) for the ampr-ripd script to work?
Tom SQ4BJA
> If we replaced the IPIP mesh with a collection of geographically
> distributed VPN servers (OpenVPN?) which advertised routes for /24 (or
> larger) subnets, and dual homed each subnet to two or more VPN servers we
> would have pretty good redundancy and could end the distribution of IPIP
> endpoints and just let the Internet route between subnets.
That, or alternatively we could setup a number of routers across the globe with
a tunnel mesh between them (similar to what is now done on IPIP, but probably
better to use something like GRE/IPsec tunnels), with BGP talking between all
those routers, and let users connect their router to one or more of them as
they desire. When one, they could use a VPN with static routing of their subnet,
when they use 2 or 3 connections they could use BGP as well to advertise their
own subnet plus maybe local people's subnets they have routed over radio.
(in the above, with BGP I mean BGP on private AS with only AMPRNet routes, not
full internet BGP)
In such a setup, a single router failing would have little or no impact on the
network as a whole. And everyone can participate with simpler or more complex
setups without having to forcibly deal with a 600-tunnel mesh (that still does
not allow redundancy of the internet connection, i.e. the current IPIP tunnel
mesh cannot handle redundant internet connections that present a different
internet IP to the tunnel system).
Routers in this system could also announce, directly or via their ISP, subnets
from AMPRnet directly to internet. That would just mean there is a more direct
path between AMPRNet users and internet users in that region. But it is not
a firm requirement to do so.
But well, it has all been discussed several times already. In the beginning,
the counter-argument was "it would cost money and who is going to pay that??".
I think that is resolved now.
The next one was "but we won't have a full mesh, traffic to my buddy is going
to take 2 or 3 tunnel hops instead of one". Well, not really true, one can
always setup a direct tunnel to someone else, and a BGP session over that, and
direct traffic will take that path because it has less visible hops.
So then we usually end up in the "it has always been done this way (IPIP mesh)
and I am not going to change". Where the discussion usually stops until the
next new user turns up that has difficulty getting connected to the mesh, e.g.
because they are behind a NAT router they cannot change, their address is
very dynamic, they want to use an off-the-shelf router, etc etc.
By now it appears to be the classical "it was difficult for me should it
should be difficult for everyone else trying to join" that has also been
abused for so long in the battle to get rid of CW exams when obtaining a
ham radio license...
Rob
Hi Steve,
First of all, thanks for checking out my connectivity as requested in my
post to Net44
Second, I notice that your hostname begins with hsmm. Have you done
anything with that or advanced to AREDN?
Third, I'm interested in your report of gateways with errors. Is that a
custom script that you wrote that inspects incoming frames from the tunnel?
Lastly, I tried calling your sip phone on 44.92.21.20 but there was no
response. Is that an active device?
73, Mark, N2MH
