I added a note specifically about the introducer here. I think youre right, if an Introducer is known to two devices, that introducer should be able to share the connection information with a new peer.
even without the introducer bit, the local discovery should still work on your home network. Then in your server which stays at home, you “announce” your address through the VPN and it’s stored on your laptop. Laptop and server connect happily when you’re home. Then you take the laptop with you, it knows about the VPN target since the server sent the VPN address and it’s cached on the laptop.
After rereading the paragraph above, I realized that I’m not entirely clear on the network setup…
Are your home computers also connected to your OpenVPN server?
If they aren’t – and assuming that the OpenVPN server is forwarding traffic between the two subnets – then all that’s needed on your iOS device is to append the appropriate tcp://syncthing-server entry for each configured device. No changes to the home computers, local discovery, discovery server or introducer required.
My home computers are not connecting through the OpenVPN tunnel, the OpenVPN tunnel is only used to connect back home when I need to access my NAS, have Syncthing sync, or RDP into a VM.
I’m not using Syncthing on iOS, I only mentioned it because Apple does not allow layer 2 VPN connections and thus I cannot created a “bridged” VPN as someone suggest, nor would I want to. Even if they did allow this, it’s typically frowned upon to use bridging for VPN connections due to the increased traffic from broadcasts from network services, having to worry about collisions (i.e., if my home network is on a 192.168.0.X subnet and I try to connect from a “guest network” that is also using a 192.168.0.X subnet) and a multitude of other concerns that arrive from bridging a VPN connection.
Outside of that, what you mentioned regarding manually entering in the appropriate tcp://syncthing-server in the “Addresses” field on each configured device, (in this case it would be any device that may leave the house), that’s what I’m currently doing and it works as intended with my “remote” devices successfully being able to connect to “Syncthing-Server” and “Hyper-V” over the VPN.
The question I was raising, was whether that could be automated, so that I don’t need to manually configure it on each “remote” client. Instead, the introducer would populate those fields upon initially adding a client or through it’s usual propagation method that automatically updates information for all clients.
I think “mraneri” understands the request, effectively Syncthing would have a “phonebook” of last seen addresses that it would try in the event that broadcast/discovery fails (which would be the case with a layer 3 VPN, or any time routing occurs).
Unfortunately, with hundreds of millions of private LANs in use, even without a network bridge there will be collisions when a remote Syncthing device happens to be connected to a guest LAN occupying the same IP range as your home LAN and Syncthing tries to “phone home”.
While technically true, it’s trivial to resolve this by making the VPN tunnel IP schema to something that would never be used when connecting to a guest network. For example, if we choose an IP scheme of 192.168.254.X with a subnet mask of 255.255.255.248, this would leave us with 6 usable hosts for our VPN. VPN clients would route traffic through the tunnel to the “router”, which lives at 192.168.254.1, which would then route to the appropriate LAN address. OpenVPN is configured with the “redirect-gateway” directive, meaning ALL VPN traffic goes through the tunnel and is routed by the router on the other side of the tunnel (in this case my Windows Server box with RRAS). With this setup, we don’t care what the remote network has for an IP schema, it doesn’t matter because all routing and DNS goes through the tunnel to the server on the other end at home.
Additionally, I’m using a layer 3 tunnel for the reasons already gave regarding additional overhead, but I also connect home on iOS to access the NAS or perform email checking or web browsing. All that data goes directly through the tunnel to ensure it’s secure, especially when on a guest networks that are wide open SSIDs.
