DNS "allow-remote-requests" -- how remote?
RouterOS general discussion

15 posts   •   Page 1 of 1
User avatar
macsrwe
Member Candidate
Member Candidate
 
Posts: 278
Joined: Mon Apr 02, 2007 5:43 am
Location: Arizona, USA

DNS "allow-remote-requests" -- how remote?

by macsrwe » Thu Sep 12, 2013 9:20 pm

For years, our network has had one connection to the internet. Recently, we added a second, independent gateway on the "far end" to improve reliability. This required us to juggle routing and deal with two mutually suspicious DNSes.

We rooted out all the hard-coded DNS server addresses in our CPEs, instead instructing all CPEs to request DNS service from their local tower, which would forward to the correct full server.

We encountered strangeness while correcting DHCP leases. We took out the hard-coded DNS server addresses in /ip dhcp-server network, and instead had the subscriber PCs go to the CPE for resolution. In other words, in a DHCP pool where we handed out LAN addresses of 192.168.1.2-192.168.1.254, both the gateway and the DNS server were set to 192.168.1.1.

This resulted in total failure until we turned on "allow-remote-requests" in the CPE's DNS panel.

A request from 192.168.1.2 to 192.168.1.1 qualifies as a "remote" request???

The wiki manual isn't very clear as to exactly what this switch controls; it just uses the word "remote" without really explaining what is going on. I feel like Inigo Montoya -- "I do not think that word means what you think it means."

What precisely does it mean?

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Thu Sep 12, 2013 9:23 pm

macsrwe wrote:For years, our network has had one connection to the internet. Recently, we added a second, independent gateway on the "far end" to improve reliability. This required us to juggle routing and deal with two mutually suspicious DNSes.

We rooted out all the hard-coded DNS server addresses in our CPEs, instead instructing all CPEs to request DNS service from their local tower, which would forward to the correct full server.

We encountered strangeness while correcting DHCP leases. We took out the hard-coded DNS server addresses in /ip dhcp-server network, and instead had the subscriber PCs go to the CPE for resolution. In other words, in a DHCP pool where we handed out LAN addresses of 192.168.1.2-192.168.1.254, both the gateway and the DNS server were set to 192.168.1.1.

This resulted in total failure until we turned on "allow-remote-requests" in the CPE's DNS panel.

A request from 192.168.1.2 to 192.168.1.1 qualifies as a "remote" request???

The wiki manual isn't very clear as to exactly what this switch controls; it just uses the word "remote" without really explaining what is going on. I feel like Inigo Montoya -- "I do not think that word means what you think it means."

What precisely does it mean?

Remote request means anything other than the router itself... so yes... even the local ips are "remote" relative to the mikrotik. Just make sure you block port 53 from the public side using the firewall filter table.
If I helped you please remember to give Karma.

eightace
just joined
 
Posts: 19
Joined: Sun Aug 11, 2013 11:37 am

Re: DNS "allow-remote-requests" -- how remote?

by eightace » Thu Sep 12, 2013 11:17 pm

I tried blocking port 53 and was still accepting external DNS requests on port 53 until I unticked the box IP -- DNS -- Allow remote requests.
I set the firewall to drop connections on port 53 via ether 1 and 3 which I use for my incoming PPPoE connections.

Is there a reason it wouldn't work?

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Thu Sep 12, 2013 11:34 pm

Udp or tcp? Remember dns can use both.

Sent from my SCH-I545 using Tapatalk 4
If I helped you please remember to give Karma.

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Thu Sep 12, 2013 11:35 pm

Post your configuration and maybe a diagram of your setup and I'll be able to help more

Sent from my SCH-I545 using Tapatalk 4
If I helped you please remember to give Karma.

Rudios
Forum Veteran
Forum Veteran
 
Posts: 752
Joined: Mon Mar 11, 2013 1:58 pm
Location: The Netherlands

Re: DNS "allow-remote-requests" -- how remote?

by Rudios » Fri Sep 13, 2013 1:19 pm

My advice is to allow the traffic you want to (E.g. allow internal systems) and drop everything else.
Testing setup with: 2 x RB750UP | 2 x RB750GL | 1 x RB951G-2HnD | 1 x RB2011UiAS-IN

eightace
just joined
 
Posts: 19
Joined: Sun Aug 11, 2013 11:37 am

Re: DNS "allow-remote-requests" -- how remote?

by eightace » Sat Sep 14, 2013 12:31 am

I have two PPPoE connections coming to my router over ether 1 and ether 3.
I added the following to prevent external DNS requests:

/ip firewall filter
add chain=input in-interface=ether1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether1 protocol=tcp dst-port=53 action=drop
add chain=input in-interface=ether3 protocol=udp dst-port=53 action=drop
add chain=input in-interface=ether3 protocol=tcp dst-port=53 action=drop

and my Mikrotik still has port 53 open according to https://www.grc.com/x/portprobe=53

What am I doing wrong?

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Sat Sep 14, 2013 12:33 am

Don't you want to drop on the pppoe interface? Not the ether?

Sent from my SCH-I545 using Tapatalk 4
If I helped you please remember to give Karma.

eightace
just joined
 
Posts: 19
Joined: Sun Aug 11, 2013 11:37 am

Re: DNS "allow-remote-requests" -- how remote?

by eightace » Sat Sep 14, 2013 9:29 am

That worked.
Can you explain why though?
Do I have to use the PPPoE interface for NAT rules too as I have some trouble with those too?

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Sat Sep 14, 2013 2:13 pm

