what does mikrotik Allow Remote Requests mean?

gabak · Thu Dec 25, 2014 10:07 pm

merry xmas everyone
i m trying to make a tutorial about mikrotik and i would like to know what does Allow Remote Requests mean?
i know i need it check up to have internet. Please can you answer with one or two examples of how it work.
thank you

Thu Dec 25, 2014 10:42 pm

You mean the one in the "/ip dns" menu?

This is whether to let other devices use RouterOS as a DNS server. If this option is not checked, client devices must use another device set as their DNS server. Regardless of this option, requests originating from RouterOS itself (e.g. from a script via the ":resolve" command) will check up the DNS entries defined there, and use the defined servers if the router doesn't know the answer.

You don't need to have this option enabled to have internet. If you disable it, you can give your client devices a different DNS, such as Google's 8.8.8.8 for example. That's what the DNS setting in "/ip dhcp-server network" is for. Or if you don't use DHCP, you can instruct clients to enter that other IP in their network settings.

A DNS server in general is not required to be in the same subnet. Only the default gateway must be.

gabak · Fri Dec 26, 2014 2:15 am

thank you very much for the answer.
here it is picture i upload.
so in few words it means that option let the router solve dns?
what is the remote requests? does it mean it permit or allow requests from outside of the LAN network to the server or internet?
or when i got a host in my network requesting a data outside of my lan to internet ,mikrotik will let that data get into my network.
let's say i do ping to yahoo, from my pc, then the data goes outside to yahoo server and when it want to come back, if that option is not set they packet wont be able to return if that option is not check.

Sob · Fri Dec 26, 2014 6:06 am

These settings apply only when clients use router's own address as DNS resolver.

If your clients use some external resolver, these settings will not influence them in any way.

If you do not check Allow Remote Requests, router will resolve names only for itself (e.g. when you have hostname in its VPN client, etc..). If you do check it, router will act as resolver for *any* other machine that asks for it.

Unfortunately there's no option to allow just LAN clients (there's a feature request, but who knows if it ever gets implemented). So when you enable Allow Remote Requests, you have to make sure that you allow incoming port 53 only for your clients and block the rest of the world using firewall. Otherwise you'll create open resolver and it's a bad thing.

Fri Dec 26, 2014 2:08 pm

When you ping yahoo.com from a client device, the client device first makes a connection to the DNS server defined in its own settings, asking it for the IP that "yahoo.com" corresponds to.

If your client device (e.g. 192.168.88.254) has 8.8.8.8 defined as their DNS server, it will contact the default gateway (e.g. 192.168.88.1), and ask it to forward a packet to 8.8.8.8, and send back the reply. The gateway connects to 8.8.8.8 via the internet, and eventually gives the client back the reply. The client only then asks the default gateway to make a connection to the IP that it just received via DNS.

That same procedure happens if the client device's DNS server is set to 192.168.88.1, but if the "Allow remote requests" option is not checked, the DNS exchange with 192.168.88.1 will fail, and thus you wouldn't be able to ping "yahoo.com". If you already knew the IP that "yahoo.com" is on, you can still ping to that IP, since it doesn't require a DNS lookup.

dadzejson · Wed Jul 11, 2018 10:44 am

Ok sorry for bumping but basically i check "allow remote requests" and added public IP address of that mikrotik router as dns server for "outside" computer and he cant resolve the DNS....im using RouterOS v6.40.8 ... I even made a firewall rule, chain - dstnat, protocol - udp, dst.port - 53, action - redirect, to ports - 53

...what im missing ? why i cant use my router as an extrenal dns and use static routes in it ?

mkx · Wed Jul 11, 2018 10:53 am

Ok sorry for bumping but basically i check "allow remote requests" and added public IP address of that mikrotik router as dns server for "outside" computer and he cant resolve the DNS....im using RouterOS v6.40.8 ... I even made a firewall rule, chain - dstnat, protocol - udp, dst.port - 53, action - redirect, to ports - 53

You don't do dstnat for connections to the router itself. Rather you add FW rule to chain=input allowing particular connection. Something like

/ip firewall filter
add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp

