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.”
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.
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.
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).
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.