I have multiple locations, but for the purpose of this question, let's just call them A and B.
A and B get a public IP from their upstream provider and we use dyndns.org for dynamic DNS.
A's LAN side is at 192.168.0.0/24
B's LAN side is at 192.168.2.0/24
A and B have a nice reliable Wireguard and EoIP/IPsec connection between them. IP traffic flows beautifully between the devices on both LANs.
A is at A.dyndns.org
B is at B.dyndns.org
At A, I have a Blue Iris server at 192.168.0.1 port 81. I don't want to open port 81 to the public, so the firewall does not allow traffic through.
From a device at B (for example, 192.168.2.100) I can browse to 192.168.0.1:81 and it works perfectly.
Here's the problem:
If I browse to A.dyndns.org:81 from the same device (192.168.2.100) it fails.
DNS resolves A.dyndns.org to A's public IP address (for example: 1.2.3.4)
Likewise, if I browse to 1.2.3.4:81 it also fails.
Is there a way to make it so that I can browse to A.dyndns.org:81
Thank you!
Re: Firewall/Routing Question
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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Just a wild assed guess though.
MKX would be better suited to answer...
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
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Just a wild assed guess though.
MKX would be better suited to answer...
Re: Firewall/Routing Question
Thank you for your help.
Can this be achieved with a firewall rule that directs all traffic for A.dyndns.org to be routed via the Wireguard interface?
Yes. Users on any device in LAN B can access the BI server at 192.168.0.1:81Your 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.
Correct.b. You want users to be able to access the server by FQDN type name? like A.dyndns:81
I do not understand how static DNS would get around the firewall not allowing traffic through.
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.
How would the IP/Cloud DNS name provide a solution?
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 ????
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.
In other words any traffic queries for that URL should go through wireguard.
Can this be achieved with a firewall rule that directs all traffic for A.dyndns.org to be routed via the Wireguard interface?
No idea.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
Re: Firewall/Routing Question
Yup its up a level from my knowledge hoping MKX will find this thread and comment!!
Re: Firewall/Routing Question
Is there a way to make it so that I can browse to A.dyndns.org:81
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:
Code: Select all
/ip/firewall/address-list
add list=siteA address=A.dyndns.org
/ip/firewall/nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=81 dst-address-list=siteA to-addresses=192.168.0.1
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).
Re: Firewall/Routing Question
nm duplicate
Last edited by anav on Thu Apr 04, 2024 11:24 pm, edited 1 time in total.
Re: Firewall/Routing Question
Ahh I think I get it....
Your dstnat dst-address-list=a.dyndns.org dst-port=81 to-address=addressofserver on Device A.
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.
Your dstnat dst-address-list=a.dyndns.org dst-port=81 to-address=addressofserver on Device A.
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.
Re: Firewall/Routing Question
i think is a clasical example of trying to access a published local server from inside your network
the "problem"
is explained here
https://help.mikrotik.com/docs/display/ ... HairpinNAT
the "problem"
is explained here
https://help.mikrotik.com/docs/display/ ... HairpinNAT
Code: Select all
But, there will be a problem, when a client on the same network as the web server requests a connection to the web server's public IP address...Re: Firewall/Routing Question
Hi Chechito not sure hairpin or what applies here, I get muddled trying to work my way through it.
Re: Firewall/Routing Question
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.
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.
Re: Firewall/Routing Question
I can't say I full understand this.Is there a way to make it so that I can browse to A.dyndns.org:81
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:
Code: Select all/ip/firewall/address-list add list=siteA address=A.dyndns.org /ip/firewall/nat add chain=dstnat action=dst-nat protocol=tcp dst-port=81 dst-address-list=siteA to-addresses=192.168.0.1
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).
Your NAT FW rule works!
But, it would be even better if there were a more generic rule that would not require the dst-port and to-address specified.
That way, I could access any servers, at any ports, on A without having to add a new rule for each.
Something like these (which do not work):
Code: Select all
/ip/firewall/nat
add chain=dstnat action=dst-nat protocol=tcp dst-address-list=siteA
Code: Select all
/ip/firewall/nat
add chain=dstnat action=dst-nat protocol=tcp dst-port=1-65000 dst-address-list=siteA to-address=192.168.0.1/24
Re: Firewall/Routing Question
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.
Code: Select all/ip/firewall/nat add chain=dstnat action=dst-nat protocol=tcp dst-port=1-65000 dst-address-list=siteA to-address=192.168.0.1/24
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.
Re: Firewall/Routing Question
Trying to understand, but it will take time.
In the meantime, I'm using these 2 rules.
Port 81 points to the internal to LAN A BI server at .101
Port 8123 points to the internal to LAN A Home Assistant server at .162
Thank you (as always)!
In the meantime, I'm using these 2 rules.
Port 81 points to the internal to LAN A BI server at .101
Port 8123 points to the internal to LAN A Home Assistant server at .162
Code: Select all
/ip firewall nat
add action=dst-nat chain=dstnat comment=a.dyndns.org:81 dst-address-list=mtdale dst-port=81 \
log=yes protocol=tcp to-addresses=192.168.0.101 to-ports=81
add action=dst-nat chain=dstnat comment=a.dyndns.org:8123 dst-address-list=mtdale dst-port=\
8123 log=yes protocol=tcp to-addresses=192.168.0.162 to-ports=8123Re: Firewall/Routing Question
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 ?????
Where am I getting mixed up???
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 ?????
Where am I getting mixed up???
Re: Firewall/Routing Question
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.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 ).
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).
Re: Firewall/Routing Question
There are many things that can be done, but I have to ask; what is the advantage of accessing it via the "external" A.dyndns.org ip address?Is there a way to make it so that I can browse to A.dyndns.org:81
To me, this just seems like added complexity with no real benefit.
Re: Firewall/Routing Question
Because if you have lots of users, its easier to give them and have them remember a name than a number.
blowbluckeye.orgasm:69 for example, unforgettable.
blowbluckeye.orgasm:69 for example, unforgettable.
Re: Firewall/Routing Question
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.Because if you have lots of users, its easier to give them and have them remember a name than a number.
How to set hostname for a specific static IP (MikroTik way)
Map DNS entry to specific port (some information about dealing with non-standard ports)
Re: Firewall/Routing Question
That's an easy one:There are many things that can be done, but I have to ask; what is the advantage of accessing it via the "external" A.dyndns.org ip address?Is there a way to make it so that I can browse to A.dyndns.org:81
To me, this just seems like added complexity with no real benefit.
"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.
The FQDN reduces the complexity.
Re: Firewall/Routing Question
Setting a static hostname for each server's full IP/port means remembering the hostname, for example: blueiris.a.dyndns.org:81I 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.Because if you have lots of users, its easier to give them and have them remember a name than a number.
How to set hostname for a specific static IP (MikroTik way)
Map DNS entry to specific port (some information about dealing with non-standard ports)
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.
Who is online
Users browsing this forum: Ahrefs [Bot], Bing [Bot], cjayho, jaffir123, seocompmelb, TuxPowered and 48 guests