perhaps adding src-address=xx.yy.ww.zz to allow connections only from select remote hosts (don't forget to allow LAN hosts!).

dadzejson · Wed Jul 11, 2018 11:35 am

Ok sorry for bumping but basically i check "allow remote requests" and added public IP address of that mikrotik router as dns server for "outside" computer and he cant resolve the DNS....im using RouterOS v6.40.8 ... I even made a firewall rule, chain - dstnat, protocol - udp, dst.port - 53, action - redirect, to ports - 53
You don't do dstnat for connections to the router itself. Rather you add FW rule to chain=input allowing particular connection. Something like
Code: Select all
/ip firewall filter
add action=accept chain=input comment="Accept DNS - UDP" port=53 protocol=udp
add action=accept chain=input comment="Accept DNS - TCP" port=53 protocol=tcp
perhaps adding src-address=xx.yy.ww.zz to allow connections only from select remote hosts (don't forget to allow LAN hosts!).

Tried with those firewall rules (i tought if u dont set that rule it will accept automaticly !?).

The thing is that i put public IP directly into DNS TCP/IP configuration of external computer of my router and it still doesnt resolve anything....even tho i can see some 285 UDP accepted packets with ur first firewall rule...

Dont know what im doing wrong...i thought i only need to check that "Allow Remote Requests" and its done (ofc with public IP on WAN interface)

dadzejson · Wed Jul 11, 2018 1:17 pm

I'm reading some topics here and someone said that router should not be in DNS "client" mode but in DNS Server mode....how can i check that, when is he operating as a client and when as a server ?

sindy · Wed Jul 11, 2018 3:03 pm

The DNS process on the router always handles the requests of other processes on the router to translate an fqdn to IP address (e.g. when you write ping mikrotik.com on router's command line, the DNS process translates mikrotik.com to an IP address). The process has two sources of information - local static DNS records you configure and external DNS servers. The addresses of the external servers can be configured manually and/or received via dynamic host configuration protocols such as DHCP or various alternatives embedded into ppp-type protocols. The process caches the responses from external servers.

allow-remote-requests=yes solely permits the DNS process to listen for incoming requests at UDP port 53 and process these requests. The DNS process itself doesn't care about the source address of those requests. So whether a particular client will be served or not depends on firewall settings. A typical firewall ignores any packets coming from WAN side, except those it knows (thanks to connection-tracking) to be responses for packets previously sent out via the WAN interface. Order of rules in the firewall matters, so the rule action=accept chain=input protocol=udp dst-port=53 must be at the right place in the list to do what you expect it to do.

But opening a local DNS service for requests coming from anywhere in the internet is not a good idea as DNS is a UDP service so it is easy to make your device participate in a DDoS attack if it is configured to send a packet back to the source address of an incoming packet. So if I want to attack UDP port X on address x.x.x.x, it is enough to send to your UDP port 53 a DNS query packet with source address x.x.x.x and source port X; your device will send the DNS response to that address and port and my own address remains invisible to the target - from the target's perspective, it is you who attacks him.

dadzejson · Fri Jul 13, 2018 12:47 pm

Sindy tnx for the answer, and i get that totally...awesome explanation of how dns works tho....but...

Im losing all the hope after all of these days...

So basically i set up everything, tried every solution possible (all kind of firewall rules, different routerOS, change every little thing in DNS conf) and it cant resolve anything that i put as a static address or even anything when i put public IP of my mikrotik DNS server... It can resolve from the inside tho, but from WAN interfaces nothing (i have two comupters, one with completely different ISP, and one on VPN, so i treat those as a clients that are accessing from WAN)....and nothing :/ ....

mkx · Fri Jul 13, 2018 1:37 pm

Are you sure your ISP is not filtering DNS requests targeted at their clients? Use torch tool and check if there are any packets targeting your public IP TCP/UDP port 53 coming to your WAN interface ...
OK, I see that you mentioned filter counters going up. However, that doesn't rule out IPS filtering. Recently we've seen on this forum a case where ISP was filtering replies rather than incoming packets. After user asked ISP about that, ISP ceased doing it (at least for that particular user).

dadzejson · Sat Jul 14, 2018 2:17 pm

Are you sure your ISP is not filtering DNS requests targeted at their clients? Use torch tool and check if there are any packets targeting your public IP TCP/UDP port 53 coming to your WAN interface ...
OK, I see that you mentioned filter counters going up. However, that doesn't rule out IPS filtering. Recently we've seen on this forum a case where ISP was filtering replies rather than incoming packets. After user asked ISP about that, ISP ceased doing it (at least for that particular user).

Tnx for getting into conversation and trying to help mkx...

That was a nice idea and i did the torch, and looks like there are packets from ISP's side that are hitting my Public IP (Wan), but only packets that i create from those remote computers (which is nice, i dont get any spam, attacks, etc.)...its looks like the DNS server cant replay anything for public side....so i have some feeling that i need to do something so server can, not resolve, but proceed the respond to the WAN interface (something on firewall maybe), because he gets the packets from WAN but he is not responding to request (but he is responding and resolving anything from LAN)....im gonna check with the ISP if they are blocking or not.

EDIT: just had a conversation with the technicians from ISP and they are not blocking anything on 53...

sindy · Sat Jul 14, 2018 2:35 pm

If the torch doesn't show the responses, there is no need to talk to ISP - if ISP was blocking it, you would see the responses in torch but they wouldn't get through the ISP network to the asking PC.

So follow the instructions in my automatic signature, it must be something in your firewall settings.

dadzejson · Sat Jul 14, 2018 9:21 pm

If the torch doesn't show the responses, there is no need to talk to ISP - if ISP was blocking it, you would see the responses in torch but they wouldn't get through the ISP network to the asking PC.

So follow the instructions in my automatic signature, it must be something in your firewall settings.

I thought they are blocking the replay's from ISP's clients just like mkx said, not requests

Recently we've seen on this forum a case where ISP was filtering replies rather than incoming packets. After user asked ISP about that, ISP ceased doing it (at least for that particular user).

I saw on torch packets that are hitting on WAN but that does not confirm that ISP is not blocking the DNS replays from my side. Did i miss something, am i getting this right ?

sindy · Sat Jul 14, 2018 10:48 pm

I saw on torch packets that are hitting on WAN but that does not confirm that ISP is not blocking the DNS replays from my side. Did i miss something, am i getting this right ?

If the ISP would be blocking the queries, you wouldn't see them in torch. As you can see the queries, the ISP is not blocking them.

If you could see the responses in torch but the client wouldn't get them, it would mean that the ISP is blocking the responses. However, as you cannot see the responses, you cannot tell whether the ISP is blocking them or not, but you can see that either the DNS process does not respond the queries (which I doubt), or your routing sends them via some other port than the WAN through which the requests came in, or your firewall blocks them.

The torch conditions should, in addition to the interface name, look like this:

src-address=0.0.0.0/0 dst-address=0.0.0.0/0 ip-protocol=udp port=53

Don't get distracted by src and dst addresses being swapped, torch sometimes behaves funny. If you see packets in both directions (on one row 53 is src-port and on another row 53 is dst-port), then the ISP is filtering the responses. If you only see 53 as dst-port but never as src-port, something inside your 'Tik is wrong.

And one important point - if the client is using TCP to query the Mikrotik, everything is clear, Mikrotik's DNS server doesn't support TCP queries.

dadzejson · Sun Jul 15, 2018 9:55 am

Yea i used the torch exactly like that and there is no src-adr thats my WAN ip and dst-adr thats remote DNS client....

If you see packets in both directions (on one row 53 is src-port and on another row 53 is dst-port), then the ISP is filtering the responses. If you only see 53 as dst-port but never as src-port, something inside your 'Tik is wrong.

This is the case...so i hope its something wrong that i can fix...what firewall rule should i apply ? And does the place of firewall rule matter ?

sindy · Sun Jul 15, 2018 10:21 am

...what firewall rule should i apply ? And does the place of firewall rule matter ?

Yes, the order of the rules does matter, so without knowledge of the overall configuration, no one can suggest you what rule to add or which rule to remove or modify. So again, to get a useful advice, follow the instructions in my automatic signature.

dadzejson · Sun Jul 15, 2018 3:35 pm

...what firewall rule should i apply ? And does the place of firewall rule matter ?
Yes, the order of the rules does matter, so without knowledge of the overall configuration, no one can suggest you what rule to add or which rule to remove or modify. So again, to get a useful advice, follow the instructions in my automatic signature.

I dont have any rules in firewall, so i just need basic command like chain=output protocol=udp port=53 action=accept ...i tried a few rules but seems that non of those works...

sindy · Sun Jul 15, 2018 5:22 pm

No rules in firewall mean everything is permitted. This is a) a very bad idea (to put it softly) on a machine with a public address on it, and b) an indication that the issue must be within routing or the DNS process itself.

dadzejson · Mon Jul 16, 2018 12:31 pm

No rules in firewall mean everything is permitted. This is a) a very bad idea (to put it softly) on a machine with a public address on it, and b) an indication that the issue must be within routing or the DNS process itself.

