- Edit the
level=0value to1insidesettings.conf(sudo nano your_path_to/settings.conf).
rtkbase/settings.conf.default at a596c9d13edbe6a24e5912396337bd574a187842 · Stefal/rtkbase · GitHub - Reboot
- copy/paste here the str2str_tcp.log content (inside rtkbase/logs/)
The Janceling image has a normal Raspian OS. You can log in to the GUI if you need to access it.
2 Likes
I just made a quick test with 2022-04-04-raspios-bullseye-arm64.img
Everything seems ok, the str2str_tcp service starts correctly after a reboot.
1 Like
Just curious as to how you access this? It boots to the CLI.
SSH and HTTP are working fine, I didn’t even realise there was a Linux gui 
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.
5 Likes
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.
1 Like
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.
12 Likes
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.
4 Likes
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.
1 Like
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:
- Change all passwords before you connect anything to your network.
- Only port forward any services you actually need external access to. It’s probably best not to make the http front end publicly accessible, but rather use a VPN to connect to a client on the inside of your firewall and use a browser on that client to view the page locally.
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.
2 Likes
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.
5 Likes
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:
- Don’t run the ntrip caster service as the root user (I assume RTKBase already does does this)
- Keep RTKBase updated, both the underlying OS, and RTKBase itself. This can be a bit of burden in an appliance-like device like this
- It’s possible to configure the Rasbian to only allow connections to port 2101 from certain IP addresses. Although it’s hard to know and predict what IP addresses a cell connection may come from.
- Set up a port knocking firewall, either on the pi itself or your router, that allows sources outside your network to connect to port 2101 only after making attempts to access other ports (which are also forwarded to your Pi but don’t have any service on them) in a certain sequence. This is called port knocking. There’re actually apps on Android to knock on ports that would work here. Knock on the ports, then connect to ntrip. This is probably easiest to do on the router itself, provided you had a router that could run and configure Linux on. Many routers can run OpenWRT, for example. Apparently Mikrotik routers can be set up to do this also: Port Knocking - MikroTik Wiki
- Since NTRIP is based on http, can use a web server like nginx to proxy (and thus filter and sanitize the requests) traffic to the ntrip caster. I’ve not actually used RTKBase, so maybe he already does this and I’m not aware.
- Place the Pi on its own network segment (vlan, or router) which is isolated from the rest of your network. If it gets hacked through a buffer overrun, the damage a bad guy can do is limited.
Is this something you should be worried about? Probably not so much, but it’s good to be aware that there are some risks.
2 Likes