Repeater linking

I am testing network configurations for TARRA, the Teton Amateur Radio Repeater Association in Wyoming.

Goal here is to route our 44 subnet to the repeaters. The repeaters can be on any service provider so we need to accommodate that.

I have to keep in mind that the bigger picture is to control and link the repeaters, so that might mean changing out the operating system. For example, the Pi image distributed for Allstar is ArchLinux.

Wireguard would be one approach but my current thought is to keep it as simple as possible by using only tunnels.

Test setup #1

I am using a Pi4 and a Pi3 for testing right now, using the official image based on Debian.

Violet is the pi3, connected over Wifi so I can ssh into it

Tenrec is the pi4, connected by a 10BT patch cable to violet. Tenrec has a 7" screen and kbd.

Tools you will be be needing.

apt install tcpdump

IPIP tunnels

cat /etc/modules-load.d
cat > ip_tunnel.conf
tunnel4
ipip

reboot

Now you have an unconfigured interface called tunl0. I add a new one, tun0

On violet,

ip tunnel add tun0 mode ipip remote 192.168.1.2
ip addr add 44.127.9.2/24 dev tun0
ip link set tun0 up

On tenrec,

ip tunnel add tun0 mode ipip remote 192.168.1.1
ip addr add 44.127.9.1/24 dev tun0
ip link set tun0 up

ping 44.127.9.1

Test setup #2

Two virtual machines are used. This simulates a Pi deployed someplace on a Comcast link. (Or any other ISP, or even a wifi link, really.)

Tarra will be the router in deployment.

W6gkd will be the "repeater"; in reality it's a virtual machine at a different service provider.

I set up tunnels and tested them. Some notes on that, similar to the above. I created the module load file, it required one more module on tarra.

cat /etc/modules-load.d
cat > ip_tunnel.conf
tunnel4
ip_tunnel
ipip

I did not reboot, I just used insmod to load them, trusting that the conf file will actually work on next reboot.

Then I did create a script (and run it) like this. It's called "ipip.sh" and it's in the root folder to remind me to sudo first. The 108.x IP is for w6gkd.

ip tunnel add tun0 mode ipip remote 108.161.129.155
ip addr add 44.127.9.2/24 dev tun0
ip link set tun0 up

route

With a similar set up on w6gkd I can ping from tarra to w6gkd with "ping 44.127.9.2" but no echo comes back presumably because of routing issues. I can see packets pop out of the tunnel with tcpdump at the far end.

In test or deployment, at this point I need the AMPR router daemon installed. See these set up instructions.

apt-get install tcpdump dnsutils iptables-persistent ipset fail2ban lynx

I had fail2ban installed already on both machines, which means that iptables was also installed already and could be the whole problem. My iptables skills are rusty.

"iptables -L" shows me that about 100 sites have been ssh banned. It also told me that FORWARD was DROP on w6gkd hmmm.

iptables -A INPUT -p 4 -j ACCEPT
iptables -A INPUT -p udp --dport 520 -j ACCEPT
iptables -P FORWARD ACCEPT

# Drop various services we don't want running over the tunnel, mostly Microsoft stuff
iptables -A OUTPUT -o tun0 -p udp --dport 10001 -j DROP
iptables -A OUTPUT -o tun0 -p udp --dport 137:139 -j DROP
iptables -A OUTPUT -o tun0 -p udp --dport 5678 -j DROP 
# Drops destination unreachable replies to various probe responses saving bandwidth
iptables -A OUTPUT -o tun0 -p icmp --icmp-type destination-unreachable -j DROP

# This prevents nested ipencap see https://ohiopacket.org/xrpi/docs/ipencap.htm
iptables -t raw -I PREROUTING -p 4 -i tun0 -j DROP
# This prevents a general loop
iptables -I FORWARD -i tun0 -o tun0 -j DROP
# Drops outbound unassigned IPs from looping though tunl0 via ipencap
# You must add accept rules under this line to make exceptions
# Drop traffic that does not have one of our 44 addresses on it.
iptables -I FORWARD ! -s 44.127.9.0/24 -o tunl0 -j DROP

"Other"

I also have tried GRE tunnels and Wireguard. Wireguard is actually deployed on tarra but not used for the repeater links.

GRE tunnels

Not working the way I expect,

Basics

• https://david-waiting.medium.com/a-beginners-guide-to-generic-routing-encapsulation-fb2b4fb63abb
• https://www.xmodulo.com/create-gre-tunnel-linux.html

Types and basic commands

On Raspbian I had to create a file to load the modules at boot, in this order.

cd /etc/modules-load.d
cat > gre_tunnel.conf
gre
ip_tunnel
ip_gre

I reboot at this point and make sure the modules are loading, with

lsmod | grep gre

TUN interface - encapsulates ether header

The "gre0" interface exists so if I try to use the first command with gre0 I get an 'exists' error, I could follow the first example above and use "tun0" instead of "gre0"?

On violet,

ip tunnel add tun0 mode gre remote 172.16.123.1 local 172.16.123.2 ttl 255
ip addr add 10.10.10.1/24 dev tun0
ip link set tun0 up

On tenrec, the other way round,

ip tunnel add tun0 mode gre remote 172.16.123.2 local 172.16.123.1 ttl 255
ip addr add 10.10.10.2/24 dev tun0
ip link set tun0 up

To shutdown simply use, then press on and test TAP.

ip link set tun0 down

TAP interface - no ether header

On violet,

ip link add tun1 type gretap remote 172.16.123.1 local 172.16.123.2 dev eth0
ip addr add 10.10.10.1/24 dev tun1
ip link set tun1 up
ip -d link show tun1

On tenrec, going the other direction,

ip link add tun1 type gretap remote 172.16.123.2 local 172.16.123.1 dev eth0
ip addr add 10.10.10.2/24 dev tun1
ip link set tun1 up
ip -d link show tun1

I need some sample commands here to confirm the links actually work.

ping 10.10.10.1
ping 172.16.123.1

tcpdump -i tun0

Wireguard

Wireguard is an encrypted tunnel that is easy to set up.

Instructions and download are available from https://github.com/WireGuard/wireguard-vyatta-ubnt/wiki/EdgeOS-and-Unifi-Gateway