Wan Gateway interference #845
Comments
|
Best way I found to achieve is to setup a VPN server at Internet gateway location and route traffic through an unencrypted VPN over the mesh. This way, the traffic will always goes through the wished gateway. Pretty easy to do using a cheap mikrotik router or a raspberry pi with PiVPN. |
|
I do have a Ubiquiti EdgeRouter at my QTH which handles traffic for a few tunnels I am serving up as well as serving as the WAN gateway. It appears I have a few other local gateways that have emerged. Is it possible to configure the WAN on the remote node with devices attached straight to the VPN?Sent from my iPadOn May 21, 2023, at 6:13 PM, VA2XJM Jean-Michel ***@***.***> wrote:
Best way I found to achieve is to setup a VPN server at Internet gateway location and route traffic through an unencrypted VPN over the mesh. This way, the traffic will always goes through the wished gateway. Pretty easy to do using a cheap mikrotik router or a raspberry pi with PiVPN.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
For Ubiquiti device, you will be on your own or someone else will be needed as I have not much knowledge of those devices. Due to some factor (Pi prices and availability, ease of use...) we switched toward Mikrotitk hardware to host this kind of systems. The way I do it, is a Pi or Mikrotik hAP device inside the mesh (10...*) at the location where Internet is available. Until recently, I was using a Raspberry Pi that hosted OpenVPN server (search Pi VPN) and added clients for each system needing Internet access. You may need to put some filtering rules to prohibit use of encryption (ex: HTTPS). Then at each system, I setuped the VPN client and made it default gateway for non-10 address. So mesh traffic goes directly to mesh and Internet traffic will go through VPN-over-mesh. One interesting thing we were doing was to redirect Yaesu Wires-X ports through the VPN for a FTM-100 node feeding repeaters. For AllStarLink, what we do is to run a "hub" VM on the mesh boundary. The hub will connect to outside world and mesh systems runing a 1000-1999 node number will connect to boundary server. This way the link is properly done, quite simple and very easy to monitor and troubleshoot. |
|
Thank you. I sent a follow up to this and am not certain it came through. I currently have a vpn server running however outside the mesh serving as the gateway for my mesh network. I see the benefit of how you are running yours so will make the adjustment.On the client side, are you setting your VPN clients as wan mesh gateways on the node or connecting them to a LAN port for the node? I can see a few ways of doing this and am certain there are pros and cons to each; wan gateway via a switch and VLANs, LAN connection to the node hosting the client device.Thank you,KeithSent from my iPadOn May 21, 2023, at 6:50 PM, VA2XJM Jean-Michel ***@***.***> wrote:
For Ubiquiti device, you will be on your own or someone else will be needed as I have not much knowledge of those devices.
Due to some factor (Pi prices and availability, ease of use...) we switched toward Mikrotitk hardware to host this kind of systems.
The way I do it, is a Pi or Mikrotik hAP device inside the mesh (10...*) at the location where Internet is available. Until recently, I was using a Raspberry Pi that hosted OpenVPN server (search Pi VPN) and added clients for each system needing Internet access. You may need to put some filtering rules to prohibit use of encryption (ex: HTTPS).
Then at each system, I setuped the VPN client and made it default gateway for non-10 address. So mesh traffic goes directly to mesh and Internet traffic will go through VPN-over-mesh.
One interesting thing we were doing was to redirect Yaesu Wires-X ports through the VPN for a FTM-100 node feeding repeaters.
For AllStarLink, what we do is to run a "hub" VM on the mesh boundary. The hub will connect to outside world and mesh systems runing a 1000-1999 node number will connect to boundary server. This way the link is properly done, quite simple and very easy to monitor and troubleshoot.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Jean-Michel,I set up a pi-ovpn server on the same node as my mesh internet gateway as you described. It has a 10.x.x.x address. I then had it create a client script to install for a test at my qth. Initially the client did not link with the server and in trouble shooting I noted the client script was using my internet gateway IP as the endpoint address rather than the ip of the vpn server. When I changed this address in the script, the client connected to the server however I have no internet access that would be needed.As I write this, I am suspecting that the issue Issue might be that both the client and server devices are connected to the same AREDN node vs having the distance and client attached to a separate node as a gateway? Is this a correct assumption or am I missing something?Thank you,KeithSent from my iPadOn May 21, 2023, at 6:50 PM, VA2XJM Jean-Michel ***@***.***> wrote:
For Ubiquiti device, you will be on your own or someone else will be needed as I have not much knowledge of those devices.
Due to some factor (Pi prices and availability, ease of use...) we switched toward Mikrotitk hardware to host this kind of systems.
The way I do it, is a Pi or Mikrotik hAP device inside the mesh (10...*) at the location where Internet is available. Until recently, I was using a Raspberry Pi that hosted OpenVPN server (search Pi VPN) and added clients for each system needing Internet access. You may need to put some filtering rules to prohibit use of encryption (ex: HTTPS).
Then at each system, I setuped the VPN client and made it default gateway for non-10 address. So mesh traffic goes directly to mesh and Internet traffic will go through VPN-over-mesh.
One interesting thing we were doing was to redirect Yaesu Wires-X ports through the VPN for a FTM-100 node feeding repeaters.
For AllStarLink, what we do is to run a "hub" VM on the mesh boundary. The hub will connect to outside world and mesh systems runing a 1000-1999 node number will connect to boundary server. This way the link is properly done, quite simple and very easy to monitor and troubleshoot.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
I have utilized a vpn server/client set up recently as well however see you have done it differently which makes sense. My server is hosted and becomes the wan gateway at my QTH and I have several client devices at various repeater sites connected to the LAN port of the node at my switch. I can easily move the server inside the mesh at my QTH. For clarification of the clients are you setting yours up as WAN gateways at each site vs a LAN port to the node? I am guessing yes but want to be certain.Thank youSent from my iPadOn May 21, 2023, at 6:50 PM, VA2XJM Jean-Michel ***@***.***> wrote:
For Ubiquiti device, you will be on your own or someone else will be needed as I have not much knowledge of those devices.
Due to some factor (Pi prices and availability, ease of use...) we switched toward Mikrotitk hardware to host this kind of systems.
The way I do it, is a Pi or Mikrotik hAP device inside the mesh (10...*) at the location where Internet is available. Until recently, I was using a Raspberry Pi that hosted OpenVPN server (search Pi VPN) and added clients for each system needing Internet access. You may need to put some filtering rules to prohibit use of encryption (ex: HTTPS).
Then at each system, I setuped the VPN client and made it default gateway for non-10 address. So mesh traffic goes directly to mesh and Internet traffic will go through VPN-over-mesh.
One interesting thing we were doing was to redirect Yaesu Wires-X ports through the VPN for a FTM-100 node feeding repeaters.
For AllStarLink, what we do is to run a "hub" VM on the mesh boundary. The hub will connect to outside world and mesh systems runing a 1000-1999 node number will connect to boundary server. This way the link is properly done, quite simple and very easy to monitor and troubleshoot.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
You may need to enable IPv4 forward and apply If you are on AREDN Community Slack you can drop me a private message there or an email (call @ gmail.com). I'll give you more help toward that without flooding everyone in here. |
|
ThanksSent from my iPadOn May 26, 2023, at 1:10 AM, VA2XJM Jean-Michel ***@***.***> wrote:
You may need to enable IPv4 forward and apply masquerade rules to your firewall (iptables) on the VPN server.
If you are on AREDN Community Slack you can drop me a private message there or an email (call @ gmail.com). I'll give you more help toward that without flooding everyone in here.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a challenge I have run into for some time and, depending on the connections, have found a couple ways to manage it. Looking at the Advanced Config section under the WAN section I am wondering if the prevent others on my LAN connections from accessing my WAN will help out.
One of my sites has a WAN link from my QTH providing the bridge for a number of DMR D-Star and Allstar linked repeaters. If I get another WAN gateway that is too close, I start seeing drops and packet loss. With the recent advancements, is there a better way to manage this so repeaters at my site will only use the link to my QTH? I am hosting a few tunnels from my QTH as well. Is it possible that this is contributing?
Thank you,
Keith - AI6BX
The text was updated successfully, but these errors were encountered: