I have a firewall/router which runs unbound(8) to provide a caching
DNS service to local machines. This mostly works ok, but the local
machines are seeing intermittent failures to open new TCP connections.
I speculate that this problem may be due to DNS failures caused my
having mis-configured resolv.conf(5) and/or unbound(8) on the firewall.
Before I break out tcpdump, can anyone point out any problem with my
configuration?
The firewall is a PC Engines Alix board running 6.5-stable/i386.
The wired client is a laptop running 6.5-stable/amd64; both this and
the firewall have had the 2019-06-10 libssl patch applied. The wifi
clients are laptops running a mixture of Windows 7 and Windows 10.
The wired and wifi clients both see the same sort of intermittent
failures, signalled by (e.g.) a web browser reporting that it's unable
to resolve a hostname, or Thunderbird (on a Windows client) reporting
that it's unable to save a message to its sent-mail folder.
The failures tend to cluster in time, i.e., immediately after a failure
there's a much-larger-than-usual chance that retrying the same command
will fail again. Eventually (after enough retrying) the connection
always succeeds. I speculate that I might be seeing a race condition
on the firewall between its unbound(8) and whatever the ISP router/gateway
is doing?
The network topology is this:
internet
|
|
+---------+ +------------------+
| | | | +--------+ ) ) wifi
| ISP | | | | wifi | ) ) clients
| gateway |----------|vr0 firewall vr2|---------| access |
| /router | | | | point |
| | | vr1 | +--------+
+---------+ +------------------+
|
|
wired client
The firewall has 3 (ethernet) interfaces, vr0, vr1, and vr2.
vr0 is connected to the ISP gateway/router; vr1 to the wired client,
and vr2 to a wifi access point for the wifi clients.
On the firewall, vr0 gets a dhcp IP address from the ISP gateway/router,
while vr1 and vr2 have static IP addresses. The firewall runs dhcpd on
vr1 and vr2 to assign dynamic IP addresses to the clients.
The firewall uses pf for access control and to NAT internal addresses
to the outside world:
--- begin firewall /etc/pf.conf ---
# our interfaces
if_outside = "vr0"
if_wired = "vr1"
if_wifi = "vr2"
if_inside = "{" $if_wired $if_wifi "}"
if_all = "{" $if_wired $if_wifi $if_outside "}"
# subnets
addr_wired = "192.168.105.0/26" # .0 to .63
addr_wifi = "192.168.105.64/26" # .64 to .127
# all internal addresses
addr_internal = "192.168.105.0/24"
################################################################################
set skip on lo0
antispoof quick for $if_all
block all
# allow outgoing connections from any internal address, NAT these
pass in on $if_wired from $addr_wired
pass in on $if_wifi from $addr_wifi
pass out on $if_outside from { $addr_internal ($if_outside) } \
nat-to ($if_outside) modulate state
# allow incoming connections to our ssh ONLY from wired network
block in on !$if_wired proto {tcp,udp} to port ssh
--- end firewall /etc/pf.conf ---
The firewall runs unbound(8) (started from /etc/rc.conf.local). Right
now unbound is *not* doing DNSSEC validation (that's still on the TODO
list for the future). The ISP gateway/router always gives out the same
DNS address, so for simplicity I've just hardwired that in the firewall's
/var/unbound/etc/unbound.conf . On the firewall, unbound-checkconf(8)
reports nothing wrong.
--- begin firewall /etc/resolv.conf ---
# Generated by vr0 dhclient
search Home
nameserver 127.0.0.1
nameserver 192.168.1.254
--- end firewall /etc/resolv.conf ---
--- begin firewall /var/unbound/etc/unbound.conf ---
# $OpenBSD: unbound.conf,v 1.14 2018/12/16 20:41:30 tim Exp $
server:
interface: 192.168.105.62 # wired network vr1
interface: 192.168.105.126 # wifi network vr2
do-ip6: no
access-control: 0.0.0.0/0 refuse
access-control: 127.0.0.1 allow
access-control: 192.168.105.0/26 allow
access-control: 192.168.105.64/26 allow
hide-identity: yes
hide-version: yes
# Uncomment to enable DNSSEC validation.
#
#auto-trust-anchor-file: "/var/unbound/db/root.key"
#val-log-level: 2
# Uncomment to synthesize NXDOMAINs from DNSSEC NSEC chains
# https://tools.ietf.org/html/rfc8198
#
#aggressive-nsec: yes
# UDP EDNS reassembly buffer advertised to peers. Default 4096.
# May need lowering on broken networks with fragmentation/MTU issues,
# particularly if validating DNSSEC.
#
#edns-buffer-size: 1480
# Use TCP for "forward-zone" requests. Useful if you are making
# DNS requests over an SSH port forwarding.
#
#tcp-upstream: yes
forward-zone:
name: "."
forward-addr: 192.168.1.254
--- end firewall /var/unbound/etc/unbound.conf ---
Can anyone point out any problem with this configuration? Is it appropriate
for the firewall's /etc/resolv.conf to list both 127.0.0.1 and the upstream
ISP router/firewall's DNS address?
thanks, ciao,
--
-- "Jonathan Thornburg [remove -animal to reply]"
<jth...@astro.indiana-zebra.edu>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
currently on the west coast of Canada
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
