Messages

You have to be on 25.7 for all dnsmasq option as the release was finished in it.

Woops, mistook the version I thought this machine was on for another machine.

I see the field now.

If the switch does the inter VLAN routing, the switch also needs to provide a DHCP relay. Check the vendor documention.

Sorry if I wasn't clear, it indeed does. GWN7822P from Grantstream. Has a DHCP server and relay option. I just wanted to make sure that Dnsmasq could handles ranges outside of the interface its on, like Kea can.

Yeah dnsmasq can do it the exact setup was tested and confirmed here:

https://github.com/opnsense/core/issues/8924

Thanks, that's awesome that this exact setup was already documented as working, though, do you know explicitly where and in what format I am to include the subnet mask in this dialogue, since it only has fields for start and end (perhaps after a comma in the end field)?



It seems that it's recommended to also pass the netmask via option 1 so that it's also cleanly communicated to clients, but the core functionality of this setup requires it in the range.

Additionally, I'm assuming that OPNsense's "Set" type is what I want to use to do the same as

Code Select Expand

dhcp-option=tag:my_tag_for_some_vlan,3,192.168.1.1 to set the gateway provided to the requests that match that tag, for example?

Sorry if I'm not using the right terminology as I'm new to this use case.

I want to setup a new L3 switch to handle all VLANs, including routing between them, instead of defining the interfaces on the firewall and having it do the routing less efficiently; however, I'd prefer to keep DHCP on the firewall and of course the switch supports a DHCP relay.

As mentioned in this post, I should just be able to make a transfer network to form a point-to-point connection between the switch and OPNsense (by specifying routes on both sides), which would be the only interface in OPNsense. The issue at the time of the post was that ISC is apparently unable to handle DHCP requests for subnets for which the firewall does not have an interface on (like in this case), but Kea (which now is available) should be able to do this, presumably via it's pools and the system's static routes defined in System->Routes.

My question though is, is OPNSense's implementation of the DHCP portion of Dnsmasq capable of this scenario as well? I didn't realize that had also been added as an option until I went to start migrated to Kea. I'd prefer to use the "primary"/default DHCP server since it's more likely to maintain support if the maintainers decide to drop one, but since I'm not experienced with this use case, it's unclear to me if Dnsmasq will be able to handle requests from DHCP relays like this.

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.

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.

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 Expand

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 Expand


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.

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 :(

[OPNSEnse Router:]

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 ;D)?

Thanks