Well i did system reset-config and did just a basic setup from scratch, and still DNS server is not replaying to outside clients...

I tried with different mikrotik, from company that i work for, and it works easy as hell...

I tried with 3 different RouterOS at my router and it still doesnt work....im runnin out of ideas :/

mkx · Mon Jul 16, 2018 3:21 pm

....im runnin out of ideas :/

Many users of this forum can supply you with many ideas. But you stubbornly ignore suggestion by @sindy to post full configuration export (obfuscated sensitive data such as public IP address, username and password) and it is really hard to point out think of all possible configuration mistakes that can be made.

dadzejson · Mon Jul 16, 2018 3:38 pm

Here is the code, but there is like nothing...i do have some dynamic routes tho, dont know why that didnt dispay in the export command....

BTW, i did everything on fresh new clean RouterOS without any configuration (except that DNS settings, static DNS record, and DHCP client so i can get internet access)...and without any configuration he couldnt replay the DNS record outside...

EDIT: i just want to say guys i appreciate so much that u are involved in my problem, cuz im learning a lot in this way...tnx to u guys

/interface ethernet
set [ find default-name=ether1 ] name=ether1-Wan
set [ find default-name=ether2 ] name=ether2-Wireless
set [ find default-name=ether3 ] name=ether3-Jason
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec proposal
set [ find default=yes ] enc-algorithms=3des
/ip pool
add name=dhcp_pool0 ranges=192.168.84.2-192.168.84.254
add name=dhcp_pool1 ranges=192.168.84.2-192.168.84.254
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=ether2-Wireless lease-time=1h name=dhcp1
/ppp profile
set *0 only-one=yes
/queue simple
add disabled=yes max-limit=1M/10M name=Wireless target=192.168.84.0/24
/system logging action
set 0 memory-lines=100
set 1 disk-lines-per-file=100
/interface pptp-server server
set default-profile=default enabled=yes
/ip address
add address=192.168.84.1/24 interface=ether2-Wireless network=192.168.84.0
add address=10.0.0.1/24 interface=ether3-Jason network=10.0.0.0
/ip cloud
set ddns-enabled=yes
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1-Wan use-peer-dns=no
/ip dhcp-server network
add address=192.168.84.0/24 dns-server=8.8.8.8,8.8.4.4 gateway=192.168.84.1
/ip dns
set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4
/ip firewall nat
add action=masquerade chain=srcnat comment="nat for eth3" out-interface=ether1-Wa
    src-address=10.0.0.0/8