eightace wrote:That worked.
Can you explain why though?
Do I have to use the PPPoE interface for NAT rules too as I have some trouble with those too?


Sure. For the real answer lookup the packet flow diagram and follow it through, but I'll give you the brief version here.

Basically ALL packets come in on ether1 and ether3, but when they are coming in they are all "PPPoE" type packets. The RouterBoard then takes them apart and determines what their "virtual interface" is. Then they come in through the "virtual interface". So for firewalling purposes if you wanted to filter PPPoE data then ether1 or ether3 would be correct, but odds are you don't actually want to do that. Since you really want to filter the data inside of the PPPoE tunnel and NOT the PPPoE packets themselves you want to use the "virtual interface".

The same would hold for NAT. If you NAT using ether1 or ether3 as the destination you will be sending those packets to the PPPoE server, or anyone else on the ether1/ether3 interfaces, but as normal packets. E.g. not PPPoE packets to the PPPoE server. It is basically the same as the above, just backwards. So you want to send them to the "virtual interface" so the routerboard encapsulates them in the PPPoE packet and sends them to the server.

To really get it I recommend you lookup the packet flow diagram and just step through it with your packets.

Does all that make sense? Think about the difference as this.... ether1 and ether3 should have mostly PPPoE packets on them.... and the virtual interfaces will have the actual data on them after they are de-encapsulated (generally what you want to filter, etc).
If I helped you please remember to give Karma.

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Sat Sep 14, 2013 9:28 pm

efaden wrote:
eightace wrote:That worked.
Can you explain why though?
Do I have to use the PPPoE interface for NAT rules too as I have some trouble with those too?


Sure. For the real answer lookup the packet flow diagram and follow it through, but I'll give you the brief version here.

Basically ALL packets come in on ether1 and ether3, but when they are coming in they are all "PPPoE" type packets. The RouterBoard then takes them apart and determines what their "virtual interface" is. Then they come in through the "virtual interface". So for firewalling purposes if you wanted to filter PPPoE data then ether1 or ether3 would be correct, but odds are you don't actually want to do that. Since you really want to filter the data inside of the PPPoE tunnel and NOT the PPPoE packets themselves you want to use the "virtual interface".

The same would hold for NAT. If you NAT using ether1 or ether3 as the destination you will be sending those packets to the PPPoE server, or anyone else on the ether1/ether3 interfaces, but as normal packets. E.g. not PPPoE packets to the PPPoE server. It is basically the same as the above, just backwards. So you want to send them to the "virtual interface" so the routerboard encapsulates them in the PPPoE packet and sends them to the server.

To really get it I recommend you lookup the packet flow diagram and just step through it with your packets.

Does all that make sense? Think about the difference as this.... ether1 and ether3 should have mostly PPPoE packets on them.... and the virtual interfaces will have the actual data on them after they are de-encapsulated (generally what you want to filter, etc).


Totally forgot to put the URL for the diagram in here...

http://wiki.mikrotik.com/wiki/Manual:Packet_Flow_v6
viewtopic.php?f=2&t=72736&hilit=Packet+Flow+Diagram

Specifically on the second link look at Example 2.1. It shows how a packet comes in via PPPoE. See download/file.php?id=13281 for the example.
If I helped you please remember to give Karma.

eightace
just joined
 
Posts: 19
Joined: Sun Aug 11, 2013 11:37 am

Re: DNS "allow-remote-requests" -- how remote?

by eightace » Sun Sep 15, 2013 12:23 am

I have changed the firewall rule to:

/ip firewall filter
add chain=input in-interface=PPPoE1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=PPPoE2 protocol=tcp dst-port=53 action=drop
add chain=input in-interface=PPPoE1 protocol=udp dst-port=53 action=drop
add chain=input in-interface=PPPoE2 protocol=tcp dst-port=53 action=drop

I had a firewall script from the wiki which had set things up to accept all DNS so that was confusing things:

http://wiki.mikrotik.com/wiki/Basic_uni ... all_script

- one final question with the NAT rules - could I just select all ppp as the in interface?
Last edited by eightace on Sun Sep 15, 2013 12:38 am, edited 1 time in total.

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Sun Sep 15, 2013 12:38 am

Glad it's working

Sent from my SCH-I545 using Tapatalk 4
If I helped you please remember to give Karma.

eightace
just joined
 
Posts: 19
Joined: Sun Aug 11, 2013 11:37 am

Re: DNS "allow-remote-requests" -- how remote?

by eightace » Sun Sep 15, 2013 9:48 am

- one final question with the NAT rules - could I just select "all ppp" as the in interface?

Could that have worked with the DNS firewall rule too?

efaden
Forum Guru
Forum Guru
 
Posts: 1366
Joined: Sat Mar 30, 2013 2:55 am
Location: New York, USA

Re: DNS "allow-remote-requests" -- how remote?

by efaden » Sun Sep 15, 2013 2:04 pm

I believe so, but I'd have to check. I don't use pptp personally.

The other way to do it would be to allow the traffic you want, and just put a global drop as your last rule... That's what I do. It's easier to drop by default and allow certain things than it is to figure out everything you need to drop.

Sent from my SCH-I545 using Tapatalk 4
If I helped you please remember to give Karma.

15 posts   •   Page 1 of 1

Who is online

Users browsing this forum: Google [Bot] and 31 guests

It is currently Thu Dec 18, 2014 6:59 am