I have a simple site-to-site implementation with WireGuard, with one subnet in each site, say 192.168.10.0/24 in site 1 and 192.168.20.0/24 in site 2.
Both routers have a peer IP in a third subnet, say 192.168.30.0/24 — 192.168.30.1 for site 1 and 192.168.30.2 for site 2.
Requests originating from site 1 to site 2 use hosts addresses in site 1 subnet, namely 192.168.10.0/24.
Requests originating from site 2 to site 1 are behind WireGuard peer’s IP, namely 192.168.30.2/24, appearing to be NATed.
Both implementations are identical, strictly following MikroTik’s documentation. Both routers are the same hAP ac^3, both running 7.1.2.
There is no NAT for WireGuard interfaces on either sites.
The behaviour is unexpected. Any thoughts? I can provide you with an export, but it will not show any deviations of what I have already described above.
Thank you in advance!
A network diagram would be helpful as it not quite clear what you mean but I will attempt.
A. Two MT routers with public IPs ( ISP provides modem )
B. Site 1 will initiate the tunnel and then it will stay up and allow traffic in both directions
C. Site 1 subnet users need access to Site 2 subnet
D. Here is the UNKNOWN
what the heck do you mean by peer IPs on site 2 needing access to Site 1.
Do you mean roadwarriors will tunnel into Site 2 and then need to have access to a subnet on site 1 ???
(why even mention that site1 has a peer when it does not come up as a requirement)
You do not detail what is unexpected behaviour??
Yes your explanation does not hold a candle compared to seeing the configs on both please.
/export file=anynameyouwish
Here is a diagram that explains the situation. Both routers have a private IP associated with their WireGuard interface, as recommended.
Following this diagram:
Host A reaches Host B as 192.168.10.2
Host B reaches Host A as 192.168.30.2 (unexpected behaviour; expected behaviour is Host B reaching Host A as 192.168.20.2)
The tunnel may be initiated by hosts in both Site 1 and Site 2.
Hosts in both sites need access to each other.
There are no road warriors in this scenario.
Attached are the exports with redacted public IP addresses. Site2.txt (2.95 KB) Site1.txt (3.05 KB)
set keep alive (30secs) as you state you want either end to be able to initiate the tunnel.
allowed IPs works for both directions
a. as destination IPs heading to the other site (if site 1 sends traffic),
b. as filter for incoming IPs through the tunnel (if site 2 sends traffic).
use of IP address for wireguard interface is different.
I note it doesnt encompass the existing incoming subnet of 192.168.20.0/24
I was expecting an IP address of 192.168.20.254/24 network 192.168.20.0 but I dont normally use IP address so it may be fine…
Lets say the issue is you have both the subnet coming in on 192.168.20.0/24 which IS THE CASE
AND say that you also have road warriors coming in 192.168.40.5/32 and another one you gave 192.168.40.20/32
Then I would have two IP addresses for the wg interface
192.168.20.254/24 network=192.168.20.0 interface=s2s
192.168.40.254/24 network=192.168.40.0 interface=s2s
I would delete your static DNS setting, I dont see the purpose it serves in your setup.
/ip dns static
add address=192.168.10.1
rules are okay but placement of the wireguard rules needs to be moved to below the default rules so it looks like… ADDED MISSING RULES IN BLUE and modified/simplified ruleset.
/ip firewall
…
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid log=yes log-prefix=“Invalid forward”
add action=accept chain=forward dst-address=192.168.20.0/24 out-interface=s2s src-address=192.168.10.0/24
add action=accept chain=forward dst-address=192.168.10.0/24 in-interface=s2s src-address=192.168.20.0/24
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward connection-nat-state**=dstnat**
add action=drop chain=forward comment=‘drop all else’
with the IP address as I have stated above, you would not need the following IP route
add dst-address=192.168.20.0/24 gateway=s2s table=main
If you were not to use IP address at all for wg interfaces, then you would need this IP route rule.
Site 2
WG inteface
-Recommend using a DIFFERENT listening port, too confusing to me to have the same listening port.
lets say 6666 .
Recommend using a different name for the wirguard interface also too confusing for me at least call it 2s2
Peer
same , keep alive needs to be set.
same comment on allowed IPs, works for both direction and if you have incoming road warriors you need to add their IPs as well.
/interface wireguard peers
add allowed-address=192.168.10.0/24 endpoint-address=78.78.78.78 endpoint-port=6666 interface=2s2 public-key=“yyyyyyyyyyyyyyyyyyyyyyyyyyyy=”
same comment on wireguard interface, One either uses IP addresses that encompass all incoming traffic or dont use IP addresses so in your case it would be.
192.168.10.254 network=192.168.10.0/24 interface=2s2
192.168.40.254 network=192.168.40.0/24 interface=2s2 {supposing the road warriors could connect to either router }
If I get rid of peer IP for WireGuard interfaces on both routers, Host B in Site 2 reaches Host A in Site 1 as the gateway of Site 2 (192.168.20.1:38452), NATed, not being behind the peer IP any longer (it is disabled, obviously). Moving the firewall rules does not change anything in this behaviour.
Changing WireGuard instances’ names and listening ports does not help either. In another setup with different routers (MikroTik again), I used different listening ports, and both routers failed in establishing the tunnel. This is why I stick to using the same ports on both routers.
Site 1 USE 192.168.20.254 /24 network=192.168.20.0
Site 2 USE 192.168.10.254/24 network=192.168.10.0
FORGET ABOUT an IP address that has no coverage for incoming subnets. ( 192.168.30.X stuff is garbage )
OR
FORGET ABOUT Ip addresses for the WG interfaces themselves and create necessary routes manually.
If the listening port change doesn’t work for you then something is wrong with the config NOT the listening port.
Initiating a tunnel from one side or the other should work as long as
listening port at one end matches endpoint port at the other end, and thus if it doesn’t work its because you have missed that step.
keeping the listening ports separate makes it clear what side is initiating the tunnel and easier for us to read/understand.
however if it works for you stick with it.
The whole Detect Internet is weird. At first sight, it seems that it should be useful. But then you think about what can you actually do with it, and … Anyone feel free to help me, because I didn’t find anything that didn’t have major flaws.
I have zero idea how it might be useful … apparently MikroTik believes it is used to automate WAN connectivity for systems like CPE but that is only my uneducated guess.
It can tell you what interfaces can reach internet:
Internet
WAN interfaces that can reach cloud.mikrotik.com using UDP protocol port 30000 can obtain this state.
That’s what many people want to know, when they do things like Advanced Routing Failover without Scripting. But Internet Detect can’t replace it, because it may give you correctly classified interface, but you can’t do anything with that.
Another thing that comes to mind is firewall rules based on interface state. It makes sense to have different rules for LAN and WAN. Problem is, Internet Detect is pretty much useless for that too, because all interfaces are initially LAN, and that’s where you’ll usually have permissive rules. So if you’d have detection on interface connected to ISP, normally it would be WAN or Internet. But attacker in ISP’s network could simply block DHCP, disconnect and reconnect cable, and the interface would become LAN. Not great. And if you enable it on internal interface, it could save you, if it somehow becomes connected to internet, but there’s no realistic way how it could ever happen, so it’s not useful there either.
I’m out of ideas, I don’t see any other use for it. So far I’ve seen it only break configs of people who accidentally enabled it.
