Messages

1

20.7 Legacy Series / Insight into strange network disruption?

« on: February 05, 2021, 05:14:04 pm »

I know that there probably isn't a lot that can be said based on the lack of details, but I had a strange occurrence that I wanted to see if anyone had any ideas about so I can get a sense of direction for if this happens again. Let me know if there's logs or other information I can provide.

The other night I was using the internet on my phone and suddenly couldn't load a page. I immediately logged into the web server and saw the CPU usage as much higher than usual, not quite pinned but near max load when usually it struggles to ever pass 40%. At the same time, the State Table which rarely gets to 1%, while I've been watching it at least, quickly rose in usage over about 30 seconds until it hit 100% and then Unbound stopped (I'm assuring crashed) and then the page table emptied.

I had to hard reboot the machine to restore internet access.

I almost wonder if there's a slight chance I was a victim of the recent Plex DDoS amplification attacks that have cropped up as a I do run a server, but that is more likely just a coincidence.

2

General Discussion / Re: Forced DNS Redirect to PiHole Doesn't Return to Client

« on: December 29, 2020, 05:43:08 pm »

Unfortunately no, though I haven't tried anything else since my last post.

Hopefully stesoell isn't out of ideas, but regardless I do have a few things I'm going to try despite being doubtful that they'll change the situation. I will post back if I figure out anything.

3

General Discussion / Re: Forced DNS Redirect to PiHole Doesn't Return to Client

« on: December 24, 2020, 01:55:43 pm »

Interesting,

With both my old rules removed and only yours in place, the setup still behaves the same, but I now see it appears to be "working", just in a way that is non-compliant or that the network clients don't like and see as invalid.

On Windows:

Code: [Select]

shell>nslookup google.com 1.1.1.1
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  1.1.1.1

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out
Same as before. To see if I can get more info, I try on my Kubuntu machine.

On Linux:

Code: [Select]

shell:~$ nslookup google.com 1.1.1.1
;; reply from unexpected source: 192.168.1.5#53, expected 1.1.1.1#53

;; reply from unexpected source: 192.168.1.5#53, expected 1.1.1.1#53

;; reply from unexpected source: 192.168.1.5#53, expected 1.1.1.1#53

;; connection timed out; no servers could be reached

So it does seem that clients do get the reply, but are ignoring them because of the source discrepancy? It this perhaps because of use of DNSSEC on both OPNsense (unbound) and PiHole?

Otherwise I have no clue. Not experienced enough with custom DNS servers/setups to know what the issue could be. As we know the redirect is intentional and obviously it works on your setup and is possible to do it in general.

I'll mention that OPNsense is running in a VM on an ESXI server, but I doubt that is affected this and everything else works fine.

4

General Discussion / Re: Forced DNS Redirect to PiHole Doesn't Return to Client

« on: December 23, 2020, 07:03:02 pm »

Hej, check this settings ...

Firewall->NAT->Port Forward: Rule
Interface: LAN
TCP/IP Version: IPv4
Protocol: TCP/UDP
Source/Invert: unchecked
Source: any
Source Port Range: from: any, to: any
Destination/Invert: Checked
Destination: LAN address
Destination Port Range: from: DNS, to: DNS
Redirect Target IP: Single host or Network -> 192.168.1.5
Redirect Target Port: DNS
NAT Reflection: disable

Hi,

Just to clarify, am I supposed to change my existing port forward rule to this (I'd imagine so)? Or add this in addition?

Either way do I also leave the outbound rule alone?

Changing my existing port forward entry to match this one still results in the request hitting the PiHole but timing out on the client

5

General Discussion / Forced DNS Redirect to PiHole Doesn't Return to Client

« on: December 22, 2020, 10:17:41 pm »

Hi,

Just got started with OPNSense and have everything up and working, but I'm quite unfamiliar when it comes to setting up more advance configurations that were not possible on standard consumer routers, so I apologize for leeching so soon.

OPNSense acts as my full router on 192.168.1.1 with a fairly standard setup (IPv4 DHCP, some port forwards, Static IP/MAC Reservation) with the only feature I've really leveraged so far that I couldn't before being UnboundDNS' ability to have hostnames for local clients.

I also have a PiHole on my network that I want handling ALL DNS requests, which I mention because I have several of those notorious devices on my network with hardcoded DNS servers that ignore what they're sent through DHCP. In order to make this happen, I know I need to setup my configuration so that all packets on the network that are trying to travel externally through port 53 need to be redirected to my PiHole.

My current setup is that all clients are given the IP of my PiHole through DHCP and the PiHole itself is told to use the OPNSense router as its upstream DNS so that I can still make use of Unbound's hostname feature (and potentially more in the future), which then finally uses Cloudflare's DNS server to do the final lookup. This all works correctly and allows me to see each unique client in PiHole instead of it all appearing as coming from the router if I did it the other way around, which I'd prefer not to change.

The issue is that I cannot fully get the forced redirect to the PiHole working (it seems really close) for the clients that ignore DHCP.

I followed the advice here: https://forum.opnsense.org/index.php?topic=15472.0 to setup a port forwarding rule, and an outbound rule, which lead to this overall setup-

OPNSEnse Router: 192.168.1.1
PiHole: 192.168.1.5
DNS Pathing: Client -> PiHole -> OPNSense (Router) -> Internet (Cloudflare)

System->Settings->General
DNS servers: 1.1.1.1 + 1.0.0.1 + Empty...

Services->DHCPv4->[LAN]
DNS servers: 192.168.1.5 + Empty

Firewall->NAT->Port Forward: Rule
Interface: LAN
TCP/IP Version: IPv4
Protocol: TCP/UDP
Source/Invert: Checked
Source: Single host or Network -> 192.168.1.5/32
Source Port Range: from: any, to: any
Destination/Invert: Checked
Destination: LAN address
Destination Port Range: from: DNS, to: DNS
Redirect Target IP: Single host or Network -> 192.168.1.5
Redirect Target Port: DNS
NAT Reflection: Disable

Firewall->NAT->Outbound:
Mode: Hybrid outbound NAT rule generation
Rule
Interface: LAN
TCP/IP Version: IPv4
Protocol: any
Source Invert: Checked
Source address: Single host or Network -> 192.168.1.5/32
Source port: DNS
Destination address: Single host or Network -> 192.168.1.5/32
Destination port: DNS
Translation/target: Interface address

This has resulted in a near functional setup. Devices that obey the DHCP given servers work correctly and you can see their requests in the PiHole interface, such as when doing "nslookup google.com"; however, for devices that try to circumvent the DHCP given address, their requests only make it out, but not back in. For example, when doing "nslookup google.com 8.8.8.8" an entry for the client and that request do appear in PiHole and it shows the request successfully being redirected to the OPNSense router, but on the client the request times out, so clearly the return path is being disrupted.

I think this is because the rules suggested in the thread I linked didn't account for the third step in the chain being the router itself given the use of unbound and so the existing rules are preventing the DNS query result from returning to the client, perhaps just sending it off to the PiHole again. I'm not sure if in my current setup when not redirected if the results go back through the PiHole and then to the client, or just straight from the router to the client (not 100% sure how that works networking wise), but if it was the latter and the result gets redirected to the PiHole since the rule doesn't have the router itself as an exception (i.e. !192.168.1.5 && !192.168.1.1) then it would make sense why it isn't working.

Either way, while I get what is going on here in general and the port forward make sense to me, I don't entirely get the function of the Outbound rule (perhaps one handles the outbound request and the other handles the return result? Again not sure) and overall I'm not sure what I need to change to make this function correctly all the way through.

Right now I'm simply blocking the DNS servers that I know the devices are hardcoded to, but this isn't a dynamic solution and on some of them causes significantly slowdown as they wait a while before trying the DHCP given address, so this is really just a stopgap solution.

Anyone know how to fix that last step (or piece of the pie )?

Thanks