/ip dhcp-server network
server1.myowndomain.here
chain=dstnat
/ip firewall nat
/ip firewall address-list
address-list
/ip firewall layer7-protocol
add name="dns for local.mesh" regexp="\\x05local\\x04mesh.\\x01"
/ip firewall nat
add action=dst-nat chain=dstnat protocol=udp dst-port=53 in-interface=<LAN> \
layer7-protocol="dns for local.mesh" to-addresses=<local.mesh DNS server>
whatever.com
something.local.mesh
.0x01
0x01
0x00
layer7-protocol
/ip firewall nat
add action=dst-nat chain=dstnat content="\05local\04mesh\00" dst-port=53 protocol=udp to-addresses=ip.of.mesh.dns.server
dstnat
The problem is rather that it is hard to understand from your description what you actually want.
I have tried while developing my "plaintext" match. You are almost right but the sequence looks as follows:@sindy: I must insist on my pattern (at least for now, maybe there is some possible improvement). Null byte at the end would be correct, because that's what's in the packet. But RouterOS drops all null bytes from input, before it tries the regexp, and it makes the input quite unpredictable. And if you'd let it end with just "mesh", it would also match hostnames like local.mesh.example.com. So in order to filter out false positives, you need to look for other non-null bytes. Right after hostname are two 16-bit numbers, query type (A, AAAA, ...) and class. First one varies, but luckily most common records are < 256, so that's the "." for any byte. And class is for most uses 1.
sales.local.mesh: type A, class IN
Name: sales.local.mesh
[Name Length: 16]
[Label Count: 3]
Type: A (Host Address) (1)
Class: IN (0x0001)
05 73 61 6c 65 73 05 6c 6f 63 61 6c 04 6d 65 73 68 00 00 01 00 01
05 s a l e s 05 l o c a l 04 m e s h 00
00 01
00 01
contain
..\x01
05 73 61 6c 65 73 05 6c 6f 63 61 6c 04 6d 65 73 68 00 00 01 00 01
05 73 61 6c 65 73 05 6c 6f 63 61 6c 04 6d 65 73 68 01 01
So yourBut the problem is RouterOS eating null bytes, so if packet contains this:then L7 matcher works with this:Code: Select all05 73 61 6c 65 73 05 6c 6f 63 61 6c 04 6d 65 73 68 00 00 01 00 01
And with content="\05local\04mesh\00", there are two problems. First is minor, you have to use CLI to enter this, and non-printable characters will show as garbage in WinBox and WebFig. Another is that this will be case-sensitive (unlike L7 matching), so it can miss some queries.Code: Select all05 73 61 6c 65 73 05 6c 6f 63 61 6c 04 6d 65 73 68 01 01
.\x01
contains
layer7-protocol
\0x03tld.{2,4}$
\0x03tld...?.?$
I had some time to work on this again, and yes, the new NAT rule counter does increase when when I attempt to navigate to an address on the Mesh network, but the Hairpin counter does not increase. I tried to use the hairpin settings I used for my webserver and modify them for the mesh connection at 192.168.1.200, but I'm not totally sure I am doing it correctly. so it seems like the rule is sending it correctly, but the issue may be on the hairpin. I am only using 2 ports on my MikroTik, would it make sense to move my Mesh device that is 192.168.1.200 off of my main network, and place it on Port 3 of the MikroTik and eliminate the hairpin all together, or am I making things more complicated? I could set it back to its default 10.x.x.x address and to not have conflicts with my home subnet.
@kd7vea: Two things to make sure about:
1) ether2 is the interface where your PC (or whatever device you test it with) is connected to
2) 192.168.1.200 is DNS server that knows how to resolve <anything>.local.mesh
Is so, does the counter for this rule increase? If it does, the problem might be elsewhere. E.g. if you PC would be in same subnet as 192.168.1.200, you'd also need to set up hairpin NAT.
/ip route
add dst-address=10.0.0.0/8 gateway=192.168.1.200
zone "subzone.mydns.example.com" {
type forward;
forwarders { 192.168.0.4; };
};