Messages

Advantage of this setup is I can see which requests are coming from which device ip's on the local network. Disadvantage of this setup is for now I've lost the DoH/DoT/DoQ that is configured out of the box on AdGuard Home and not replicated on Unbound by default.

https://sahlitech.com/opnsense-setup-unbound-dns/

This Unbound DNS guide is pretty good and was recently modified to include 'tls-cert-bundle' that properly checks for valid certificates.  The problem I have is Unbound can be kind of buggy and unreliable.  I have resorted to enabling a PiHole as a DNS backup, with Cloudflared DoH. If you start having issues with Unbound, you might want to bypass it.

deleted

Thank will try you suggestion and remove the outbound NAT rule. The reason for the Outbound NAT rule was to enforce use of AdGuard + my choise of outbound DNS rather than permit use of other DNS providers (for example hardlinked DNS servers inside of IoT devices, i've seen alot of requests for 8.8.8.8 from devices).

DHCP address are handed out by OPNsense and AdGuard gets handed a fixed IP based.

I think you meant remove the Port Forward WAN rule.  Outbound NAT should still have a rule (likely Automatic).

That makes sense; you're doing a DNS redirect.  I would disable it and get it working on a PC then work on your redirect.

wrt addresses, your WAN interface address should not be in the address space of your LANs.  OPNSense lets you do this and it causes routing problems. (It happens often if AdGuard issues a 192.168.1.0/24 address and one of your LANs also uses this range.)

That NAT port forward rule seems strange.  I think you might try disabling it and make sure your Outbound NAT rules are set to Automatic.  Using defaults, OPNSense should hand out the DNS address given by AdGuard to the clients.  You don't need a port forward rule because OPNSense will route return traffic to the host requesting DNS.

I assume AdGuard is providing an address over DHCP to OPNSense.  I assume that address is private.  If it is, make sure you're not blocking private addresses at the WAN level. Also, make sure that it does not interfere with the address space of your LANs.

You can put your SPAMHAUS Drop rules only once in Floating so you don't have to replicate them on every interface.

No because I did a complete reinstall of OPNSense. 

I tried many things including a reset to factory defaults.  I wonder if between netmap and my hardware, there is a bug. I was beginning to wonder if I actually had a hardware failure, but the full reinstall fixed it.  I am hesitant to try it out again. 

Update: I found this.

https://bugzilla.redhat.com/show_bug.cgi?id=626427

This seems like the same problem, ten years earlier. Fortunately, it appears that dhclient reverts back to broadcasts in the native interface so it doesn't cause a connection problem.

I asked because I enabled IPS one time and I started having routing issues. I could never fix it even with a reset. I finally reflashed the OS and started clean. It worked. That's the nuclear option if all else fails. I think mine was a netmap issue.

Another question: Have you ever enabled Intrusion Prevention?

Could be a certificate issue and not a firewall rule.

I have looked these over, and everything seems right.

My only guess is that it's a problem with some static gateway assignment on 192.168.21.10.  If the source that was pinging is outside the subnet, then it will route replies to the locally assigned gateway. (This is generally assigned through DHCP but can be overridden.)

I think you'll might need to use Wireshark or tcpdump on the interface that is being pinged to see the traffic to/from the interface. You can detect which path is failing and trace out the problem, but I would check the gateway on 192.168.21.10 first.

This is a sort of a complicated setup, so I don't know what all is happening here. Without knowledge of this overall configuration, it's difficult for someone in the forum to diagnose.

You're passing private addresses from your WAN.  Packets incoming on WAN are typically destined to a public address, like the WAN address itself.  Since your interface is WAN, and the destinations are private, then these packets couldn't route through the internet.  (Unless you're behind another NAT server or something.)

I think you need to use a NAT Port Forward configuration to pass traffic destined for the public IP to your mail server.  Your WAN rules must allow traffic to the WAN interface address, not a private space address. 

Workaround: I applied a static route for the 172.19 address range to the WAN.  With that, success:

2021-04-27T20:37:26   dhclient[77590]   bound to [redacted] -- renewal in 43200 seconds.   
2021-04-27T20:37:26   dhclient[78460]   Creating resolv.conf   
2021-04-27T20:37:26   dhclient[77590]   DHCPACK from 172.19.57.123   
2021-04-27T20:37:26   dhclient[77590]   DHCPREQUEST on igb0 to 172.19.57.123 port 67

I need to know if this is a bug, or am I doing something wrong.

In short, the DHCP client is routing DHCP requests for the WAN interface over the gateway group and not the WAN.

Please advise.

It helps to get a screenshot of the rule entry pages if possible.

Can you ping the host on the same subnet?

What is in the Gateway field on the pass rules? 

Yes it is Cox.

I did find this in the filter log:

2021-04-27T19:34:55   filterlog[14428]   105,,,0,ovpnc2,match,pass,out,4,0x10,,128,32852,0,none,17,udp,328,10.18.0.3,172.19.57.123,1528,67,308

It looks like it is passing through the VPN client and not to the WAN interface.  I wonder why I am not having address/connectivity issues.  (10.18.0.3 is the VPN issued IP)

Is this a bug?

I'm not familiar with 1:1, but I'll try:

User, Settings, Admin -> Try setting the OPNSense interface to not listen on WAN.