add action=masquerade chain=srcnat comment="nat for eth2" out-interface=ether1-Wa
    src-address=192.168.84.0/24
add action=dst-nat chain=dstnat comment="web server" disabled=yes dst-port=80 protocol=tcp to-addr
    10.0.0.10 to-ports=80
/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=192.168.84.253
/ip service
set telnet disabled=yes
set ftp disabled=yes
set www disabled=yes
set ssh disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/system clock
set time-zone-name=Europe/Belgrade
/system identity
set name="Mikrotik"

mkx · Mon Jul 16, 2018 3:59 pm

Dynamic entries don't get into export, you can only see those using print command.

Is there anything weird if you issue command "/ip firewall filter print"?

sindy · Mon Jul 16, 2018 4:17 pm

export only shows the static configuration elements, to see the dynamically created ones, you need to use print, and you can only print a single configuration tree leaf at a time. So post also /ip route print, and in order that it would make sense, you'll have to obfuscate only the gateway IPs; the route dst-address must remain verbatim, and you'll have to publish the address of the client from which you test.

dadzejson · Mon Jul 16, 2018 4:17 pm

Dynamic entries don't get into export, you can only see those using print command.

Is there anything weird if you issue command "/ip firewall filter print"?

Nothing.... just this from the code

 0 X  ;;; accept DNS UDP
      chain=input action=accept protocol=udp port=53 log=no log-prefix="" 

 1 X  chain=input action=accept protocol=tcp port=53 log=no log-prefix="" 

 2    chain=output action=accept protocol=udp out-interface=ether1-Wan port=53 log=no log-prefix=""

dadzejson · Mon Jul 16, 2018 4:20 pm

