I have a location with a hAPax3. On ether2 is a camera that was previously configured to have a static ip address of 192.168.0.97
The environment is has several vlans in the 10.a.b.c networks, as well as a Wireguard connection with the interface at 10.10.100.80
I am hoping there is a nat rule I can implement that will make all the 192.168.0.97 frames arriving from the camera at ether2 and change it to 10.72.22.200. And, all traffic arriving via Wireguard destined for 10.72.22.200 translated to 192.168.0.97
The goal is to point a web browser at another location and be able to access the camera so I can change the ip address on it.
I tried various nat entries and could not make it work.
Is that ether2 port part of a bridge (slave port) or outside of any bridges (standalone interface)? You’ll need to add an IP address first
/ip address
# choose only one of the three following!
add address=192.168.0.98 interface=ether2 network=192.168.0.97 # only if ether2 is standalone port!
add address=192.168.0.98 interface=bridge1 network=192.168.0.97 # only if ether2 member of non-VLAN-filtered bridge bridge1
add address=192.168.0.98 interface=vlan50 network=192.168.0.97 # only if ether2 is access port of VLAN interface vlan50!
# NAT rules:
/ip firewall nat
add action=dst-nat chain=dstnat dst-address=10.72.22.200 to-addresses=192.168.0.97
add action=masquerade chain=srcnat dst-address=192.168.0.97
You should then be able to access the camera using the IP address 10.72.22.200 (if there is no filter forward drop rule that blocks it).
Your previous attempts did not work because the router didn’t know that it should forward frames destined for 192.168.0.97 to ether2. By adding the IP address (and the network address, if you want you can also use 192.168.0.98/24 as address and 192.168.0.0 as network) to the interface vlan-cameras, you also implicitly add a route entry in the /ip route table, that tells the router that for destination address 192.168.0.97/32 (or 192.168.0.0/24 if you use the alternative address config) the interface vlan-cameras should be used as gateway. Now the router knows to direct packets for 192.168.0.97 to the vlan22 interface (of which ether2 is an access port).
With the dstnat rule, we tell the router that for all packets with destination 10.72.22.200, the destination address should be changed to 192.168.0.97 instead. Which also implicates that the packet will be routed using vlan-cameras as gateway.
With the masquerade rule, we tell the router to modify the source address of all packets that is being sent to the destination 192.168.0.97, so that the source address of the packet becomes 192.168.0.98 (the address of the router on the interface vlan-cameras). Which means the camera will receive a packet with destination 192.168.0.97 and source 192.168.0.98. All addresses in its acceptable subnet range.
When the camera responds, it sends respond packets with source 192.168.0.97 to destination 192.168.0.98. 192.168.0.98 is the router. The router receives the packets, sees that it’s part of a srcnat-ed and dstnat-ed connection. The routers will then undo the address translation (undo the NAT), the source of the respond packet will be changed back to 10.72.22.200, and the destination address changed to the IP address of the original sender (for example 10.10.100.81). The response can now be forwarded to the original sender (10.10.100.81).
I have been studying it, rewriting it to help me learn it better, and really trying to let it sink in so that when I have to do something like this again, or, rather, something not exactly like this but close, I can implement these concepts and solutions.
This is such an elegant solution that required very little additional configuration and no changes/modifications to the the configuration settings in place at either site.
I probably missed the intent entirely but why not something as simple as:
If I have a device with LANIP 192.168.0.X and I want it to go out over wireguard but as 10.10.100.Y address add chain=srcnat action=src-nat src-address=192.168.0.97 to-address=10.72.22.200
AND for return traffic… add chain=dstnat action=dst-nat dst-address=10.72.22.200 to-address=192.168.0.97
@anav because in OP’s original config the subnet 192.168.0.0/24 (or any other smaller subnet enough to encompass 192.168.0.97) doesn’t exist yet on his router. The router did not know how to route to destination 192.168.0.97, other than to forward everything to the default destination 0.0.0.0/0 route (which usually goes to WAN).
You need to understand that OP’s has this old camera device that has a hard-coded IP address of 192.168.0.97 (probably with netmask 255.255.255.0 in the UI) that doesn’t use DHCP. The camera is plugged into his network that has only 10.x.x.x subnets, and because it doesn’t use DHCP it sits there with the IP address 192.168.0.97 among a bunch of 10.x.x.x devices. And OP’s is not at the router’s location but only has remote access to the router via Wireguard. He cannot take the camera and plug to his laptop to reconfigure it.
With the 3 changes above OP told the router how to reach this 192.168.0.97 device (the /ip address entry that also adds the route entry), as well as to let the device still think that it’s in a 192.168.0.x subnet talking to 192.168.0.y peers (the two NAT rules).
I assume that once OP has gained access to the camera with this method, he’ll change the camera IP address range back to the correct one of vlan-cameras, or probably change the setting of the camera to use DHCP, then he can remove the /ip address entry and the dstnat rule. For some cameras, the masquerade rule might still be needed (dst-address adjusted of course, as it’s no longer 192.168.0.97) because they only accept incoming connections from the same subnet.
How you sussed that out from the information presented boggles my mind. Glad you are here LOL
However, the weak point being, how does the router know that 10.72.22.200 should be assigned to the device ( assuming its now in a VLAN of that subnet structure )??
THe router knows that that address might exist locally because there is such a subnet, so the challenge becomes,
how to tell the router that the two are linked… when .200 hasnt been assigned to anything… and 192.168 has no bearing locally.
CGGXANNX sussed out my situation because of my extraordinary communication skills
Oh yea, and also because he is clearly quite smart.
There is only a single inaccuracy, though of absolutely no significance whatsoever: The camera is not old, and is quite a good quality camera (EmpireTech B5842E, which is identical to a Dahua). Several months ago, when I was on site, I programmed it with a static IP. It has DHCP capability. Indeed, you were correct that as soon as I got access to it, the first thing I did was change it to DHCP. I might go in at a later time and set it to a static IP address in the local network.
My understanding of the solution is that the router was informed about the existance of the 192.168.0.97/32 network by assigning to the interface “vlan-cameras” the ip address of 192.168.0.98.
Once the router knows about the network, and what interface to use as the gateway for that network, the dstnat and masquerade rules create the ip address translations to allow the device to communicate with the 10.72.32.x network.
Truly a brilliant, elegant and sophisticated solution that utilizes these powerful ROS facilities.
About this point: This address can be whatever IP address, even from subnets not managed by the router, it can be 3.4.5.6 for example. The only requirement is that on the remote WireGuard client device (a phone for example), “Allowed IPs” has some value that contains this address. For example, if it has 0.0.0.0/0 or 3.4.5.6/32 or 3.0.0.0/8, etc…
Because Allowed IPs can match this IP address, on the remote device, when OP enter 3.4.5.6 the device will use the WireGuard tunnel to send the packets to the hAP ax³ router. Like I said, the router doesn’t even need to have the subnet 3.x.x.x configured anywhere at all, because DSTNAT is in the prerouting part of the firewall, before any route lookup is made. The DSTNAT rule catches this destination address and changes it immediately into 192.168.0.97. Normally if there were no DSTNAT rule, then the router would try to send it to the WAN because the destination 3.4.5.6 only matches the 0.0.0.0/0 route. But because DSTNAT happens before route lookup, the destination of the packet is already 192.168.0.97 when RouterOS on hAP ax³ tries to find the route to forward the packet.
The rest is like @Josephny wrote. The route table has the entry with destination=192.168.0.97/32 gateway=vlan-cameras, that’s why vlan-cameras is picked as the outgoing interface. And before the packet is sent out, there is the srcnat rule, which is in the postrouting chain of the firewall (comes after route lookup and filter) that modifies the source of the packet to 192.168.0.98, so that when the camera receives it, it thinks that it just comes from a host in its subnet. Without the srcnat masquerade rule the camera sees a foreign source address in the packet (the IP address of the remote WG peer), it might reject that. In case it doesn’t reject, it will try to answer using the foreign IP address (which is from the remote WG device) and probably doesn’t know how to send the response if OP has not manually configured the default gateway on the camera.
In OP config, he chose 10.77.22.200 probably because 10.77.22.0/24 is one of the subnets of his router that is already allowed by “Allowed IPs” on the remote WG device (that way he doesn’t need Allowed IPs = 0.0.0.0/0 in the WG app). But if the app had Allowed IPs = 0.0.0.0/0, or contains 192.168.0.0/24 then OP won’t even need the DSTNAT rule, and he could even enter 192.168.0.97 directly on the remote device. The device will send the packet with destination 192.168.0.97 through the tunnel to the hAP ax³, and here no dstnat rule is needed, the router will route the packet using vlan-cameras as out-interface. The masquerade rule is still needed though.
