Welcome to the new FlexRadio Community! Please review the new Community Rules and other important new Community information on the Message Board.
Need the latest SmartSDR, Power Genius, Tuner Genius and Antenna Genius Software?
SmartSDR v3.8.20 and the SmartSDR v3.8.20 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
SmartSDR v3.8.20 and the SmartSDR v3.8.20 Release Notes
SmartSDR v2.12.1 and the SmartSDR v2.12.1 Release Notes
Power Genius XL Utility v3.8.9 and the Power Genius XL Release Notes v3.8.9
Tuner Genius XL Utility v1.2.11 and the Tuner Genius XL Release Notes v1.2.11
Antenna Genius Utility v4.1.8
If you are having a problem, please refer to the product documentation or check the Help Center for known solutions.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
Need technical support from FlexRadio? It's as simple as Creating a HelpDesk ticket.
L3 VPN Remote Solution with WireGuard
tzmitch
Member ✭
I operate my station remotely only. Currently it is installed at my parents house about 6 miles away from my own, but I am considering moving it to a second home in the mountains of western North Carolina where the only Internet service is a Wireless ISP using Carrier Grade NAT. The router there is owned and controlled by the ISP. The goal of this exercise was to develop a remote solution that is not dependent on SmartLink. SmartLink does not work with CGNAT. Outside of SmartLink, SmartSDR requires broadcasts from the radio to find available radios. This is a design decision they’ve made and, like their approach to remote CW, it’s something I have to figure out how to work around. As much as I don’t like those decisions, I still think the Flex solution is still easier to use than the Elecraft KX3 & RemoteRig solution I used for years before.
There are multiple users and devices at each location so I was unwilling to use one of the L2 bridged VPNs as the filtering and micromanagement of addresses and broadcasts introduced overhead I didn’t want to deal with. Judging from comments, there are plenty of people who have solved this problem before but I had a hard time finding any of those people who thoroughly documented what they did. This is my attempt at documenting how I enabled access to my Flex Radio without SmartLink and without resorting to a layer two VPN. It is based on a WireGuard VPN, a tiny app from HB9FXQ that forwards the UDP broadcasts that enable radio discovery, a couple of static routes and a little bit of TCP tweaking. All of those things run on the Raspberry Pi. The remote site also houses a Windows machine used for radio stuff and with AnyDesk, gives me an alternate method of connecting into the remote network.
I’m using two Rasperry Pi devices:
radiopi, 192.168.1.126, lives at the remote site with the radio
pi-hole, 192.168.86.239, lives at my home and will function as the “server” side
These devices are using reserved DHCP addresses because I find that easier than statically assigning addresses. Each site also has a dynamic DNS entry. Where possible I use hostnames rather than IP addresses.
I installed PiVPN on each Raspberry Pi:
https://www.pivpn.io/
I largely followed the instructions here:
https://pimylifeup.com/raspberry-pi-WireGuard/
and here:
https://www.youtube.com/watch?v=yc9PEM1ovg0
Since I have a reserved IP addresses in the DHCP scope configured on the routers for each Raspberry Pi, I selected Yes when prompted.
I opted for WireGuard rather than OpenVPN when prompted
I used the default 51820 port for WireGuard. On the server/home site router I forwarded this port to the Raspberry Pi at my house.
I am using Pi-hole for DNS on the same Raspberry Pi at my house. The installer recognized that and used it for DNS resolution. I used Cloudflare at the remote site.
After enabling automatic upgrades and such, I rebooted both Raspberry Pi’s
I ran “pivpn add” on the server side Pi and created a profile called “radio.” This doesn’t do a whole lot besides put the correct keys in.
I added a number of things to the radio.conf profile after copying the contents to radio.conf on the remote Pi. 10.6.0.0/24 is the address of the tunnel. This doesn’t exist anywhere. 192.168.86.0/24 is the “server” side. 192.168.1.0/24 is the remote side where the radio lives. This file tells WireGuard to send traffic to 192.168.86.0/24 over the tunnel. The file /etc/WireGuard/radio.conf on radiopi looks like this:
[Interface]
PrivateKey = <private key is here>
Address = 10.6.0.2/24
DNS = 10.6.0.1
MTU = 1420
PostUp = iptables -A FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[Peer]
PublicKey = <public key>
PresharedKey = <Preshared key>
Endpoint = <remote public address/name>:51820
AllowedIPs = 10.6.0.0/24, 192.168.86.0/24
PersistentKeepalive = 25
The “server” side uses /etc/WireGuard/wg0.conf edited to look like this:
[Interface]
PrivateKey = <private key>
Address = 10.6.0.1/24
MTU = 1420
ListenPort = 51820
### begin radio ###
[Peer]
PublicKey = <public key>
PresharedKey = <presharedkey>
AllowedIPs = 10.6.0.2/32, 192.168.1.0/24
### end radio ###
<end part 1>
There are multiple users and devices at each location so I was unwilling to use one of the L2 bridged VPNs as the filtering and micromanagement of addresses and broadcasts introduced overhead I didn’t want to deal with. Judging from comments, there are plenty of people who have solved this problem before but I had a hard time finding any of those people who thoroughly documented what they did. This is my attempt at documenting how I enabled access to my Flex Radio without SmartLink and without resorting to a layer two VPN. It is based on a WireGuard VPN, a tiny app from HB9FXQ that forwards the UDP broadcasts that enable radio discovery, a couple of static routes and a little bit of TCP tweaking. All of those things run on the Raspberry Pi. The remote site also houses a Windows machine used for radio stuff and with AnyDesk, gives me an alternate method of connecting into the remote network.
I’m using two Rasperry Pi devices:
radiopi, 192.168.1.126, lives at the remote site with the radio
pi-hole, 192.168.86.239, lives at my home and will function as the “server” side
These devices are using reserved DHCP addresses because I find that easier than statically assigning addresses. Each site also has a dynamic DNS entry. Where possible I use hostnames rather than IP addresses.
I installed PiVPN on each Raspberry Pi:
https://www.pivpn.io/
I largely followed the instructions here:
https://pimylifeup.com/raspberry-pi-WireGuard/
and here:
https://www.youtube.com/watch?v=yc9PEM1ovg0
Since I have a reserved IP addresses in the DHCP scope configured on the routers for each Raspberry Pi, I selected Yes when prompted.
I opted for WireGuard rather than OpenVPN when prompted
I used the default 51820 port for WireGuard. On the server/home site router I forwarded this port to the Raspberry Pi at my house.
I am using Pi-hole for DNS on the same Raspberry Pi at my house. The installer recognized that and used it for DNS resolution. I used Cloudflare at the remote site.
After enabling automatic upgrades and such, I rebooted both Raspberry Pi’s
I ran “pivpn add” on the server side Pi and created a profile called “radio.” This doesn’t do a whole lot besides put the correct keys in.
I added a number of things to the radio.conf profile after copying the contents to radio.conf on the remote Pi. 10.6.0.0/24 is the address of the tunnel. This doesn’t exist anywhere. 192.168.86.0/24 is the “server” side. 192.168.1.0/24 is the remote side where the radio lives. This file tells WireGuard to send traffic to 192.168.86.0/24 over the tunnel. The file /etc/WireGuard/radio.conf on radiopi looks like this:
[Interface]
PrivateKey = <private key is here>
Address = 10.6.0.2/24
DNS = 10.6.0.1
MTU = 1420
PostUp = iptables -A FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
PostDown = iptables -D FORWARD -i wg0 -m state --state RELATED,ESTABLISHED -j ACCEPT; iptables -D FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
[Peer]
PublicKey = <public key>
PresharedKey = <Preshared key>
Endpoint = <remote public address/name>:51820
AllowedIPs = 10.6.0.0/24, 192.168.86.0/24
PersistentKeepalive = 25
The “server” side uses /etc/WireGuard/wg0.conf edited to look like this:
[Interface]
PrivateKey = <private key>
Address = 10.6.0.1/24
MTU = 1420
ListenPort = 51820
### begin radio ###
[Peer]
PublicKey = <public key>
PresharedKey = <presharedkey>
AllowedIPs = 10.6.0.2/32, 192.168.1.0/24
### end radio ###
<end part 1>
0
Comments
-
The PostUp and PostDown lines (those are each single lines) fiddle with the TCP Maximum Segement Size and drive it down to match the Path MTU. From what I understand, the MTU setting on the Flex Radio only affects the UDP broadcasts and not the TCP flows. Without this I could discover the radio and connect to it, but would not send me audio or paint the waterfall and would disconnect after several seconds. Packet dumps showed the TCP connections being set up, so I had connectivity but it didn’t last. HB9FXQ also mentioned this being necessary, but his understanding of iptables far surpasses mine to the point that it was difficult for me to know how to apply it (I can adjust MSS on a Cisco device, but not iptables). Fortunately I found someone else doing this with WireGuard and learned that it will apply those lines when the tunnel goes up and down.
I brought the WireGuard tunnels down and up.
Radio side:
wg-quick down radio
wg-quick up radio
Server side:
wg-quick down wg0
wg-quick up wg0
The routers at the remote sites needed static route entries that route the remote site via the Raspberry Pi local to it. For example, the router at the radio location needed a static route for 192.168.86.0/24 (my home network) pointing to the address of radiopi, 192.168.1.126.
At this point I had end to end connectivity. I could, for example, hit the inside address of the router at the radio site from my home PC. It also means that I can connect to Elecraft KAT500 ATU using the internal 192.168.x.x address and do away with the port forwarding on the remote router.
I used HB9FXQ’s flex6k-discovery-util-go program to forward those pesky UDP broadcasts from the radio:
https://github.com/hb9fxq/flex6k-discovery-util-go
This utility will pick up UDP 4992 packets from the radio and forward them to the server side where another copy of the utility dumps them out as broadcasts on the local network where I’m running SmartSDR.
Radio side:
./flex6k-discovery-util-go --SERVERIP=192.168.1.126 --SERVERPORT=7777
192.168.1.126 is the local ethernet interface of the Raspberry Pi at the radio site.
On the server/home side:
pi@pi-hole:~ $ ./flex6k-discovery-util-go --REMOTES=192.168.1.126:7777 --LOCALIFIP=192.168.86.239 --LOCALPORT=7788
192.168.86.239 is the Raspberry Pi at the house/server site.
Start both sides and the radio will show up in the chooser without using SmartLink. It only needs to run to find the radio. You can stop it after you connect. You can also do this with socat, but I like Frank’s little program because you get some good feedback from it. It looks like this when it’s working. The radiopi side was started first and receives several broadcasts before the home side registered with it. Once that happens you can see the radio side start forwarding packets to it.
pi@radiopi:~ $ ./flex6k-discovery-util-go --SERVERIP=192.168.1.126 --SERVERPORT=7777
APP Identified local IPs: 0.0.0.0 127.0.0.1 127.0.0.1 ::1 192.168.1.126 fe80::864:e4cc:5b46:f278 10.6.0.2
SRV listening for registrations on: 192.168.1.126:7777
SRV BROADCAST RECEIVED [192.168.1.10:4992]
SRV BROADCAST RECEIVED [192.168.1.10:4992]
SRV BROADCAST RECEIVED [192.168.1.10:4992]
SRV BROADCAST RECEIVED [192.168.1.10:4992]
REGISTRATION R;192.168.86.239;7788 from 192.168.86.239:55197
SRV: Number of regs: 1
SRV BROADCAST RECEIVED [192.168.1.10:4992]
==> Notifying remote [R;192.168.86.239;7788]
SRV BROADCAST RECEIVED [192.168.1.10:4992]
==> Notifying remote [R;192.168.86.239;7788]
SRV BROADCAST RECEIVED [192.168.1.10:4992]
pi@pi-hole:~ $ ./flex6k-discovery-util-go --REMOTES=192.168.1.126:7777 --LOCALIFIP=192.168.86.239 --LOCALPORT=7788
APP Identified local IPs: 0.0.0.0 127.0.0.1 127.0.0.1 ::1 192.168.86.239 2603:6080:280a:6ba8:189e:43f8:5d4f:8ac fe80::3a69:dfc5:5289:98db 10.6.0.1
==> Notifying remote [192.168.1.126:7777]
CLT RECEIVED PKG FROM SRV @ 192.168.1.126
broadcasting in local subnet
CLT RECEIVED PKG FROM SRV @ 192.168.1.126
broadcasting in local subnet
CLT RECEIVED PKG FROM SRV @ 192.168.1.126
broadcasting in local subnet
CLT RECEIVED PKG FROM SRV @ 192.168.1.126
broadcasting in local subnet
CLT RECEIVED PKG FROM SRV @ 192.168.1.126
I need to automate running this program. I haven’t decided how I will do this yet.
Lastly, configure WireGuard to start the tunnel on the remote side. The wg0 interface comes up automatically on the server side.
pi@radiopi:~ $ sudo systemctl enable wg-quick@radio
Created symlink /etc/systemd/system/multi-user.target.wants/wg-quick@radio.service → /lib/systemd/system/wg-quick@.service.
pi@radiopi:~ $
With this solution the audio to and from the radio is not compressed like it would be with SmartLink. Still, it’s better than not working at all. A layer two VPN between the sites with many more broadcasts crossing the tunnel would only exacerbate that bandwidth problem. In running it for a day I still get drops with about the same regularity that I do with SmartLink. I think this is largely due to my parents' ISP. It comes and goes. I’ll get a more thorough test with CW Sweepstakes this weekend.
I hope this helps someone looking to do the same thing.
73
Tommy WZ4M0 -
To automate the discovery tool on both sides to start on boot, just use systemd.
I've copied mine to https://gist.github.com/hb9fxq/f4a51f0b3db496792ae02ccb2a038bfb for reference.
1 -
Frank, once again you have been super helpful. I have this on radiopi:
pi@radiopi:~ $ cat /etc/systemd/system/flexi.service
[Unit]
Description=flex radio discovery
Wants=network-online.target
After=network-online.target
[Service]
ExecStart=/home/pi/flex6k-discovery-util-go --SERVERIP=192.168.1.126 --SERVERPORT=7777
Restart=always
RestartSec=10
StandardOutput=null
[Install]
WantedBy=multi-user.target
pi@radiopi:~ $
And this on pi-hole at the house:
pi@pi-hole:~ $ cat /etc/systemd/system/flexi.service
[Unit]
Description=flex radio discovery
Wants=network-online.target
After=network-online.target
[Service]
ExecStart=/home/pi/flex6k-discovery-util-go --REMOTES=192.168.1.126:7777 --LOCALIFIP=192.168.86.239 --LOCALPORT=7788
Restart=always
RestartSec=10
StandardOutput=null
[Install]
WantedBy=multi-user.target
pi@pi-hole:~ $
I've set these to start automatically using the guide Frank pointed me to here:
https://www.shubhamdipt.com/blog/how-to-create-a-systemd-service-in-linux/2
Leave a Comment
Categories
- All Categories
- 260 Community Topics
- 2.1K New Ideas
- 538 The Flea Market
- 7.6K Software
- 6K SmartSDR for Windows
- 147 SmartSDR for Maestro and M models
- 367 SmartSDR for Mac
- 242 SmartSDR for iOS
- 236 SmartSDR CAT
- 175 DAX
- 345 SmartSDR API
- 8.8K Radios and Accessories
- 7K FLEX-6000 Signature Series
- 43 FLEX-8000 Signature Series
- 859 Maestro
- 43 FlexControl
- 837 FLEX Series (Legacy) Radios
- 807 Genius Products
- 424 Power Genius XL Amplifier
- 280 Tuner Genius XL
- 87 Antenna Genius
- 227 Shack Infrastructure
- 153 Networking
- 409 Remote Operation (SmartLink)
- 119 Contesting
- 639 Peripherals & Station Integration
- 116 Amateur Radio Interests
- 821 Third-Party Software