Wireguard is fairly easy and works well.
MT device act as a server and gets a wireguard address
address=10.10.10.2/24 interface=workwireguard
All clients get wireguard IP addresses within that subnet
remoteworker1 address=10.10.10.3/32
remoteworker2 address=10.10.10.4/32
etc.....
The only exception is if its a MT router or device and then it gets
mt client device address=10.10.10.5/24
The settings for the wireguard on the client assuming like a pc or desktop version of wireguard.
- need the endpoint IP address of the Office WANIP
- need the port being connected too for the initial handshake,
- need the public key spit out by the MT Wireguard server settings
- need to set a keep alive setting such as anything between 20-50 seconds seems to be fine.
- need to set allowed addresses/IPs, which means what addresses will the client be seeking to reach on the MT server,
typically we put
a. the wireguard IP subnet and
b. any LAN subnets
and thus in this case
= 10.10.10.0/24, Internal LAN (where lets say that internal lan on the MT server router is 192.168.50.0/24)
+++++++++++++++++++++++++++++++++++++++++++++
The MT router side is a bit more work,
need to allow the input chain to accept incoming traffic to the port
One needs to input for each wireguard peer for the single INTERFACE, the following,
- the public key from that client
- the allowed IPs/Addresses which in this case will be.
a. the assigned wireguard IP for each device, all should be /32 (including any mt client routers)
b. the incoming assigned LAN IP on source device ( like a laptop - single user behind another router )
c. the incoming assigned subnet on source device ( like from a router client - where a bunch of users are connecting )
Basically the idea here is that the traffic will be allowed to exit the tunnel at the server side IF the source IP of the traffic matches the list you create. We ensure the wireguard IPs are included to facilitate pinging and continuity checking, and for single users on something like an IPHONE, which has no pre-ordained source IP (such apps basically, in effect, source-nat the devices assigned sourceIP (like from public WIFI) to the wireguard IP for tunnel traffic). For devices with a known source IP, laptop on a subnet behind another router, we should identify that IP or its subnet and for clients that are routers perhaps with a bunch of users, the entire subnet.
This is typically the most difficult step in the process, which is easily done if you plan well and know the requirements.
Note: If the clients were going to go out the MT Servers internet connection, then the allowed IP setting would be 0.0.0.0/0 which includes the above entries and thus they, in this scenario, would not be required (redundant).
One other consideration on the MT Server Router are firewall rules.
a. to allow admin remote access to configure the router would require an input chain rule.
b. to allow remote users to access LAN device, a forward chain rule or rules to do so.............. as
discriminating as you need.
add chain=forward action=accept
in-interface=workwireguard dst-address=localLANsubnet src-address=clientSourceIP or
src-address-list=authorized
You may break it down further........ by stating a specific only device,
dst-address=deviceIP
Finally, the last consideration is Routing..........
In this case the construction of the wireguard network is such that necessary route is created automatically by the router and covers any return traffic that needs to come back into the tunnel to the client
<DAC> dst-address=10.10.10.0/24 gwy=workwireguard table=main
+++++++++++++++++++++++++++++++++++++++++++++++++++
Where this gets tricky is if you want LAN subnets on the WIreguard Server to reach to some of the clients, this is not necessarily typical for remote warriors, but as per the example above, its very possible to have an MT CLIENT router in the mix and it may have LAN subnets that users on the MT Server router may need to reach. A discussion for another day,
but right away one gets the sense that
Allowed IPs on the MT server will need to identify that,
Firewall rules will have to allow local MT Server subnet folks to head toward the tunnel gateway unsolicited, and
One will have to add a route pointing such users to the tunnel vice somewhere else.
viewtopic.php?t=182340