Honestly I know very little about linux and even computers generally. Perhaps I’ve changed the boot options, really cannot remember. Hopefully experts can suggest the best approach.
Anyway, if I have the Pi at reach, I can log on with a keyboard and a display. Usually I access the Pi remotely with VNC Viewer. Opens directly the Raspian GUI.
So I’ve been playing this morning with an open source peer-to-peer VPN system, based on wireguard, called TailScale that would be an idea addition to RTKBase. Several people have commented about security issues with NTRIPv1 protocol not being encrypted, and privacy implications of data on rtk2go. TailScale solves all this quite nicely, and eliminates the need to use rtk2go at all, provided you RTKBase can be its own local ntrip caster. Just have your phone or the AOG tablet connect to your VPN and get the NTRIP connection directly.
TailScale is the VPN solution I’ve been waiting years for. I say that having run my own OpenVPN network for decades. It’s peer-to-peer, meaning there is no central server, other than a coordinating server that helps the nodes find each other and their public keys. The actual vpn traffic does not pass through TailScale’s servers at all. Traffic goes direct from computer to computer, thanks to UDP NAT traversal. Being peer to peer, if you had two devices on your tailscale vpn who happened to be on a local WLAN, they actually wouldn’t send any traffic over the internet, but direct to each other.
Wireguard (well-known open source) is used to secure and authenticate these connections using public key encryption. TailScale hides away the complexity of key management, making it fast and easy to set up. Tailscale passes the public version of those keys to all your participating nodes. Tailscale never sees your devices’ generated private keys.
I sound like an advertisement. haha. I am super impressed. I’ve never seen any VPN of this nature that was as easy to set up and manage as this. Adding nodes does not require any passwords to be entered or stored on the devices; instead nodes generate an encryption key and a one-time URL that you enter into the browser to register the node. If RTKBase shipped with TailScale, there’d have to be just a couple of minor manual steps on the command line to register it with your network.
There are clients for Android and iOS in their respective stores, and clients for Linux, Windows, and Mac.
Superb.
After our last discussion on this, I had planned to fully pentest this system as I was concerned about security.
Not got around to this yet, but a VPN is a perfect solution.
To follow up on my comment, Tailscale is based on open source technologies, and the client is fully open source. Their coordinating server and web administration system is proprietary. For nearly all of us, the personal plan would fit our needs and is free. Even if it costed something ($60 USD a year for the next plan up), it’d be well worth the cost.
Not sure if it is appropriate to request more info about NTRIP security issues here but a short summary or links to previous discussions would be helpful.
Stefal’s RTKBase can already do the NTRIP caster task, no need to use RTK2GO if that brings privacy or other concerns. Now I have to run my caster with NTRIPv1 mode because of tractors with commercial products that only support V1. Does that open my home network to some serious risks? Would it help if I continue supporting my V1 rovers but moved to a more secure approach with AOG (on the tractor that is using AOG)?
I am embarrassed.
When I started developing RTKBase, it was primarily for my use. What I wanted was to get more precision for my contributions to the OpenStreetMap project.
At the same time, a caster open to all was created in France (centipede), which led to the implementation of new base stations, open to all. 3 years later, we have more than 250 GNSS Bases. A farmer can use his own base, he can also use his neighbor’s base if his one is down. On my side, I can cross the country while remaining almost always with RTK Fix. All this without any paid subscription. If someone around me uses my base, it makes me pretty happy: this GNSS base is useful to others than to me.
And now you ask me if I could integrate some features to make the GNSS base more private? This is the exact opposite of what I wanted when I created RTKBase.
I’m really embarrassed.
I understand that people are concerned about their privacy, I am too, but is removing the sharing of GNSS bases between users really the right solution? Couldn’t we do something different?
I think we could discuss this in another thread.
I’m quite surprised by the mention of a security problem using ntrip on an open network. it seems to me very improbable that we can access my private network from a connection to an ntrip server since only outgoing connections are authorized to this server. Moreover, what is the point of using a private ntrip server while a tcp connection does the job very well. and to join the opinion of stefal I am delighted to give the possibility to anyone to use my database especially within the framework of an open source project
RTKBase is excellent, you have nothing to be embarrassed about.
Maybe another simple solution to any security concerns is to place the RTKBase server on a dirty DMZ. I’ll sit down and have a proper look at this when I get the chance. The problem now is that the world has become very security conscious because some people like to destroy the work of other.
Either way, I thank you for developing it and giving your work away for free.
Security is too broad a term. It’s not like anyone can “hack” you via an unencrypted NTRIP stream. At worst some bad actor working for a network (or a bad actor that hacks into network infrastructure) could alter the stream. There is some concern about precise GPS coordinates being available for anyone to see. In fact I regularly see screenshots posted on this forum where the GPS coordinates are blurred out, and certainly in YouTube videos. And this is understandable.
I appreciate the hard work you have put into RTKBase, @Stefel, and your goals and aims for democratizing RTK. You have definitely succeeded. Hopefully others, including me, can contribute back to RTKBase one way or another.
For me the VPN isn’t so much about security or privacy as it is about making it easier to reach my base station. RTK2Go is a wonderful service, but I’d rather reach my base station directly, within my own private network, than go through another party. Modern network design, for good or bad, means everything on our side of the router is unreachable from the internet (until we get IPv6!), and many of us don’t even have a real IP address that is reachable anyway. A VPN solves the problem quite nicely for me. Just seems like a natural addition to RTKBase. In the future I’ll probably post some detailed instructions on how to install it on the Pi.
I’ve never had any real issues with RTK2Go, other than the times when my base station’s connection to it drops, leaving me waiting in the field. I’m hoping that a direct connection through the VPN will be more reliable. Plus the VPN gives me the convenience of putting my tablet virtually on my home network so I can more easily log into the Pi to check things, or restart something. VPNs are powerful tools; I’ve used a VPN (OpenVPN) to access my home network for decades.
Security is a broad term and a broad subject.
Have to admit that I’ve become a little rusty, but I used to work in network security for an ISP and my first question with something like a base station would be, “Can I exploit any service on this device and use that as a bridgehead into the network?”
Anything that forwards any traffic into a network must be considered a potential security risk until proven otherwise. With regard to NTRIP, can traffic be spoofed and shaped, for example? A quick look online suggests it could be:
This doesn’t represent an obvious risk to your network, but it does open possibilities for hijacking autonomous systems which is “interesting”.
One very obvious thing that needs stating is that anyone using remote SSH must change the default passwords immediately! If some idle script kiddie notices that port 2101 is open alongside port 22, then they could try logging into your base station pi with the default credentials and if they work, our “hacker” now has root access to a Linux box on your network. I cannot overstate just how bad that is 
So best practice would probably be:
Basically minimise the number of ports you forward on your firewall.
“For me the VPN isn’t so much about security or privacy as it is about making it easier to reach my base station.”
You don’t need a VPN to reach your base station over the internet. Maybe I’m misunderstanding something, but isn’t it just a case of forwarding port 2101 to your base station?
I do agree with you on RTK2go though. I’ve fought hard to get my BS registered with them so that I can share it with the locals, but now I am wondering whether this does compromise security. It’s far more secure to just keep it all private and give your WAN IP to people you know.
“Modern network design, for good or bad, means everything on our side of the router is unreachable from the internet”
Again, I may be misunderstanding you here, but pretty much any TCP/IP service can be shared over the internet via NAT / port forwarding. This is the whole point of NAT, with it, you can share tens of thousands of devices and services from a single public IP using IPv4.
IP6 means that every device can have its own unique IP, but with a bit of port forwarding on your firewall you can share whatever you want with over the internet with v4.
I do completely agree with you that VPNs are the way forward with AOG base station hosting, in fact VPNs will soon become ubiquitous. The very first thing I do every day for work is fire up my works laptop and connect to the VPN as this means that I am effectively (logically) sat at my desk in the company offices, securely connected to the company network whilst I am physically sat, unshaven, on my sofa in my underpants.
VPNs are what make secure home working possible.
With regards to punching holes in the firewall, I agree. NTRIP, however, was designed to avoid that problem by having a local NTRIP server connect to the NTRIP caster in the cloud and push data up. There are no inbound connections involved when using something like RTK2Go. Obviously if you want to talk directly to your own NTRIP caster, the VPN is the only way to safely do this.
As to my comment about NAT, what I mean is NAT is one-way by nature. If you’re behind a NAT, which most of us are, it’s very difficult to publish a port to the world. Many of us don’t even have public IP addresses associated with our router. So there’s no forwarding that can be done even if I wanted to (and understood the risks).
Yes IPv6 will change things quite a bit. Theoretically with IPv6 it’s all about firewalling and ACL. No NATs would be required. Even VPNs aren’t necessarily needed if things are done correctly. Reaching a node would be a matter of making sure the firewall allows it. Unfortunately most of the ISP world has forgotten how to do network security with just firewalls and access control lists, instead relying on NAT. Sadly I think most ISPs when they do roll out IPv6 are still going to use a form of NAT. I’m pretty sure the ISP industry at large is no more interested in an open internet under IPv6 than they are now.
Ahhh, right, sorry. I am behind with this and will RTFM when I get the chance 
NAT is confusing at first, but it’s actually quite simple with a little practice. Everyone who is connected to the Internet has two IP addresses, a public one (WAN IP) and private (LAN IP). Without getting into the details, all you need to do is to record the LAN address of any host (computer) publishing a service to the internet (typcally 192.168.x.x) and note the port that it is using (NTRIP uses 2101). Log onto your firewall and add a NAT rule allowing traffic to that address on that port.
Example: my RTKBase station has a LAN address of 192.168.1.100, so I log onto my router, go into NAT Settings (sometimes known as “port forwarding”) and add a rule pointing all port 2101 requests to 192.168.1.100.
My router has a WAN IP address of eg 212.100.129.250. So now anyone can connect to my NTRIP server by browsing to http://212.100.x.x on port 2101. The router receives a request to permit this inbound connection and checks its NAT table. On that table in a rule stating that any port 2101 requests should be forwarded to 192.168.1.100.
Let’s say I also have a Linux web server on my network which serves content on port 80 (HTTP) and 443 (HTTPS). This server has the LAN address of 192.168.1.80. I log onto my router and add two more rules allowing port 80 and 443 requests to 192.168.1.80.
Finally, I have an FTP server because I want to share some files over the internet to some friends. This server has the LAN address of 192.168.1.21 FTP works on port 21, so I add another NAT rule pointing any inbound requests on port 21 to 192.168.1.21.
If i want to add a simple layer of security, I can specify the WAN addresses of my friends’ and permit traffic only from these. That means that nobody else is able to connect to this service.
That’s basically how NAT works.
You’re correct though, ideally you need a static WAN address for this so this address does not change. You can get it to work with dynamic WAN addresses, but this takes a bit of configuration. You can use DYNDNS for this, or just get a bit crafty. One dirty solution I sometimes use with dynamic WAN IPs is to create a rule on a box inside my network that sends an email every hour to a certain address. If you look at the headers of this email, then you can extract the originating WAN IP and these addresses can remain unchanged for days. Input this address into your clients which are trying to connect and now they know where to go.
So you can forward traffic via NAT even on a dynamic IP, but it’s usually dirty. DYNDNS is a better solution.
Networks are my thing and if I can ever help anyone with any network queries, then please ask.
Yup I’ve been working in a professional capacity for many years also. I used to know ios really well. I also tend to assume others know about networking, routing, and address translation. My bad!
What I mean is the wan on my router has a private IP address. I can’t expose any ports whatsoever on the internet. This is the case for a lot of people, particular when you’re on a cell connection. My public-facing IP address is shared with dozens maybe hundreds of other customers which often causes Google to flag my traffic as suspicious (and also I don’t allow the tracking cookies Google thinks are necessary). I don’t have any ipv6 here either and likely never will. So I’m behind several layers of nat.
I have a vps I can host services on and even proxy my private network services through it, but for now the VPN works wonderfully.
Sorry man, I did mean to caveat that you probably know all this, but I have had a few questions about it wanted to provide a general “how to”. If you know ios, then know Cisco which means you know your networks.
My thinking has all been based on a bunch of assumptions, basically your base being connected to a high speed network.
I would be interested in where you are and what technologies are available in your region. Some years back I did some work designing and building mesh networks in Ghana and Mozambique and I have some familiarity with rural networks in Australia so may have some ideas.
I’m just a beginner at these IP stuff. So forward port 2101 to allow access to my RTKbase could open the door for a hacker to introduce in my home network(on my other computers)?
There’s always a potential that the ntrip caster service running in RTKBase might have an undiscovered bug (most likely a buffer overrun in the parsing and processing of HTTP requests) that could allow a bad guy to convince the caster to run arbitrary code on your Pi, compromising it. However I’d rate the risk as somewhat low. A few mitigations for the paranoid:
Is this something you should be worried about? Probably not so much, but it’s good to be aware that there are some risks.
Key phrase is “used to know!” Haven’t worked with it in quite a few years now. It’s nice to see more pro-sumer hardware on the market now that support things like 802.1q trunking for creating network segments. A lot of pro-sumer routers support it too along with more advanced routing, which is nice. It’s always a decent idea to have a “DMZ” for things like RTKBase that you want to expose to the outside world.
Do you listen to Security Now? Just in the last episode or two they talked about port knocking. Never heard of it before.
I used to catch them once in a while. I’ve never used port knocking myself. In fact I run an open ssh server on my VPS on the normal port even. I don’t allow password logins, though. Never had a problem, and never felt the need to port knock. Of course when running a mail and web server, you kind of want people to connect, so port knocking is not so useful there!.
Yes.
Anything that connects to the internet is vulnerable to attack by hackers. The only completely secure computer is one that is locked inside a concrete box to which there is no key and the computer is powered off.
Personally, I work in professional IT and still have a hand in security and my advice is to not worry about it too much.
Observe good practice: do not recycle passwords, change all default passwords immediately, use VPNs for remote connections where practical, back up critical data and encrypt sensitive data.
And then relax, you have taken all reasonable precautions, don’t obsess about it.