In dstnat rule, in-interface=ether3 must be where the client device that sends query for something.local.mesh is connected to. From your description I’m not sure if it is or not.
If DNS server (10.18.199.45) has correct route back to client subnet (192.168.1.x), you don’t need masquerade. But it it doesn’t, you need it.
Okay, my cllient Machine and all other devices are on ethernet 2, my modem is on ethernet 1, I put the .local.mesh network on ethernet 3. so it sounds like i need to move it back to ethernet 2 reconfigure the Nat rule for ethernet 2, and change the IP back to the NAT address. at that point I will try the Hairpin again and post my configuration. thanks for sticking with me through this nightmare.
Easy, just understand what each part does and it should be really simple.
Dstnat rule inspects packets with DNS queries coming from client device, and going to any DNS resolver. If L7 matches (i.e. the query is for anything.local.mesh), it changes destination to server that knows the answer. The packet gets routed there, server sends response back (it must know where) and that’s it.
So just using in-interface=ether2 in dstnat rule might be enough.
Based off of a previous post about seeing if the counters increment, I decided to do some testing. I have my web server on this same network, so I looked at the NAT rules for it and copied and modified them so that if you go to my public IP of 160.7.249.40:8080, you should see the local mesh node that is connected, but i cant even get to that webpage, so this tells me that it could be part of my overall problem. The mesh node runs a web server on port 8080 for setting up the node, and and some tools that show everybody else on the network. I also thought that if you could see the interface that I am working with, maybe it could make a little more sense.as to how this works and what I’m doing with it. The 2 rules on my web server NAT, when I go to my website (not on the Mesh node, but to my main web server) I see both counters increase. the first rule is a DSTNAT that sends port 80 of my public IP to my web server,
This rule increments the counter from inside or outside of my network
Chain dstnat
Dst. Address 160.7.249.40
Protocol 6 (tcp)
Dst. Port 80
Action dst-nat
To Addresses 192.168.1.86
This rule will increment the counter from inside my network
the second rule is an SRCNAT
Chain srcnat
Src. Address 192.168.1.0/24
Dst. Address 192.168.1.86
Protocol 6 (tcp)
Dst. Port 80
Out. Interface ether2
those are for my web server
I created rules for the web server on my node that runs on port 8080 from the actual Ubiquiti device but I only see the DSTNAT rule increase, the SRC rule count stays at zero
here are the rules
this rule will increase every time I try to get to my Mesh node web page from inside or outside of my network,
Chain dstnat
Dst. Address 160.7.249.40
Protocol 6 (tcp)
Dst. Port 8080
Action dst-nat
To Addresses 192.168.1.200
To Ports 8080
this rule stays at zero on the counter both inside and outside of the network
Chain srcnat
Src. Address 192.168.1.0/24
Dst. Address 192.168.1.200
Protocol 6 (tcp)
Dst. Port 8080
Out. Interface ether2
Action masquerade
To Ports 8080
I don’t know what to think of this. I feel like if I can get this issue figured out, I will be one step closer to getting the bigger issue figured out. any ides?
Check rules in /ip firewall filter, chain=forward.
When I look at the rules you posted, I don’t see any other difference than destination address and port. So if one set works, the other must work too. If not, it might be because router can’t communicate with 192.168.1.200 (can you ping it from router?) or the connection is blocked by firewall.
Edit: The question about ping if of course stupid, it must be accessible when it’s possible to connect from outside.
Okay, I got the issue of port forwarding my node to the internet. My gateway setting got unchecked on that mesh node. so I set it back to my default gateway. You can now look access the node main pages from the internet, but you cant browse the network from there (that would be kind of cool for showing the capabilities of the system to people) but you can get to the Mesh status page where you can see all of the other systems connected, and the services on the network like the PBX, FTP servers and so on. If you go to 160.7.249.40:8080 and click on Mesh Status, this may give you a little better idea of what I am working with. all of the red links are either other nodes that I can brows to, or under services column, these are services that have been added to the network, and I can click on those and brows to those(When I am directly connected to My ubiquiti rocket.
so now, I know that the port forwarding and Hairpin NAT should be working correctly, so now I just need to focus on the initial issue of being able to browse the network.
I don’t know if it’s intentional, but I can no longer access the server on port 80 from outside. The one on 8080 works.
My UPS went off line at home, everything came back online but the main webserver did not. it will be back up in about 10 minutes when I get home.
I did a little more testing this weekend, but still havent got it working. I believe the hairpin is working correctly because I can acces my Mesh node from inside my network, and also at 160.7.249.40:8080. I did start wondering because the nodes themselves run the webpages on port 8080, but I don’t believe any other machines on the network do, like the Email server, and samba server. but from what I understand from one of the Previous posts, the Layer 7 protocol can handle that even if that is the case.
Try to expand “not working” a little more.
So far we were dealing with DNS queries, that’s what L7 filter was for. Does this part work now, i.e. if from your PC you try e.g. “ping .local.mesh”, does it resolve the hostname correctly? If not, can you resolve it, when you ask the mesh-aware DNS server directly (in Windows you can use “nslookup .local.mesh 192.168.1.200”)?
If DNS works, routing will need few more touches. First your router must know route to mesh network:
/ip route
add dst-address=10.0.0.0/8 gateway=192.168.1.200
And since other mesh nodes are unlikely to know (correct me is I’m wrong) where your 192.168.1.0/24 is, you’ll also need NAT masquerade on your mesh mode, so all connections from 192.168.1.0/24 will look like they come from your node’s 10.x.x.x address an d replies will come back correctly.
port forwarding the nodes web server works, that was part of making sure the hair pin was working properly. The initial issue of trying to access devices on the .local.mesh network is still not working(The original issue, and the one that really matters) so I am going through your steps and here is what I am getting. I ran NSLookup and here is what I got.
nslookup N0KVN-Sector120.local.mesh 192.168.1.200
Servers: localnode.local.mesh
address: 192.168.1.200
DNS request timed out.
timeout was 2 seconds.
name: N0KVN-Sector120.local.mesh
address: 10.64.211.225
I then added the static route, and now I can ping the IP address of other nodes, and I can navigate to the nodes Be browsing to the IP address of the nodes.this is progress, its not the optimal method, but it does show that you are on the right path. there is just something in the DNS somewhere that isn’t working as it should.
as for the issue you questioned about other nodes being able to see mine on with the NAT address, those node only see my WAN address that is tied to the wireless, so the entire network infrastructure is based on wieless, that address is unchanged. in the configuration of my mesh node, I do any port forwarding I need to allow devices on my network out on to the Mesh network, so unless I am overlooking something, the Mikrotik shouldn’t have to handle any of the routing for other devices on the WAN side looking in.
so in short, the Static route now lets me brows the network by IP, but I still cant browse by name.
UPDATE
It is now fully working. The Static route was the Key. I had already setup a static, route but it wasn’t set up correctly. I followed the static route setup that was Posted by Sob, and then changed my primary DNS to 192.168.1.200, and secondary to 8.8.8.8. The connection is a little slow, but I’m not sure if that is related to the wireless connections or something in the routing. I will do some more testing tomorrow, but at least it works. Thanks for all of the help Sob, I am so happy to finally have this running.
Wait a little with celebration. You can’t combine internal and external DNS resolvers like this. It might appear to work, but you’ll experience seemingly random failures in future. Even though DNS resolvers are sometimes referred to as primary and secondary, they are supposed to be equal. There’s no guarantee that primary will be always asked first. And I don’t need to explain what will happen, if question for something.local.mesh goes to 8.8.8.8. Well, maybe I should. There won’t be any positive answer, this part is clear. But the negative answer won’t be “I don’t know, ask elsewhere”, it will be “this domain does not exist”. And if it’s clearly said that it doesn’t exist, client won’t ask another resolver and resolution will fail.
So one step back, we know that 192.168.1.200 is willing to answer DNS queries sent from your PC. We can assume that it will also work when source address will belong to router, because it’s in same subnet. Put back the original DNS config, enable dstnat rule for DNS with L7 filter and corresponding srcnat rule for hairpin NAT. Then try “nslookup N0KVN-Sector120.local.mesh” without specifying used server (it will use some from system config). Does this work? If not, post your NAT rules here.
so with everything set and my DNS servers set at 8.8.8.8 and 1.1.1.1, the NSLookup times out. I knew there were still some other issue because it is a little slow when browsing the Mesh network and I assumed it is due to the configuration. here is my NAT configuration.
Chain dstnat
Protocol 17 (udp)
Dst. Port 53
In. Interface ethernet 2
Layer7 Protocol dns for local.mesh
Action dst-nat
To Addresses 192.168.1.200
Chain dstnat
Dst. Address 160.7.249.40
Protocol 6 (tcp)
Dst. Port 8080
Action dst-nat
to-address 192.168.1.200
Chain srcnat
Src. Address 192.168.1.0/24
Dst. Address 192.168.1.200
Protocol 6 (tcp)
Dst. Port 8080
Out. Interface ether 2
Action Masquerade
To Ports 8080
If this is all, then you’re clearly missing hairpin NAT rule (srcnat) for DNS. It would be the same as for web, only with udp/53 instead of tcp/8080. Or you can use common one without protocol and port.
I know I had that NAT rule at some point, I think I got rid of it somewhere along the line by accident. It is now working with google DNS settings in the Router. It is still a little slow, but that may be on the wireless side, I will have to look into that.
For DNS, always use both TCP and UDP. Nowadays some applications are making large queries and, depending on the support for EDNS (large responses over UDP) you will need TCP.
In order to make this work without hiccups you really need your own DNS server. You should configure it with a forward type zone, so that queries for mesh.local will be forwarded to the right server, and default forwarders for the rest, pointing to the public DNS servers you wish to use, like 8.8.8.8, 1.1.1.1, 9.9.9.9 or your ISP’s servers.
If using bind, the syntax for a forward zone is (example):
zone "subzone.mydns.example.com" {
type forward;
forwarders { 192.168.0.4; };
};
Probably you can also use a different (and simpler to configure) DNS server like unbound but you must investigate a bit. Unbound has an advantage: if you use
the 1.1.1.1 public DNS server you can use the new encrypted DNS protocol so that your ISP won’t be able to incercept nor monitor your DNS queries (some have done that in the past).
73, EA2EKH
thanks for the info Bergante, this has been a learning experience, but that was part of the plan in switching over to the MikroTik router. I will assume that by running my own DNS, it should speed up the MESH network browsing. It is quite a bit slower than if I connect directly to it, so I will look into setting up a DHCP server. I think i still have a few Raspberry PI’s laying around, I don’t think there is a need for another big server???
The slowness shouldn’t be because of DNS. Address resolution happens only at the beginning, connections work further with IP addresses. And results are cached, so another connection to same address few seconds, minutes or even hours later (depends on TTL) does not need to repeat DNS resolution. And delay caused by routing the query through router will be something like a millisecond anyway. But I can’t say what else it could be.
RasPi is powerful enough for being DNS server, and you have more than one resolver software to choose from. Main problem is that it’s another machine. And if you make it your main DNS resolver, it becomes single point of failure. You can add another, but then it may become a little too complicated for given purpose.
if setting up my own DNS wont change the speed, I probably wont tackle that job right now. I will do some trace routes tonight and see whats going on with it.