OPNsense Forum
Archive => 16.1 Legacy Series => Topic started by: GLR on May 31, 2016, 10:50:04 pm
-
Hello all,
I have a setup with a pfSense instance forwarding (with dnsmasq) to two external Unbound resolvers and two external nsd local authoritative NS.
I am trying to move it to an OPNsense instance embedding the name resolution feature with Unbound.
In the past I abandoned the option to use Unbound embedded in pfSense due to limitations.
I am now rechallenging the issue with OPNsense.
It is working partially but I am still facing a problem with the reverse zones locally hosted: they are not forwarded to the local authoritative NS hosting them.
In the file unbound.conf generated by OPNsense, they are defined as stub zones, private-domain and domain-insecure.
In my original working configuration (running in a Linux instance), they are simply defined as stub and local-zones.
The forward internal zone (glrnet) is however correctly resolved.
See the configuration files in the attachments.
Also, I tried to add the local-zones statements to the advanced custom field, but then Unbound fails to restart. It seems the syntax is not good as each space is turned to a carriage return.
Can you help me ?
; <<>> DiG 9.8.1-P1 <<>> opnsense1.glrnet @192.168.1.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59323
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;opnsense1.glrnet. IN A
;; ANSWER SECTION:
opnsense1.glrnet. 7191 IN A 192.168.1.253
;; AUTHORITY SECTION:
glrnet. 86391 IN NS ns.glrnet.
glrnet. 86391 IN NS syno.glrnet.
;; ADDITIONAL SECTION:
ns.glrnet. 86391 IN A 172.16.0.3
syno.glrnet. 7191 IN A 192.168.0.251
;; Query time: 0 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue May 31 22:46:58 2016
;; MSG SIZE rcvd: 118
; <<>> DiG 9.8.1-P1 <<>> -x 192.168.1.253 @192.168.1.253
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 3644
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;253.1.168.192.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
168.192.in-addr.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200 604800 10800
;; Query time: 15 msec
;; SERVER: 192.168.1.253#53(192.168.1.253)
;; WHEN: Tue May 31 22:47:10 2016
;; MSG SIZE rcvd: 103
-
So, to sum-up, it seems the main problem is that the advanced settings don't work because the spaces (and tabulations) are turned to carriage returns.
In the "Advanced" web configuration:
local-zone: "168.192.in-addr.arpa" nodefault
local-zone: "16.172.in-addr.arpa" nodefault
statistics-interval: 300
statistics-cumulative: no
extended-statistics: yes
In /var/unbound/unbound.conf:
# Unbound custom option
local-zone:
"168.192.in-addr.arpa"
nodefault
local-zone:
"16.172.in-addr.arpa"
nodefault
statistics-interval:
300
statistics-cumulative:
no
extended-statistics:
yes
What of course induces the following Unbound error:
opnsense: /services_unbound.php: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '/var/unbound/unbound.conf:115: error: syntax error read /var/unbound/unbound.conf failed: 1 errors in configuration file [1465244973] unbound[47952:0] fatal error: Could not read config file: /var/unbound/unbound.conf'
Can this please be fixed ?
-
I've just tried to implement the same configuration in pfSense and surprisingly it now works fine, probably because an option "System Domain Local Zone Type" was added in the General settings.
-
pfSense configuration with native local-zone statement.
-
Hi there,
This should fix embedding of custom options (opnsense-patch works from 16.1.16 onwards):
# opnsense-patch acbd63db3
Cheers,
Franco
-
Thanks, it works fine !
Added in the custom options:
server:
local-zone: "168.192.in-addr.arpa" transparent
local-zone: "16.172.in-addr.arpa" transparent
Got in the config file:
# Unbound custom options
server:
local-zone: "168.192.in-addr.arpa" transparent
local-zone: "16.172.in-addr.arpa" transparent
What fixes my problem.
I think you should also think at adding the local-zone statement and setting natively as done in pfSense...
Thanks a lot anyway.