Community discussions

 
WirelessRudy
Forum Guru
Forum Guru
Topic Author
Posts: 3089
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

dns cache resolving leaving router through wrong port?

Mon Apr 11, 2016 5:25 pm

We have one router connected to the internet and other port to the clients.
Ether 9 and ether 10 are in a OSPF / BGP setup so forward (=internet) traffic come in (requests) through port 9 and should come back to client though ether10 (response traffic).

Before we just had all traffic (in/out) flowing from/to router over ether10 and the router would catch all dns requests (p56) and reroute to itself (=internal cache) and that worked fine for months.
But today, after we arranged the second link to clients with OSPF / BGP separated up and downlink links with full failover it didn't work any more.

I had to disable the p56 dst-nat rule to make dns resolution possible again.
(I have to say that all clients traffic initially is told to use an dns server outside our network. So dns is not pointing to one of the internal IP's of the gateway router. It points to the internet servers)

Now are the two ports ether 9 end ether 10 both in this router that is also having the dns cache and connect to the internet.

So, I can understand that a dns request pointing to an internet server that comes in at ethernet 9 gets actually 'catched' by the dst-nat rule and is redirected to the internal cache. The router now has to send back an answer to a destination that was the original source address. All router's forward traffic is leaving through ethernet 10.
But this is actaully now 'output' chain traffic. Leaving the router from itself. Maybe the connection tracker has in its registration tables that the request originally entered router from ethernet 9 and thus is send back to that same interface again? Since the OSPFis in charge of the traffic this is now a dead end for this dns response traffic and thus it never makes it back to the client?
I can understand all that, but to be honest have no clue how to solve this apart from enabling the 'forwarding to the internet of dns' again.......

Any suggestions?
If you need some more info let me know and I'll print these.
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: dns cache resolving leaving router through wrong port?

Mon Apr 11, 2016 6:39 pm

There's no OUTPUT chain in the nat table....

In general, you should only need these two rules in the dstnat chain:
protocol=udp dst-port=53 in-interface=ether9 action=redirect
protocol=udp dst-port=53 in-interface=ether10 action=redirect


the NAT state table will know the difference between new requests that are getting redirected to self, and the replies to requests that it made to the world. When the local proxy generates an outbound DNS request to some recursive resolver, those packets will not match the dstnat rules because they're not going through an in-interface, thus these rules won't match.

As for firewall filter rules that protect the router from being used as an amplification attack member - use connection state tracking again.
INPUT chain:
protocol=udp dst-port=53 connection-state=new in-interface=WAN1 action=drop
protocol=udp dst-port=53 connection-state=new in-interface=WAN2 action=drop
etc.

If you have multiple routers that do this interception, then you should probably add an address-list containing all interface addresses of all "interceptors" and add this criteria to the redirect rules above:
src-address-list=!interceptors

In other words, don't intercept traffic from other interceptors. Otherwise you could possibly get a ping-pong thing going on and nobody's request ever making it out to the real world. If you also have DNS servers of your own, you should probably add those addresses to the "interceptors" list as well so that the router doesn't interfere with these servers.

If your customers also host DNS servers, you might need to add these servers as well, or else possibly put in some stateful rules in the dstnat chain:
in-interface=wan1 protocol=udp dst-port=53 action=accept
in-interface=wan2 protocol=udp dst-port=53 action=accept
etc

This will cause an un-natted state table entry for incoming new DNS requests from the Internet and the Router will not redirect the replies because the replies will match the state tracking table and not be run through the NAT chains.
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
WirelessRudy
Forum Guru
Forum Guru
Topic Author
Posts: 3089
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: dns cache resolving leaving router through wrong port?

Mon Apr 11, 2016 9:05 pm

There's no OUTPUT chain in the nat table....

In general, you should only need these two rules in the dstnat chain:
protocol=udp dst-port=53 in-interface=ether9 action=redirect
protocol=udp dst-port=53 in-interface=ether10 action=redirect


the NAT state table will know the difference between new requests that are getting redirected to self, and the replies to requests that it made to the world. When the local proxy generates an outbound DNS request to some recursive resolver, those packets will not match the dstnat rules because they're not going through an in-interface, thus these rules won't match.

As for firewall filter rules that protect the router from being used as an amplification attack member - use connection state tracking again.
INPUT chain:
protocol=udp dst-port=53 connection-state=new in-interface=WAN1 action=drop
protocol=udp dst-port=53 connection-state=new in-interface=WAN2 action=drop
etc.
This is all interesting. (The rest is not applicable for us.)

Two more questions; This router is a CCR and actually has several ports that are incoming. Not only the two mentioned but more...
In fact it only has one port as WAN.

So what if your above dst-nat rules would be written as:
protocol=udp dst-port=53 in-interface=!WAN action=redirect
So the rule fits all ports except the outgoing to WAN.

And what about port 53 tcp protocol?
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
WirelessRudy
Forum Guru
Forum Guru
Topic Author
Posts: 3089
Joined: Tue Aug 08, 2006 5:54 pm
Location: Spain

Re: dns cache resolving leaving router through wrong port?

Mon Apr 11, 2016 9:15 pm

Re the firewall we actually have:
chain=input dst-port=53 in-interface=!ether1-WAN300 protocol=tcp action=accept

Is this worse then your proposal;
protocol=udp dst-port=53 connection-state=new in-interface=WAN1 action=drop?
Show your appreciation of this post by giving me Karma! Thanks.

Rudy R. Puister

WISP operator based on MT routerboard & ROS.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: dns cache resolving leaving router through wrong port?

Mon Apr 11, 2016 10:00 pm

Re the firewall we actually have:
chain=input dst-port=53 in-interface=!ether1-WAN300 protocol=tcp action=accept

Is this worse then your proposal;
protocol=udp dst-port=53 connection-state=new in-interface=WAN1 action=drop?
Well, my way explicitly drops an unwanted connection type - it works in either a default-accept firewall or a default-deny firewall. Not knowing your setup, I'm going to give a rule that is going to work in most cases. If you have a default drop policy and want to allow all interfaces but WAN interface in one rule, then that should also work.

You should probably make a rule for TCP and a rule for UDP. (UDP is by far the most commonly used transport for DNS)

Your proposed redirect NAT rule should work fine, and yes, you could do the same for TCP (I've never tested whether Mikrotik's proxy resolver listens on TCP, but if it does, then you can redirect that as well)
When given a spoon,
you should not cling to your fork.
The soup will get cold.
 
User avatar
ZeroByte
Forum Guru
Forum Guru
Posts: 4051
Joined: Wed May 11, 2011 6:08 pm

Re: dns cache resolving leaving router through wrong port?

Mon Apr 11, 2016 10:02 pm

Oh - one more thing - make sure that your redirect rule(s) have src-address-list=!myDnsServers
and list your own DNS servers in the address list myDnsServers - if you have your own on-net resolver. If the router is configured to use public DNS resolvers like 8.8.8.8 (Google) or 4.2.2.2 (Level3) then this won't be necessary.
When given a spoon,
you should not cling to your fork.
The soup will get cold.

Who is online

Users browsing this forum: No registered users and 78 guests