Messages

1

22.7 Legacy Series / DNS not working - can't resolve domain names behind opnsense

« on: September 06, 2022, 07:25:08 pm »

this install hasn't been running long, and after a recent power failure, dns simply refuses to work
key points are as such, i understand ping is different to dns but just bear with me...

i am using latest opnsense
i am using ADGUARD dns filter for the dns server
the network is a dual NAT setup, with OPNSENSE as gateway for the devices in this room, and the ISP router "outside" this network serving as another gateway, traffic is DMZ'd through to OPNSENSE for hosting etc, it's a bit funky but it's been working great for the past decade or so and preserves the standard ISP wifi network for friends/family as they find my filtering excessive - but i digress;

ADGUARD: 192.168.2.241
OPNSENSE: 192.168.2.254
PC: 192.168.2.38
WAN: 192.168.0.30

adguard can ping 8.8.8.8
opnsense can ping 8.8.8.8
proxmox can ping 8.8.8.8
dns is set to 8.8.8.8 in proxmox dns section
adguard upstream dns is set to 8.8.8.8 (and a few others)
PC gateway is set to opnsense
PC dns is set to adguard
dhcp is turned off on the router (no conflict)
all DNS servers/forwarding is turned OFF in opnsense

yet nothing can resolve any hostname...

using DIG command from ADGUARD:

Code: [Select]

adguard:~# dig @8.8.8.8 google.com

; <<>> DiG 9.16.15-Debian <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
using PING command from ADGUARD:

Code: [Select]

adguard:~# ping google.com
ping: google.com: Temporary failure in name resolution
if i set PC dns server to 8.8.8.8 directly, it works (And is how i can post this thread) but nothing else on the server is functioning
but setting this directly in the proxmox host etc seems to do nothing, i'm unsure what the problem is...

using tracert command from PC with 8.8.8.8 set directly:

Code: [Select]

tracert google.com

Tracing route to google.com [142.250.178.14]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.2.254
  2     2 ms     2 ms     3 ms  192.168.0.1
  3    13 ms    10 ms     8 ms  10.112.32.117
  4    11 ms    12 ms    10 ms  wolv-core-2a-xe-0017-0.network.virginmedia.net [80.3.145.73]
  5     *        *        *     Request timed out.
  6    21 ms    20 ms    18 ms  tcl5-ic-4-ae5-0.network.virginmedia.net [62.252.192.246]
  7    19 ms    21 ms    20 ms  host-62-252-5.117.not-set-yet.virginmedia.net.5.252.62.in-addr.arpa [62.252.5.117]
  8    18 ms    20 ms    17 ms  216.239.49.185
  9    18 ms    19 ms    16 ms  142.250.215.125
 10    20 ms    18 ms    15 ms  lhr48s27-in-f14.1e100.net [142.250.178.14]

Trace complete.
using traceroute from ADGUARD:

Code: [Select]

adguard:~# traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.2.254 (192.168.2.254)  0.336 ms  0.297 ms  0.264 ms
 2  192.168.0.1 (192.168.0.1)  2.486 ms  3.055 ms  3.387 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
using IP route show on ADGUARD

Code: [Select]

adguard:~# ip route show
default via 192.168.2.254 dev eth0 onlink
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.241

opnsense interface overview (LAN):

Code: [Select]

Status up
MAC address ba:01:25:4a:a0:71
MTU 1500
IPv4 address 192.168.2.254/24
IPv4 gateway 192.168.2.254
Media 10Gbase-T <full-duplex>
In/out packets 700615 / 2247726 (387.00 MB / 2.59 GB)
In/out packets (pass) 695789 / 2247726 (386.74 MB / 2.59 GB)
In/out packets (block) 271254 / 0 (5 KB / 0 bytes)
In/out errors 0 / 0
Collisions 0

opnsense interface overview (WAN)

Code: [Select]

Status up
DHCP
up   
MAC address e2:d6:90:93:e4:b8
MTU 1500
IPv4 address 192.168.0.30/24
IPv4 gateway 192.168.0.1
IPv6 link-local fe80::e0d6:90ff:fe93:e4b8/64
DNS servers 194.168.4.100
194.168.8.100
8.8.8.8
8.8.4.4
Media 10Gbase-T <full-duplex>
In/out packets 2178354 / 677061 (2.54 GB / 382.25 MB)
In/out packets (pass) 2172327 / 677056 (2.54 GB / 382.25 MB)
In/out packets (block) 2664361 / 5 (6 KB / 369 bytes)
In/out errors 0 / 0
Collisions 0
using DIG command direct to 8.8.8.8 from PROXMOX:

Code: [Select]

bugz000:~# dig @8.8.8.8 google.com

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> @8.8.8.8 google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

using ping from another proxmox container to ADGUARD

Code: [Select]

httpd:~# ping 192.168.2.241
PING 192.168.2.241 (192.168.2.241) 56(84) bytes of data.
64 bytes from 192.168.2.241: icmp_seq=1 ttl=64 time=0.192 ms
64 bytes from 192.168.2.241: icmp_seq=2 ttl=64 time=0.074 ms
64 bytes from 192.168.2.241: icmp_seq=3 ttl=64 time=0.061 ms
64 bytes from 192.168.2.241: icmp_seq=4 ttl=64 time=0.062 ms
64 bytes from 192.168.2.241: icmp_seq=5 ttl=64 time=0.060 ms
64 bytes from 192.168.2.241: icmp_seq=6 ttl=64 time=0.039 ms
64 bytes from 192.168.2.241: icmp_seq=7 ttl=64 time=0.064 ms
64 bytes from 192.168.2.241: icmp_seq=8 ttl=64 time=0.070 ms
64 bytes from 192.168.2.241: icmp_seq=9 ttl=64 time=0.081 ms
64 bytes from 192.168.2.241: icmp_seq=10 ttl=64 time=0.062 ms
64 bytes from 192.168.2.241: icmp_seq=11 ttl=64 time=0.069 ms
64 bytes from 192.168.2.241: icmp_seq=12 ttl=64 time=0.077 ms

















i am almost certain i am lacking needed information to fix this issue, so please direct me to what information you need and i'll get it for you

standing by for replies as i'm out of ideas at this point - my gut feeling tells me something in the opnsense config is blocking dns which is why i'm posting here
this is because ADGUARD has been running for upwards of 6 months, and has existed much longer, it has "survived" several reboots and power failures... and this opnsense container is quite a new addition never being subject to a power failure until now - i used opnsense in the past but incredibly slow NAT speeds caused me to move back to openwrt - but it seems the fault has been fixed and i can get full line speed with suricata and crowdsec which is fantastic, but only after a power failure has this new fault appeared

thankyou all in advance <3