export only shows the static configuration elements, to see the dynamically created ones, you need to use print, and you can only print a single configuration tree leaf at a time. So post also /ip route print, and in order that it would make sense, you'll have to obfuscate only the gateway IPs; the route dst-address must remain verbatim, and you'll have to publish the address of the client from which you test.

u mean the public ip from dns client ? here is the ip route:

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 ADS  0.0.0.0/0                          xx.xxx.xxx.x              1
 1 ADC  10.0.0.0/24        10.0.0.1        ether3-Jason              0
 2 ADC  xx.xxx.xxx.0/21    xx.xxx.xxx.xxx  ether1-Wan                0
 3 A S  192.168.1.0/24                     192.168.84.253            1
 4 ADC  192.168.84.0/24    192.168.84.1    ether2-Wireless           0

mkx · Mon Jul 16, 2018 4:27 pm

Another idea for using torch: when you observe incoming DNS request at your WAN port, do you see a DNS request originating RB device being targeted at either of DNS forwarders (8.8.8.8 or 8.8.4.4)? Do you see reply coming from those?

Unless reply to your own DNS request is cached at router's DNS service, you should be able to see that IP packet exchange.

dadzejson · Mon Jul 16, 2018 4:32 pm

Another idea for using torch: when you observe incoming DNS request at your WAN port, do you see a DNS request originating RB device being targeted at either of DNS forwarders (8.8.8.8 or 8.8.4.4)? Do you see reply coming from those?

Unless reply to your own DNS request is cached at router's DNS service, you should be able to see that IP packet exchange.

yes i can see all the replays....i can see src 8.8.8.8 and dest 8.8.8.8 from the RB...everything is so clear...when remote client asks RB to resolve some dns record, router performs excellent, he resolves anything (from 8.8.8.8 ), put it even in a cache, but when it comes to forward that packet with src=public WAN, dst=remote client, that packet just doesnt happen, at least not in a torch, and in ipconfig /displaydns on remote dns client

dadzejson · Mon Jul 16, 2018 4:48 pm

The funny thing is that im trying to reslove dns query from 3 different ISPs from my country...and the situation is similar....i have RB433, with RouterOS 6.42.6 (i tried with 3 different version, the basic one, the 6.40.8, and this one - the newest)...called 2 times my ISP to ask them if they are blocking dns replays from their clients and two times the answer was no....so i have some feeling that is some generic problem, hardware, or something like that :/

mkx · Mon Jul 16, 2018 5:05 pm

Perhaps unrelated: you have configured static route towards network 192.168.1.0/24 using gateway with address 192.168.85.253. That IP address is member of DHCP address pool you're using. Either the gateway is really using DHCP-assigned address which means it can change in time (I don't see static assignment in your export) and the static route would fail ... or you've statically set up device's address but in this case you'd better choose address outside DHCP address pool to avoid potential address collision.

Can you kindly show (at least one of) IP address of a DNS client so we can (mentally) verify your routing set-up.

dadzejson · Mon Jul 16, 2018 5:16 pm

Perhaps unrelated: you have configured static route towards network 192.168.1.0/24 using gateway with address 192.168.85.253. That IP address is member of DHCP address pool you're using. Either the gateway is really using DHCP-assigned address which means it can change in time (I don't see static assignment in your export) and the static route would fail ... or you've statically set up device's address but in this case you'd better choose address outside DHCP address pool to avoid potential address collision.

Can you kindly show (at least one of) IP address of a DNS client so we can (mentally) verify your routing set-up.

Here is one of my remote IPs, im using HSPA+ hotspot of mobile, so i connected laptop to it...the ip is 77.243.29.179 ....

Btw, its not about the routes, because i tried with blank system conf reset RB, without any more config, and the problem was the same:

BTW, i did everything on fresh new clean RouterOS without any configuration (except that DNS settings, static DNS record, and DHCP client so i can get internet access)...and without any configuration he couldnt replay the DNS record outside...

Sob · Mon Jul 16, 2018 5:19 pm

It's possible to miss things in torch, you can use logging rules instead:

/ip firewall mangle
add action=log chain=output log-prefix="step1" protocol=udp src-port=53
add action=log chain=postrouting log-prefix="step2" protocol=udp src-port=53

And btw:

And one important point - if the client is using TCP to query the Mikrotik, everything is clear, Mikrotik's DNS server doesn't support TCP queries.

