pf to redirect local dns traffic to another port

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

pf to redirect local dns traffic to another port

Stéphane Guedon
Hello

I am currently trying to run two nameserver on the same Openbsd
server.

The first one is an autoritative (let's say bind or nsd, no one cares).
the second will be dnsmasq.

You guess the objective of the construction : give local answers from
dhcp leases to local requests, and give autoritatives for the internet
requests.

That's for the presentation.

I can run dnsmasq on a different port, but how do I give my local hosts
the idea of interrogating a non standard dns port ?
Then I though I could drive the traffic from my LAN to the port where
dnsmasq is running on.

so here is pf conf (obviously expurged) :

#######

table <localnet> { local addresses }

# common
pass in log on egress proto { tcp, udp } from any to re0 port domain

# local
pass in quick log on re0 inet proto { udp,tcp } from <localnet>
port domain rdr-to 127.0.0.1 port 5353
#pass in quick log on re0 proto { udp,tcp } from <localnet> port
domain divert-packet port 5353

#######

I first tried to use the divert-packet rule (that way I don't have to
care if the traffic is ipv6 or ipv4), then I tried to redirect using
rdr-to 127... like most tutorials I found regarding rdr.

I move the local rules before or after the common one, place a quick
on the common or removed it...

Nothing : the common rule is always the one that applies according to
the logs.
Can you tell me what I am doing wrong ?

Reply | Threaded
Open this post in threaded view
|

Re: pf to redirect local dns traffic to another port

System Administrator-39
On 29 Mar 2014 at 22:10, Stéphane Guedon wrote:

> Hello
>
> I am currently trying to run two nameserver on the same Openbsd
> server.
>
> The first one is an autoritative (let's say bind or nsd, no one
> cares).
> the second will be dnsmasq.
>
> You guess the objective of the construction : give local answers from
> dhcp leases to local requests, and give autoritatives for the internet
> requests.
>
> That's for the presentation.
>
> I can run dnsmasq on a different port, but how do I give my local
> hosts
> the idea of interrogating a non standard dns port ?
> Then I though I could drive the traffic from my LAN to the port where
> dnsmasq is running on.
>
> so here is pf conf (obviously expurged) :
>
> #######
>
> table <localnet> { local addresses }
>
> # common
> pass in log on egress proto { tcp, udp } from any to re0 port domain
>
> # local
> pass in quick log on re0 inet proto { udp,tcp } from <localnet>
> port domain rdr-to 127.0.0.1 port 5353

unless I'm severly mistaken (and someone will correct me), the rule as
written will match only packets whose SOURCE port is domain ... you are
missing a "to (self)" or "to any" in front of the port specification to
achieve your objective.

> #pass in quick log on re0 proto { udp,tcp } from <localnet> port
> domain divert-packet port 5353
>
> #######
>
> I first tried to use the divert-packet rule (that way I don't have to
> care if the traffic is ipv6 or ipv4), then I tried to redirect using
> rdr-to 127... like most tutorials I found regarding rdr.
>
> I move the local rules before or after the common one, place a quick
> on the common or removed it...
>
> Nothing : the common rule is always the one that applies according to
> the logs.
> Can you tell me what I am doing wrong ?

Reply | Threaded
Open this post in threaded view
|

Re: pf to redirect local dns traffic to another port

Nick Holland
In reply to this post by Stéphane Guedon
On 03/29/14 17:09, Stéphane Guedon wrote:

> Hello
>
> I am currently trying to run two nameserver on the same Openbsd
> server.
>
> The first one is an autoritative (let's say bind or nsd, no one cares).
> the second will be dnsmasq.
>
> You guess the objective of the construction : give local answers from
> dhcp leases to local requests, and give autoritatives for the internet
> requests.

you are getting sloppy with terms here.  You aren't being authoritative
for Internet requests -- you are doing recursive resolution.  You are
authoritative on your internal stuff only.

Also...  for -current, BIND has been replaced by NSD and Unbound, so you
might wish to run -current for this project to minimize changes in the
near future.

> That's for the presentation.
>
> I can run dnsmasq on a different port, but how do I give my local hosts
> the idea of interrogating a non standard dns port ?
> Then I though I could drive the traffic from my LAN to the port where
> dnsmasq is running on.

The easier way is to run your DNS resolver on a different IP Address,
not a different port, than your authoritative DNS.  BIND is something of
an address slut, it connects with every address by default, so you will
have to restrict it in the config to just the ports you want.  I don't
recall what NSD/Unbound do by default, but they are at least
configurable to not be stupid and connect up with just the address you
want them to connect to.

So...run your resolver on the external port, run the authoritative on
localhost, configure the resolver to query the authoritative (on
127.0.0.1) for local info, and the general Internet DNS for everything
else.  Your DHCP server populates your authoritative server, your
machines query the external address, and all Just Works.

And remember: if you wish to get more complicated, you can have lots of
localhosts. (127.0.0.2, 127.0.0.3 ...) and attach different services to
each.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: pf to redirect local dns traffic to another port

Stéphane Guedon
In reply to this post by System Administrator-39
Le samedi 29 mars 2014 17:56:44, vous avez écrit :

> On 29 Mar 2014 at 22:10, Stéphane Guedon wrote:
> > Hello
> >
> > I am currently trying to run two nameserver on the same Openbsd
> > server.
> >
> > The first one is an autoritative (let's say bind or nsd, no one
> > cares).
> > the second will be dnsmasq.
> >
> > You guess the objective of the construction : give local answers
> > from dhcp leases to local requests, and give autoritatives for
> > the internet requests.
> >
> > That's for the presentation.
> >
> > I can run dnsmasq on a different port, but how do I give my local
> > hosts
> > the idea of interrogating a non standard dns port ?
> > Then I though I could drive the traffic from my LAN to the port
> > where dnsmasq is running on.
> >
> > so here is pf conf (obviously expurged) :
> >
> > #######
> >
> > table <localnet> { local addresses }
> >
> > # common
> > pass in log on egress proto { tcp, udp } from any to re0 port
> > domain
> >
> > # local
> > pass in quick log on re0 inet proto { udp,tcp } from
<localnet>
> > port domain rdr-to 127.0.0.1 port 5353
>
> unless I'm severly mistaken (and someone will correct me), the rule
> as written will match only packets whose SOURCE port is domain ...
> you are missing a "to (self)" or "to any" in front of the port
> specification to achieve your objective.

that solved the thing !
thanks !

>
> > #pass in quick log on re0 proto { udp,tcp } from <localnet>
port

> > domain divert-packet port 5353
> >
> > #######
> >
> > I first tried to use the divert-packet rule (that way I don't have
> > to care if the traffic is ipv6 or ipv4), then I tried to redirect
> > using rdr-to 127... like most tutorials I found regarding rdr.
> >
> > I move the local rules before or after the common one, place a
> > quick on the common or removed it...
> >
> > Nothing : the common rule is always the one that applies according
> > to the logs.
> > Can you tell me what I am doing wrong ?

Reply | Threaded
Open this post in threaded view
|

Re: pf to redirect local dns traffic to another port

Stéphane Guedon
In reply to this post by Nick Holland
Le samedi 29 mars 2014, 23:55:07 Nick Holland a écrit :

> On 03/29/14 17:09, Stéphane Guedon wrote:
> > Hello
> >
> > I am currently trying to run two nameserver on the same Openbsd
> > server.
> >
> > The first one is an autoritative (let's say bind or nsd, no one
> > cares). the second will be dnsmasq.
> >
> > You guess the objective of the construction : give local answers
> > from dhcp leases to local requests, and give autoritatives for
> > the internet requests.
>
> you are getting sloppy with terms here.  You aren't being
> authoritative for Internet requests -- you are doing recursive
> resolution.  You are authoritative on your internal stuff only.

As I speak of my own domain, I think the word autoritative is really
correct there

> Also...  for -current, BIND has been replaced by NSD and Unbound, so
> you might wish to run -current for this project to minimize changes
> in the near future.

That was one of the purpose of this construction : stopping Bind, as
its view function is now replaced by this two-sides dns

> > That's for the presentation.
> >
> > I can run dnsmasq on a different port, but how do I give my local
> > hosts the idea of interrogating a non standard dns port ?
> > Then I though I could drive the traffic from my LAN to the port
> > where dnsmasq is running on.
>
> The easier way is to run your DNS resolver on a different IP
> Address, not a different port, than your authoritative DNS.  BIND
> is something of an address slut, it connects with every address by
> default, so you will have to restrict it in the config to just the
> ports you want.  I don't recall what NSD/Unbound do by default, but
> they are at least configurable to not be stupid and connect up with
> just the address you want them to connect to.

That was what I did first. But Dnsmasq doesn't like it, it doesn't send
RA if I restrict adress.

>
> So...run your resolver on the external port, run the authoritative
> on localhost, configure the resolver to query the authoritative (on
> 127.0.0.1) for local info, and the general Internet DNS for
> everything else.  Your DHCP server populates your authoritative
> server, your machines query the external address, and all Just
> Works.
>
> And remember: if you wish to get more complicated, you can have lots
> of localhosts. (127.0.0.2, 127.0.0.3 ...) and attach different
> services to each.
>
> Nick.

Anyway, now it's solved !
I think of writing a blog / tutorial article to document it correctly
to the world.