I have 2 sites running Ubiquiti UDM routers and they really (really really) stink at Wireguard.
I’m wondering if anyone has any insight into the pros and cons, or tips and tricks of, using a hEX behind the UDM (as a device on the LAN) just got its Wireguard facility?
Thanks!
Almost the same setup here. An Edgerouter (with public IP) and a RB2011 for wireguard behind it on inside LAN. This is for testing and not in production.
Port forwarding from Edgerouter to the RB2011. This for remote support (mobile devices). LAN can be reached on both IPv4 and IPv6 without any problems.
TL;DR: Should work without any problems (with a port forwarder on the Edgerouter)
Concur… load up 7.7 on hex.
RU - port forward wg port lets say 15555 to LANIP of Hex on RU LAN ( hex’s WANIP ).
RU1 - main/trusted subnet 192.168.2.0/24 RU2 main/trusted subnet 192.168.5.0/24
HEX - LANIP on RU1 LAN, and HEX WANIP = 192.168.2.21
On hex all default settings are fine as a starting point…
Rules will be constructed with the following assumptions.
A. Admin when at location RU1 or location RU2 may want to config
(i) hex device
(ii) either RU device.
B. Admin, when on the road and connecting remotely may want to config
(i) hex device
(ii) either RU device.
Since we cannot monkey with the RU devices, suffice to say you will have to configure their firewalls to accept on their equivalent input chains access to the opposite RU admin address and any remote WG addresses etc, along wiith own RU access of course. We can use the hex as an example.
/ip firewall address (using static set dhcp leases for RU addresses and of course fixed wireguard road warrior devices for remote connections)
add ip-address=admin-desktop RU1_IP list=AdminAccess 192.168.2.XX
add ip-address=admin-desktop RU2_IP list=AdminAccess 192.168.5.YY
add ip-address=admin-laptop RU1_IP list=AdminAccess 192.168.2.AB
add ip-address=admin-laptop RU2_IP list=AdminAccess 192.168.5.CD
add ip-address=admin-iphone/ipad RU1_IP list=AdminAccess 192.168.2.GH
add ip-address=admin-iphone/ipad RU2_IP list=AdminAccess 192.168.5.LM
add ip address=admin-remote-laptop list=AdminAccess 10.10.10.25
add ip address= admin-remote-Iphone/IPAD list=AdminAccess 10.10.10.55
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
add ip-address=admin–on hex bridge list=AdminAccess 192.168.88.0/24 { when configuring hex from hex itself aka bridge )
add ip-address=admin-on hex ether5 list=AdminAccess 192.168.55.0/24 ( for configuring accessing the HEX off bridge - emergency access )
Assumes ether1 is WAN port connected to RU1
Assumes - ether 2,3,4 are put on bridge
Assumes - ether5 is OFF bridge and give it a name of ether5-emerg
So from the firewall address list created you can access the hex router from R1 locally, from R2 through the wg tunnel and from remote warriors through the tunnel, as well as from while on the hex bridge itself, or using port 5 on the hex and off the bridge (safest way to config - just put any 192.168.55.X address in ipv4 settings in a laptop)
Additionally one can config R1U through the tunnel aka from R2U and vice versa and to both RU devices, from wg road warriors through the tunnel. Just need to use the addresses provided/simulated converted to actual ones, by manipulating the firewall rules of R1 and R2 ( similar to input chain rules on MT )
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
/interface list
add name=WAN
add name=LAN
/interface list members
add interface=ether1 list=WAN
add interface=bridge list=LAN
add interface=WGServer list=LAN
add interface=ether5-emerg list=LAN
/ip firewall filter
{Input Chain}
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=input comment=“defconf: accept ICMP” protocol=icmp
add action=accept chain=input dst-port=15555 protocol=udp comment=“handshake”
add action=accept chain=input in-interface-list=LAN src-address-list=AdminAccess
add action=accept chain=input in-interface-list=LAN dst-ports=53,123 protocol=udp comment=“access to dns and ntp services”
add action=accept chain=input in-interface-list=LAN dst-ports=53 protocol=tcp comment=“access to dns services”
add action=drop chain=input comment=“drop all else” { put this in last }
{forward chain}
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN { allows wg traffic to exit WAN for RU1 subnets or internet }
add action=accept chain=forward out-interface=WGServer dst-address=192.168.5.0/24 src-address=192.168.2.0/24 { to support local RU1 users to access remote RU2 subnet }
add action=accept chain=forward in-interface=WGserver out-interface=WGServer { to support road warrior coming in directly and relay back thru tunnel to RU2 }
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat comment=“defconf: masquerade” out-interface-list=WAN
The default source nat rule will work well for us in this case. Since we have added the manual route for all traffic to go out the WAN interface, it will all be sourcenatted to the WANIP of the hex.
Thus any return traffic from RU1 subnets or internet will have source IP of 192.168.2.21 and will be recognized by the RU1 router in terms of where to route the return traffic.
Other tidbits…
/iip neighbors discover
interface-list=LAN
/Ip mac winbox mac server
interface-list=LAN
/ip route
add dst-address=0.0.0.0/0 gwy=192.168.2.1 routing-table=main { assuming of course the gateway IP of the RU1 is correct here }
/ip address
add address=192.168.2.21/24 interface=ether1 network=192.168.2.0 { also creates route for all “WAN” traffiic, to RU1 subnets and to www }
/p address
add address=10.10.10.1/24 interface=WGServer network=10.10.10.0 { also creates route for all Wireguard traffic }
Note: wireguard address for RU2 = 10.10.10.10
/ip address
add address=192.168.55.1/24 interface=ether5-emerg network=192.168.55.0
Plus default bridge setup (minus few changes) for 192.168.88.0/24 subnet.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
NOTE it is not clear in your requirements, if RU1 users need internet access at RU2, or vice versa. This will impact WG settings.
This setup assumes LAN to LAN for users, and admin to devices for config.
Allowed IPs on RU1
peerRU2 - allowed-addresses=10.10.10.10,192.168.5.0/24
peerRemote-laptop - allowed-addresses=10.10.10.25
peerRemote-lphone/ipad - allowed-addresses=10.10.10.55
Hey dutn: Welcome to the forum! And thanks for sharing your set up – I appreciate the encouragement.
Hey anav: Thank you again (and again and again).
What does RU stand for? Remote User comes to mind, but I don’t see it fitting the context. Maybe it means the UDM routers?
Let’s see how much of what you wrote I understand (I think I average about 20% (;-):
This would allow a remote user or router to establish a WG tunnel through the UDM to the hEX. One established, packets on the tunnel hitting the hEX will be routed back out the ethernet cable on ether1 to the LAN.
Correct?
Yes RU1 is unifi router1 and RU2 is unifi router2 or whatever brand they are LOL.
1) Connect the hEX’s WAN port (ether1) to the UDM’s LAN (just like and among all the other local devices)
Yes, easiest if you do it via IP DHCP CLIENT and select add default route checkbox too.
2) Set up port forwarding on UDM to forward port 15555 to the LANIP of the hEX (call it 192.168.0.50 for now, which is on the UDM’s LAN of 192.168.0.0/24)
YES.
3) At this point, the hEX’s WANIP will be 192.168.0.50 (assigned to ether1 in /ip/address/add/…)
Yes, see (1)
4) The IP ADDRESSES on the hEX should all be in the 192.168.0.0/24
NO simply use the default subnet 192.168.88.0/24 dont try to match same lan to lan on front router RU1.
5) Setup Wireguard config
This would allow a remote user or router to establish a WG tunnel through the UDM to the hEX. One established, packets on the tunnel hitting the hEX will be routed back out the ethernet cable on ether1 to the LAN.
Sort of Yes, the tunnel will route packets directly to the hex, and with destination address not local and default route for all traffic on the hex (IP DHCP client), the traffic will go from hex to R1U, either to other LAN subnets ( if destination addresses are local address on RU1, or to the internet if not )
Got it.
So a single ethernet cable from the hEX WAN port (ether1) to a switch on the lan is the only physical connection needed, right?
The single cable connecting RU1 to the HEX is all that is required.
I’ve been working on understanding the config, made a few changes to what you provided, and have a question:
If I am off-site from the UDM->WG-hEX environment, will I still be able to access the hEX itself for management with the config below?
If I establish a tunnel, then my IP will be either in the 192.168.0.0/16 or 10.10.0.0/16 range, but I will be coming in on ether1 and the following line allows only access to coming in on interface list LAN, which does not include ether1:
add action=accept chain=input in-interface-list=LAN src-address-list=admin
If, for some reasons like my fat or over-zealous fingers, I am unable to establish a tunnel, can I still gain access from outside the LAN?
Here is a larger snippet of what I’ve got (for 1 of the UDMs):
/interface list members
add interface=ether1 list=WAN
add interface=bridge list=LAN
add interface=355-WGhEX list=LAN
add interface=ether5-emerg list=LAN
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4
add bridge=bridge comment=defconf ingress-filtering=no interface=ether5
/ip firewall address-list
add address=aaaa.dyndns.org list=mtdale
add address=bbbb.dyndns.org list=212
add address=cccc.dyndns.org list=255
add address=mtdale.dyndns.org list=dynamic-WANIP
add address=192.168.0.0/16 list=admin
add address=10.10.0.0/16 list=admin
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input dst-port=51833 protocol=udp comment="handshake"
add action=accept chain=input in-interface-list=LAN src-address-list=admin
add action=accept chain=input in-interface-list=LAN dst-ports=53,123 protocol=udp comment="access to dns and ntp services"
add action=accept chain=input in-interface-list=LAN dst-ports=53 protocol=tcp comment="access to dns services"
add action=drop chain=input comment="drop all else"
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN comment="allows wg traffic to exit WAN for UDM subnets or internet"
add action=accept chain=forward out-interface=355-WGhEX dst-address=192.168.0.0/16 src-address=192.168.0.0/16 comment="supports local LAN users to access remote LAN subnets"
add action=accept chain=forward out-interface=355-WGhEX dst-address=10.10.0.0/16 src-address=10.10.0.0/16 comment="supports inter-WG traffic"
add action=accept chain=forward in-interface=355-WGhEX out-interface=355-WGhEX comment="Supports road warrior coming in directly and relay back thru tunnel to other WG"
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN
/ip neighbors discover
interface-list=all
/ip mac winbox mac server
interface-list=LAN
/ip route
add dst-address=0.0.0.0/0 gwy=192.168.0.1 routing-table=main comment="assuming of course the gateway IP of the UDM is correct here"
/ip address
add address=192.168.0.50/24 interface=ether1 network=192.168.0.0 comment="also creates route for all "WAN" traffiic, to UDM subnets and to www"
/ip address
add address=10.10.300.1/16 interface=355-WGhEX network=10.10.0.0 comment="also creates route for all Wireguard traffic"
/ip address
add address=192.168.88.1/24 interface=ether5-emerg network=192.168.88.0
YOu wlil have to be much more detailed in the access scenarios for me to understand what are saying.
Accessing the hex from a road warrior perspective is dirt simple. You handshank with the RU1, tunnel is connected and then its your road warrior IP that is involved with traffic, either to RU1 LAN or RU2 Lan or internet. So if your road warrior access is included in the source address list (as per my example) then yes.
If you are coming from RU2, yes you will be traversing the tunnel with your RU2 local subnet LAN IP.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Looking at the config you are really lazy or dont care who has access to router for config purposes… bad security practice IMHO but its up to you.
I also dont understand why you are making such a huge wireguard network… How many wireguard connections are you thinking of…??
To directly answer the question, it would appear that everyone will be able to access the HEX LOL
Without seeing the actual subnets on RU1 or RU2, hard to say.
I also dont understand the firewall rules… because there is no context of the network, no diagram etc…
but on the first rule you basically allow everyone to access everyone…
the second one iittle makes little sense. Why would a road warrior want to connect to a road warrior’s iphone or laptop ???
the third one is fine… it actually addresses a use case where the road warrior needs to get to R2 after landing at R1…
add action=accept chain=forward out-interface=355-WGhEX dst-address=192.168.0.0/16 src-address=192.168.0.0/16 comment=“supports local LAN users to access remote LAN subnets”
add action=accept chain=forward out-interface=355-WGhEX dst-address=10.10.0.0/16 src-address=10.10.0.0/16 comment=“supports inter-WG traffic”
add action=accept chain=forward in-interface=355-WGhEX out-interface=355-WGhEX comment=“Supports road warrior coming in directly and relay back thru tunnel to other WG”
Its not to make rules, but you need to have realistic use cases. The second rule tells me you actually didnt think of why you were making the rule, just thought it was hey I can connect all road warriors to reach other…but is that the use case should be the question. Probably NOT, rw to LAN (for users, more likely) rw to Config router ( Only for admin). rw to rw probably not/.
Also you need to be more specific because later on when you look at wireguard settiings, I would imagine you are going to run into duplicate peers which means you are going to start needing multiple wireguard interfaces to deal with overlap.
So advice is to not try and get cute with huge networks and all encompassing rules.
Its good to have the overall context and design done a PLAN, a diagram and the USER requirements BEFORE making the config.
THis is cart before the horse work you are doing…
Not trying to be cute or lazy. Just trying to make sure it works.
Do I understand that by “everyone” you mean that everyone who has a 192.168.x.x or 10.10.x.x IP will have access to the hEX?
I will work on limiting that. I believe that limiting the IPs included in the “admin” src-address-list is the way to do that.
I don’t know which firewall rule allows a road warrior to access another road warrior’s device. Are you referring to the rule that forwards in-interface=355-WGhex to out-interface=355-WGhex?
If so, my thinking is not to allow road warriors to access each other’s devices, but rather to allow devis at the different sites to go through this hEX and back out the hEX to other devices that this hEX will have a wireguard tunnel to.
The plan is pretty straightforward:
I now have 5 locations, soon to be 7, that I need total remote access and management of from any of those locations as well as while being a road warrior. I am the only person who needs management access, but some devices at some locations needs access to devices at other locations. For example, a Blue Iris video server needs access to cameras at other locations.
2 of these locations have UDMs, which have horrible Wireguard implementations. So, my idea is to use a hEX behind each of the UDMs to act as a WG server.
Does that put the horse first, or is it still neck and neck with the cart (;-)?
Thank you!
Its the start of an excellent plan!
Diagram it,
Write down all the use cases including your own…
then you will have capture all the context and content and then a coherent config can be put together.
If you need to do this prove it to yourself it works, in general, thats up to you, but your better energy is spent on the actions above…
This is me failing at diagramming.
I have it all detailed in Excel, but unable to diagram.
I see (or not) LOL.
Step1: Provide a network diagram of your setup with enough detail so that the subnets (vlans), devices and their relationships are clearly established. If able, on the same, or perhaps separate diagram indicate the purpose of each port on your device. Some other apps that may prove more friendly, or it make two more than one diagram…
NETWORK DIAGRAM APPS:
https://nulab.com/cacoo/
https://online.visual-paradigm.com/diagrams/solutions/free-network-diagram-software/
https://www.lucidchart.com/pages/
https://drawio-app.com/product/
https://www.diagrams.net/ (its older sibling soon to be discontinued https://drawio-app.com/product/)
( Other links for diagrams.net - https://www.youtube.com/watch?v=P3ieXjI7ZSk & https://www.youtube.com/watch?v=mpF1i9sfEJ0 )
https://sourceforge.net/projects/dia-installer/
https://www.yworks.com/products/yed (and icons for yed → https://github.com/danger89/yEd_cisco_network_icons )
https://www.libreoffice.org/discover/draw/
http://kilievich.com/fpinger/ - has a simple drawing program but not its main intent.
Paper and pen … sometimes more then enough.
Assuming he has a scanner LOL. I suppose a smart phone and a way to transfer LOL.
This is what I have so far.
Could you please tell me what other info should be included on the diagram?
Thank you!
Complete list of user requirements and do it on a per location basis.
LIFE can get very complicated as you have the potential of many servers and clients amongst the MT routers.
So think about it, which HEX/AC/AX do you want as the relay device… all devices will connect their tunnel to the one server and then all are connected peer to peer through that device.
To me It would be best to choose the location with a fixed static public IP, that is stable with best throughput.
In your diagram you do not show the hex devices behind the UDM for wireguard ???
LOCATION A.
a. [OUTBOUND] Identify local users/devices that need access to remote subnets and to which subnet/locations outbound flow
b. [INBOUND] Identify remote users coming to location A, and from which location, that need access to local users/devices, if to single devices identify them. Drill down to IP level for this one as its best to OUTBOUND keep things on a subnet level and on the INBOUND firewall rules narrow down access to only those currently required.
c. identify if admin at local location needs to go out tunnel to other locations to be able to configure them (from their normal lan subnet IP)
d. identify if remote admin access is required to config Location A.
Repeat for each location.
I am working on more details, but I wanted address something that I think I have misunderstood until now.
When you use the term “users” I believe you mean non-admins, right? If that’s the case, there are no users for the VPNs.
The purpose of the VPN is twofold:
I hope this clarifies (and maybe even simplifies) the analysis.
In the meantime, here is a somewhat more fleshed out diagram.
Yup matters little to me whether its people or devices communicating…
Does it matter if it’s me (admin) or users?