Messages

I was having a problem with unbound DNS in resolver mode on OPNsense today where no clients could resolve DNS, but the router itself could. As soon as I changed unbound's mode to "DNS Query Forwarding" everything started working!? OPNsense was behind a clients corporate network and I don't know what their stuff was up to since in the shop and most other places the router has been everything works fine. I'm just trying to unpack the possible cause and see if what I did was the correct solution.

The other odd thing was even if I configured a DNS server locally on a client, eg 8.8.8.8, DNS resolution would still not work. Though I did not try using the DNS servers handed to OPNsense via DHCP.

What does this mean? On the GET api calls with this in the parameter column I keep getting 200 back, but empty braces. The other calls that don't have this work fine. I'm specifically using it with ZT network api on OPNsense (/api/zerotier/network/info), but I imagine this has a wider reach than just that. I've tried using $uuid=null, uuid=null, $uuid=(acutal uuid for zt net here), and uuid=(acutal uuid for zt net here). Not to mention I don't know what the $ is all about either. Yes, I know JUST enough to get myself into trouble so if you would like to tell me off right now I would understand. I just haven't been able to find anything coherent on the subject so I ask as a last resort. Thank you for your patience.

I was able to finally fix this, it took reinstalling opnsense from scratch with no import. Somehow if you start messing around with the firewall for testing it permanently changes something and you cannot go back without wiping the HD and starting fresh, at least that's what my experience has been with the first two machines I've setup so far.

I was doing some configuring on the firewall regarding my last post and found no matter how I set rules on the firewall LAN packets were being reported as blocked under "default deny rule" regardless of how much I opened the rules up on one machine. I have another firewall with the same setup (HW and SW) that doesn't report issues like this one. Out of frustration and troubleshooting sake I did a factory reset on the problem machine and spun up a completely new vanilla install with only 1 client (v19.7.8) in which looking at the logs looked normal, then I changed the LAN source on the LAN rules from "LAN net" to "any" for both rules, applied the changes, and LAN packets started to be reported as blocked on a fairly regular basis. I did a factory reset, checked logs and found reports returned to normal. I then reset states and encountered the same phenomena. During all this I didn't notice any obvious failure of connectivity on the client side, but it is troubling since I was using the log data to get connectivity issues ironed out on the other machine. What could I be missing, or is this normal? Thanks!

looks like socket is already in listen

netstat -an|grep 192.168.202.1

The ZT interface (assigned from ZT central) had the same IP as LAN, I changed the IP in ZT, rebooted, and mDNS repeater it fired right up. Thank you!

Hi all! New here to OPNsense and getting one of my routers up and running. I'm running 19.7.8 and have two ports in a LAN bridge while routing through a zerotier interface for remote sites and management access. For some reason the service won't start and regardless of which interfaces I select this is what I get in the general log:

Dec 26 10:44:58   mdns-repeater[96625]: exit.
Dec 26 10:44:58   mdns-repeater[96625]: unable to create socket for interface zt3tuismu5fivh4
Dec 26 10:44:58   mdns-repeater[96625]: recv setsockopt(IP_ADD_MEMBERSHIP): Address already in use
Dec 26 10:44:58   mdns-repeater[96625]: send bind(): Address already in use
Dec 26 10:44:58   mdns-repeater[96625]: dev bridge0 addr 192.168.202.1 mask 255.255.255.0 net 192.168.202.0

Zt3xxxxx.... is the zerotier interface and bridge0 is the LAN bridge. For some reason this doesn't change even if I change what interfaces are used in mDNS repeater. Any ideas of where to look next to figure this out? Thanks,

Andy