My RouterOS answers tcp queries just fine.

dadzejson · Mon Jul 16, 2018 5:27 pm

It's possible to miss things in torch, you can use logging rules instead:
Code: Select all
/ip firewall mangle
add action=log chain=output log-prefix="step1" protocol=udp src-port=53
add action=log chain=postrouting log-prefix="step2" protocol=udp src-port=53
And btw:
And one important point - if the client is using TCP to query the Mikrotik, everything is clear, Mikrotik's DNS server doesn't support TCP queries.
My RouterOS answers tcp queries just fine.

What postrouting means ? cuz on mangle windows there are some packets flowing around at that step 2

Sob · Mon Jul 16, 2018 10:00 pm

It's after packet was routed somewhere. And it will show some you don't need to see, so try to add src-address-type=local as basic filter. In any case, when you send request from outside, you should see both steps logged for response.

dadzejson · Mon Jul 16, 2018 11:39 pm

It's after packet was routed somewhere. And it will show some you don't need to see, so try to add src-address-type=local as basic filter. In any case, when you send request from outside, you should see both steps logged for response.

when i do nslookup google.com on remote DNS client both mangles gets their packets incremented...

im hitting the limit of my network knowledge here i guess...

Sob · Tue Jul 17, 2018 12:17 am

They should also be logged with some details, so check if packets are going the right way, i.e. via WAN interface to client's IP address. If they do, then router is sending replies back to client correctly. And if they don't arrive, then something must eat them somewhere between you and client. But it's not easy to diagnose it when the path is not under your control.

sindy · Tue Jul 17, 2018 12:20 am

/log print where topics~"firewall"

dadzejson · Wed Jul 18, 2018 6:02 pm

They should also be logged with some details, so check if packets are going the right way, i.e. via WAN interface to client's IP address. If they do, then router is sending replies back to client correctly. And if they don't arrive, then something must eat them somewhere between you and client. But it's not easy to diagnose it when the path is not under your control.

Can u explain me more what should i do exactly to track that and be sure that packet went out of my WAN int ? Im kinda confuse :/

/log print where topics~"firewall"

The command doesnt display me anything :/

sindy · Wed Jul 18, 2018 6:19 pm

/log print where topics~"firewall"
The command doesnt display me anything :/

That sounds like logging was completely off for firewall events or other events arrive with such a pace that they kick off the older events (including those from firewall) before you issue the command. So you can run /log print follow-only where topics~"firewall" while testing the DNS to see whether the events are logged or not.

dadzejson · Thu Jul 26, 2018 9:48 am

They should also be logged with some details, so check if packets are going the right way, i.e. via WAN interface to client's IP address. If they do, then router is sending replies back to client correctly. And if they don't arrive, then something must eat them somewhere between you and client. But it's not easy to diagnose it when the path is not under your control.

is this the proof that dns replay made out on WAN interface, i logged something from the step1 and its like this:

step1 output: in (unknown 0) out: ether1-Wan, proto UDP, *my dns server public IP address*:53 -> *remote dns client that im using*:59363, len 168

sindy · Thu Jul 26, 2018 10:45 am

is this the proof that dns replay made out on WAN interface

Yes, it is.

dadzejson · Thu Jul 26, 2018 10:53 am

is this the proof that dns replay made out on WAN interface
Yes, it is.

Tnx, ISP is telling me that they are not blocking anything, but 4 different client IPs cant receive DNS replay....i guess i will speak with them again.

sindy · Thu Jul 26, 2018 2:33 pm

replay = proigrati ponovo,
reply = odgovoriti (ili odgovor)

I'm a bit nervous about the firewall log showing the packet but the torch not, I don't remember whether you did a sniff on the interface.

Where exactly (to which table & chain) have you placed the rule which has logged that packet?

CZFan · Thu Jul 26, 2018 5:09 pm

...
I'm a bit nervous about the firewall log showing the packet but the torch not, I don't remember whether you did a sniff on the interface.
...

Can it be that the "Torch" screen update time? i.e. between updates this happened hence did not show?

dadzejson · Thu Jul 26, 2018 10:53 pm

I finally got an answer from different section of ISP, and they give me the tech prospect which saying that they are blocking source port 53 from clients in order to maximize security....

So 3 times i was in contact with "some" technical support and they told me they are blocking nothing, but thats not the case...its really crazy when someone is not informed like that...

Who is online