Dear all,
I have a very strange interaction between BIND9 and IPsec which I can't
understand and I hope someone here can shed some light.
An OpenBSD primary DNS server, running BIND9 with a simple named.conf
(single view, etc.) also has an IPsec connection over which a tunnel
runs connecting two RFC1918 networks. Both endpoints run OpenBSD
3.7-stable (CVS updated yesterday), the hardware is also identical (HP
Compaq Proliant DL320):
<192.168.160/24>--[DNS box]--- IPsec ---[other
endpoint]--<192.168.1/24>
X.Y.142.162
X.Y.143.226
the IPsec setup is trivial (from /usr/share/ipsec/vpn simply modifying
the values in the script).
The IPsec tunnel works perfectly but BIND9 occasionally (apparently
when a reload is issued to load a new zone or when an AXFR takes place
from the other nameservers for the zones held) starts routing all
responses to *any* DNS query via the IPsec tunnel.
That is to say that any external query from the routable Internet is
responded to by sending packets down the IPsec link to the other
endpoint where PF rejects the packet.
Any other traffic (traceroute, SSH, ICMP) works perfectly and does not
suffer from this issue.
When blocks start appearing on the endpoint's logs the fix is simple:
on the DNS box "ipsecadm flush" and re-run the VPN script. Obviously
this is not too good for a production system since these sudden "DNS
via IPsec" changes occur at unpredictable times (diagnostic: dig
@nameserver primary.zone.com fails).
The details:
DNS box: OpenBSD 3.7-stable, /usr/src CVS as of Tuesday evening,
BIND9 with trivial modification of named.conf from the OpenBSD
distro simply loading the
master zones and adding a listen-on restriction,
IPsec setup from /usr/share/ipsec/vpn
endpoint: OpenBSD 3.7-stable, /usr/src CVS as of Tuesday evening,
IPsec setup from /usr/share/ipsec/vpn,
PF
Example traffic:
dns-box# traceroute -n 192.168.1.18
traceroute to 192.168.1.18 (192.168.1.18), 64 hops max, 40 byte packets
1 X.Y.143.226 1.214 ms 1.236 ms 1.272 ms
2 192.168.1.18 1.418 ms 1.415 ms 1.420 ms
vpn-endpoint# traceroute -n 192.168.161.162
traceroute to 192.168.161.162 (192.168.161.162), 64 hops max, 40 byte
packets
1 X.Y.142.162 1.315 ms 1.322 ms 1.370 ms
2 192.168.161.162 2.399 ms 1.947 ms 1.961 ms
vpn-endpoint# netstat -rn -f encap
Encap:Source Port Destination Port Proto
SA(Address/Proto/Type/Direction)
X.Y.142.162/32 0 X.Y.143.226/32 0 0
X.Y.142.162/50/require/in
X.Y.142.162/32 0 X.Y.143.226/32 0 50
X.Y.142.162/50/permit/in
X.Y.142.162/32 0 192.168.1/24 0 0
X.Y.142.162/50/require/in
192.168.161/24 0 X.Y.143.226/32 0 0
X.Y.142.162/50/require/in
192.168.161/24 0 192.168.1/24 0 0
X.Y.142.162/50/require/in
X.Y.143.226/32 0 X.Y.142.162/32 0 0
X.Y.142.162/50/require/out
X.Y.143.226/32 0 X.Y.142.162/32 0 50
X.Y.142.162/50/permit/out
X.Y.143.226/32 0 192.168.161/24 0 0
X.Y.142.162/50/require/out
192.168.1/24 0 X.Y.142.162/32 0 0
X.Y.142.162/50/require/out
192.168.1/24 0 192.168.161/24 0 0
X.Y.142.162/50/require/out
the entries for dns-box are symmetrical to the above.
Example snafu from a DNS query to the dns-box:
(on vpn-endpoint)
Oct 19 11:19:44.884586 rule 80/(match) block out on bge0:
X.Y.142.162.53 > 213.207.142.101.3861:
[udp sum ok] 31987*- q: SOA? example.com. 1/5/5 example.com.
SOA dns.example.com. hostmaster.example.com.
[...]
Any suggestions more than welcome,
Thanks,
Arrigo
