I have been trying to connect to wireguard all morning through my public (dynamic) IP! After scouring the forum for similar problems, I tried different fixes, with no results.
When I changed my client’s endpoint address to the local IP of my router, I got in! Tried again with the public IP (and the DDNS for that matter) but nothing. I even tried the server on different ports (with the accompanying firewall rules) and nothing.
Is the MT router the client or the server for initial connections ( are users connecting to it, or is it connection to something else?)
im assuming server with only one client.
Change this rule to NONE its known to cause funny issues in the past.
/interface detect-internet
set detect-interface-list=all
Does this router face the internet as you have changed from the default rules why, its nowhere near ready for public exposure.
The rules are problematic from both security and WG perspective.
Well I am planning to work on them, I just got my hands dirty with the VPN side for now so I can work remotely on it. Are the FW problems related to WG?
Notes1: Who can configure the router… so Authorized is a firewall address list comprised of.
add IPaddress=admin IP on Router list=Authorized ( could be desktop )
add IP address=admin IP on Router list=Authorized ( could be laptop or ipad )
add IP address=admin IP on wireguard list=Authorized ( could you coming into the router via wg )
Notes2. Suggest using interface list as so…
Uh Oh, dont see interface list or interface list members on your config…
/interface list
add name=WAN
add name=LAN
/interface list members
add interface=bridge list=LAN
add interface=wireguard1 list=LAN
add interface=xxxxx list=WAN
In this regard the incoming wireguard users will have access to WAN through the existing LAN to WAN rule and thus you can remove the extra rule for wireguard to WAN access in the forward chain.
++++++++++++++
I dont get your route to 192.168.1 Do you have a public or private WANIP ???
Your destination nat rules are inconsistent… The format is screwy
Do you have a fixed public static wanip ???
Thanks for the input! I have incorporated most changes apart from the Authorized list for now, will do that later, when I decide on IPs for administration. Might go with MGMT vlan.
So yeah, the route to 192.168.1.0/24 is because I am sitting behind my ISP’s modem router which does not support bridge mode. Hence I only use it as a means to get to the internet really. It’s the one that does the PPoE and routes all the traffic back to MT. Its firewall is disabled and MT is in DMZ. I do not have a static WANIP unfortunately
Okay that was good information to pass on… a network diagram always helps provide context when looking for help.
Now that we know your routers path through the internet is through another device we have to look carefully at the standard two cases for return traffic which illustrate the change we will have to make.
a. reach a lan devce
b. reach the internet,
These can be thought of in two ways,
(1) remote user from a single device with wireguard address within the scope of the IP address of the wireguard address on the router and secondly
(2) It could be a subnet of users coming from another client router.
Case A.
Any single remote user will already be covered for a return traffic path because the Router automatically creates a route for wireguard specific traffic and remember this traffic stays within the MT router. dst-address=192.168.50.0/24 gwy=wireguard1 table=main
A subnet of users from another router are NOT known to the router, and thus one has to manually create a route for their return traffic to get back into the tunnel. This also conveniently covers the opposite requirement - what if local users want to visit that remote subnet on the client router… in both cases we need a route. Again all traffic remains within the MT router.
add dst-address=remotesubnet gtwy=wireguard1 table=main
Case B.
When reaching the MT Router, after exiting the wireguard tunnel, we have to ensure through firewall rules that the wireguard traffic can reach the WAN.
Hence we add the rule add chain=forward action=accept in-interface=wireguard1 out-interface-list=WAN
(1+2) So the single client user with source address of 192.168.50.X will leave the router as source via the MT WAN connection and will go out the internet of the ISP modem router.
When the traffic returns the ISP router will see 192.168.50.X as source and since its not local to itself it will drop it like a hot potatoe. The same true holds for any remote subnet user.
The remedy is to ensure that wireguard traffic is also sourcenatted out the Router…
add chain=srcnat action=masquerade in-interface=wireguard1 out-interface-list=WAN
Thus any 192.168.50.x traffic or remote subnet traffic will appear as 192.168.1.1 when it returns from the WWW and the ISP router will send the traffic to the MT Router which will unsourcenat the traffic back to source and with available routes, firewall rules and allowed IPs send it back into the tunnel etc…
