Your explanation is not complete or maybe just lacks some clarity.
Are you saying that
a. Users at Device B, via wireguard, successfully access the Iris Server on the LAN at Device A?
Note: Assuming the users simply put in their APP or browser 192.168.0.1:81 and the connection works great.
b. You want users to be able to access the server by FQDN type name? like A.dyndns:81
This will not work if you are expecting the users to go out the local WAN at Device B, and then reach the Device A on its WAN port due to the fact that you have already stated
that you block incoming traffic on the WAN side.
One may consider something funky with static DNS, but that may interfere with the fact that the router needs to go out local WAN to reach the a.dydnsn.org for Wireguard handshake.
Perhaps consider using the IPcloud DNS name for wireguard, and then something like static DNS for the other pointing to the wireguard IP on the device ???
In other words any traffic queries for that URL should go through wireguard. Then one has to deal with that traffic at arrival at Device A… Hairpin NAT???
/ip dns static add regexp=[“a.dyndns.org]” address=wireguardIP/32
Yes. Users on any device in LAN B can access the BI server at 192.168.0.1:81
b. You want users to be able to access the server by FQDN type name? like > A.dyndns> :> 81
Correct.
This will not work if you are expecting the users to go out the local WAN at Device B, and then reach the Device A on its WAN port due to the fact that you have already stated
that you block incoming traffic on the WAN side.
One may consider something funky with static DNS, but that may interfere with the fact that the router needs to go out local WAN to reach the a.dydnsn.org for Wireguard handshake.
I do not understand how static DNS would get around the firewall not allowing traffic through.
Perhaps consider using the IPcloud DNS name for wireguard, and then something like static DNS for the other pointing to the wireguard IP on the device ???
How would the IP/Cloud DNS name provide a solution?
In other words any traffic queries for that URL should go through wireguard.
Yes. It would seems to be that if I could direct any traffic destined for A.dyndns.org to go through Wireguard, then that would work.
Can this be achieved with a firewall rule that directs all traffic for A.dyndns.org to be routed via the Wireguard interface?
Then one has to deal with that traffic at arrival at Device A… Hairpin NAT???
/ip dns static add regexp=[“a.dyndns.org]” address=wireguardIP/32
It may be possible to construct a DST-NAT combination on router of site B which would work most of time … except in time periods after change of A public IP address (because A.dyndns.org has to be updated and TTL of the old record expires everywhere). Something like this:
The address list bypass is required for ROS to resolve A.dyndns.org to IP address (and it’ll do so every time TTL of DNS record expires). So if IP address of site A changes right after router refreshes the address list, inter-site tunnel will obviously drop. After a short while routers will create another tunnel (router B will get the new site A IP address because it’ll ask upstream DNS server and it might get the correct answer quite soon), but address list will stick to the old value until that value expires. I don’t think this will be a huge problem, site A IP address hopefully doesn’t change often and even when it does, tunnel won’t be rebuilt immediately (not if there’s cached resolution of A.dyndns.org waiting to expire). And then there are also clients (on site B) which may cache the obsolete IP address of A.dyndns.org …
And, in case anybody asks: dst-nat is done pretty early in packet processing stages, before firewall and routing decissions. So if the dst-nat rule above applies, it automatically means that packet will be routed through inter-site tunnel. Except when the construct above doesn’t align, in that case packets won’t get dst-nated and will leave dite B towards internet (where they’re bound to be lost or dropped or abused).
Then the router sees the to-address on a known remote subnet with the following existing route add dst-address=subnetofRouterA gateway=wireguard routing-table=main.
Nice!!
Just want to make sure that has no bearing on the Router service reaching out to the same URL for wireguard handshake, in other words not affected by dstnat rule.
No, hairpin NAT is not the problem here, communication between client on site B and server on Site A has to pass router (actually both of them) in both directions (if it doesn’t, then one needs hairpin NAT).
The problem here is selection of the route from site B to site A (and back) when client uses public IP address of site A.
You can make the NAT rule as general as you want. But it may soon break something else. For example establishment of wireguard tunnel (tunnel might drop momentarily while siteA address doesn’t change and then wireguard connection may get NAT-ed to 192.168.0.1 which is not accessible until after wireguard tunnel successfully starts).
This rule is too wide … the two “to-*” properties (to-port and to-address) must map into very specific combination to make any sense. The problematic part is setting to-address to anything more than single IP address. Because: when you set up more than one possible address (you’ve given 256 choices, albeit using incorrect syntax, 192.168.0.1/24 is not valid network address), then NAT machinery will randomly choose one of possible choices. Which may be handy in a load-sharing situation, but not really otherwise. The to-port property is less problematic … if it’s not set, then dst-port will be left unaltered. But if you do set it to a range, then the same random dst-port selection may kick in.
BTW, mind that there are two action properties of NAT rules, for DST NAT these are “to-port” and “to-address” … when NAT rule executes, it rewrites dst-port with to-port and dst-address with dst-port (similarly SRC NAT uses to-port and to-address to overwrite src-port and src-address). The rest of properties (e.g. protocol, src-address, dst-address, dst-address-list, etc.) are “matching criteria” and define which packets will trigger NAT rule. In your case dst-port is matching criteria and any packet, targeting port in range 1-65000 and address of siteA will trigger the rule. NAT will then rewrite dst-address with a randomly chosen IP address from the range and leave dst-port intact. But then one ask why bothering with dst-ports at all, your rule will only leave out port 65001-65535.
In short: you can try to slightly “overload” a single NAT rule (e.g. set dst-port=80,443), but not much.
So mkx,
The user on teh browswer sends hit request.
The router B DST-NAT rule intercepts the request and changes the destination IP from a.dyndns.com resloved IP, TO the local server on device A.
Transparent to the user.
The router know that the traffic for that subnet needs to go out wireguard interface and its on its merry way.
Thus we have effectively duplicated the direct LANIP address in the browser which also works.
At Router A, what does the router see…
It should see source being user from RouterB with destination IP of server on Router A LAn, ( if traffic is sourcenatted, the source IP would be the wireguard IP of B ).
In any case return traffic is handled either by existing wg route OR a route on Device A, for the remote subnet on Device B, the user came from.
What happens when the return traffic hits Router B…its coming from Router A server address…
a. gets unsourcenatted from wireugard IP to user B IP.
b. OR simply has user B IP as destination.
Does any UN DST_NATTING take place ?? Because, the user at B, is expecting reply traffic from a.dyndns.com, but its coming instead from server LANIP ???
The rule I suggested for site B is a dst-nat … so src-address is not changed. Thus router A sees a packet from 192.168.2.X and dst-address 192.168.0.1. And passes it unaltered to server. Server replies, router A knows that 192.168.2.0/24 is accessible through wireguard tunnel. Router B receives the packet, notices it’s a return packet for natted connection, undoes the DST-NAT and delivers packet to client.
The trick here is that all firewall devices, and router B is included, process each and every packet received. As per packet flow, part of prerouting “magic” is connection tracking and this is where router notices it’s processing packet which is part of natted connection … hence two boxes to the right (still part of prerouting) dst-nat undoes the natting.
If user of the same machine instead used 192.168.0.1:81, this connection wouldn’t be dst-natted in forward direction (site B → site A) and return packet wouldn’t have to be un-natted. And yet to server A both connections would seem almost identical (apart from src-port).
I do understand that it is easier to remember BlueIris:81 than 192.168.0.1:81; but he doesn’t want this accessible from the internet, so I don’t see any advantage to using the public ip. So why not solve this with an entry on a local dns server, or even on the Mikrotik itself? The users are still going to need to remember the port, or he will need to use another solution to hide that.
“a.dyndns.org” is easier to remember than “192.168.0.101” for the Blue Iris server AND 192.168.0.162 for the Home Assistant server and 192.168.0.28 for the Proxmox machine, etc., etc.
Setting a static hostname for each server’s full IP/port means remembering the hostname, for example: blueiris.a.dyndns.org:81
Correct?
Even if I could map blueiris.a.dyndns.org to 192.168.0.101:81 (that is, map the fqdn to the IP and port without specifying the port along with the fqdn), it would still be too much to remember.