(EDIT: correct recommended subnet mask for 44. Of course it's no longer /8. It should be within either 44.0.0.0/9 or 44.128.0.0/10.)

The amprd package installs directly from the fedora repository. The configuration is straightforward, however getting firewalld and NetworkManager configured is a little tricky.

The amprd documentation refers to requiring the ipip_redirector for 4.13+ kernels. It's not required for the 6.8.9 kernel that comes with Fedora 40.

Note for the most part the commands require root so put sudo in front of the commands or become root with 'sudo -i'

For starters, you'll need an ampr IP address, resource record (DNS), and gateway. Visit the ampr portal and request an address. After you get an address, configure a RR and gateway. Looking ahead, the first clue that you have the gateway correct is that you'll receive ripv2 packets when amprd is running. After pulling my hair out, I wasn't even sure my gateway was correct but upon misconfiguring it, the ripv2 packets stopped; so that was a good clue at least my gateway configuration was correct.

Note that changes in the portal can take a little while to take effect. For a gateway and resource record (DNS), I think an hour may be sufficient. But maybe it takes longer - since I was addressing several issues in the beginning, I'm not sure if maybe it took a day to take effect.

Your gateway configuration uses the IP address and hostname of the external IP address from which your Fedora machine is visible to ampr.org. The IP address does not need to reverse resolve. If you don't have a spare hostname, configure an ampr.org DNS entry to resolve to your external IP address. If the hostname and IP don't match, the gateway IP entry updates to whatever the hostname resolves to - that's how you'll know you don't have your hostname resolving correctly.

Amprd ended up creating a NetworkManager entry but it needed some tweaking. I'd suggest just creating the entry in advance and it will be all ready for the next step installing, configuring and starting amprd.

Create a new connection for your ampr0 interface that amprd will use. Create the file:

/etc/NetworkManager/system-connections/ampr0.nmconnection

and put in the following contents:

[connection]
id=ampr0
type=tun
interface-name=ampr0
zone=ampr

[tun]
mode=2

[ipv4]
address1=<your ip address>/32
method=manual

[ipv6]
method=disabled

[proxy]

The main issue I ran into was that the firewall zone was set to the firewalld default unless I created the interface to be managed by NetworkManager.

Note that the configuration above expects a firewalld zone named ampr to exist. We'll create that below. Be sure to fill in your IP address. We use CIDR /32 because amprd is going to create the correct route for you. So basically we don't want any routes yet, just an IP address on the interface.

Be sure to set the file permissions correctly (compare to others in the folder). Then restart NetworkManager.

We'll need to define a zone named ampr. This zone will masquerade. If you don't want this, leave out the masquerade declaration. On my server, it is my router handling internet traffic. When 44 traffic is routed out the IPIP interface, traffic will need to be masqueraded because all my local IP addresses are private, non-routable, e.g., 192.168.

This zone will be firewalled toward amprnet. In this example ssh, http and https are open inbound ports. Create the file:

/etc/firewalld/zones/ampr.xml

and put in the following contents:

<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>ampr-org</short>
  <description>For use toward ampr.org. You kind of trust the other computers on the networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="https"/>
  <service name="http"/>
  <masquerade/>
</zone>

Assuming you want to masquerade, we also need a policy for this new zone. Create the file:

/etc/firewalld/policies/NAT_to_ampr.xml

and put in the following contents:

<?xml version="1.0" encoding="utf-8"?>
<policy target="ACCEPT">
  <ingress-zone name="internal"/>
  <egress-zone name="ampr"/>
</policy>

where the ingress-zone should match the zone of your internal network. Ensure the file permissions are correct for these files.

Finally reload firewalld:

firewall-cmd --reload

Install amprd with:

dnf install amprd

Edit the file:

/etc/amprd.conf

Define an ampr0 section. Enter your new 44 IP address into prefix with /9 or /10 depending on your allocation. That will enable respective 44 traffic to be routed out the tunnel. If you want just a smaller subnet, use a narrower CIDR.

For now turn on multicast and rip. This will enable you to confirm you are connected to your gateway and receiving traffic. You can turn off the setting later if you like.

You don't need to set the rip_password. It hasn't changed in a long time and is compiled into the code. If you are interested in the password, I didn't find it with the -d option as the comment suggests (maybe I was running into other issues at the time) but I did see it using tcpdump.

Amprd wants to save routes in /var/lib/amprd. Although it is running as root it can't create a file - probably selinux. Just touch the file and then it will work. If your interface is ampr0 then:

touch /var/lib/amprd/ampr0.txt

The next issue isn't critical but its a little annoying. The systemd service file for amprd says to use amprd's pidfile. By default amprd doesn't create a pidfile. You can either modify the amprd line to create a pidfile or you can remove systemd's directive to look for a pidfile. Systemd can figure out amprd's pid with the file so I chose the latter.

In general don't modify /usr/lib/systemd/system/amprd.service. Instead copy it to /etc and edit the file as desired:

cp /usr/lib/systemd/system/amprd.service /etc/systemd/system/
# now edit the file, then...
systemctl daemon-reload

Start up the amprd service and if you feel ready, enable it also to start on boot. To start it:

systemctl start amprd

A couple of tcpdumps will let you look at what's going on. On your external interface you can monitor the traffic going to the internet and the encapsulated IPIP traffic:

tcpdump -nnvi eno2 host 169.228.34.84

169.228.34.84 is the amprnet gateway. The host directive will only show you traffic going to amprnet and not flood your console will all your other internet traffic.

You can also just examine the ampr0 tunneled traffic with:

tcpdump -nnvi ampr0

After a few minutes you should see ripv2 traffic coming from amprnet to a multicast address that includes your machine.

For whatever reason, the amprnet gateway takes around 60 minutes to start passing your traffic. You can start up a ping on a couple of different addresses that are pingable. Once you see replies your tunnel should be working. Try 44.1.1.17 which is portal.ampr.org or 44.1.1.20 which is git.ampr.org.

Also, once the tunnel is working and assuming you want to use masquerade, see if a device on your internal network can browse to https://portal.ampr.org.

If your tunnel isn't working after an hour or so, study the tcpdump traffic for clues. If you suspect a firewall issue, try turning on logging (use sudo):

# check the zone is on the interface
firewall-cmd --get-zone-of-interface ampr0
# turn on logging
firewall-cmd --set-log-denied=all
firewall-cmd --get-log-denied
# examine the log and use ^C when done
journalctl -xef

# turn it off
firewall-cmd --set-log-denied=off
firewall-cmd --get-log-denied

If you find that there are so many routes from ripv2 that you can hardly keep track of your own routing configuration, consider the following changes.

The 2 required ampr routes to point to all of ampr can be configured in the ampr0.nmconnection file like this:

[ipv4]
address1=<your ip address>/9
route1=44.128.0.0/10
method=manual

In order for NetworkManager and amprd not to fight, you'll need to modify the amprd.service file to start with a “network-online” target. To do this, copy the system amprd.service file into the /etc tree:

cp /usr/lib/systemd/system/amprd.service /etc/systemd/system

Edit the /etc copy of the file and change the After directive to:

After = network-online.target

This will let NetworkManager bring up the interface and configure it. Only after will amprd do its thing while respecting the initial configuration by NetworkManager. You'll end up with 2 44. routes that look like this:

44.0.0.0        0.0.0.0         255.128.0.0     U     450    0        0 ampr0
44.128.0.0      0.0.0.0         255.192.0.0     U     450    0        0 ampr0

If you are outside the US, you probably know to swap the /9 and /10 subnets like so:

address1=<your ip address>/10
route1=44.0.0.0/9