Messages

It seems I was right, with Wireshark I can see that the DNS returns several addresses and the browser attempts to access them one by one until one works and displays the login page - herein the long delay. Is there a way to instruct Opnsense to send the specific IP address of the router that is in the same VLAN as the request?

I am using version 25.7, but I have had this (likely misconfiguration) problem in older versions.

The main issue is that when I access the router GUI by name from Chrome (https://router.domain) it either times out or takes a very long time to respond (~20-30 secs). However, if I use the IP directly, Opnsense GUI loads immediately. This only happens from the Web browser, from curl it always loads immediately.

My DNS server is configured in the clients via DHCP to point to the router itself. But DNS requests for the router name return all router's IPs (from all VLANs and WAN), as I see from nslookup. I suppose that one of the possible causes for my problem can be that if the DNS response includes first an IP that is not accessible from my computer's VLAN, the computer unsuccessfully tries to connect and waits for the timeout.

I tried to make Opnsense to return its IP according to the VLAN of the requestor. If client is 192.168.0.20, then return 192.168.0.1, if it is in 10.0.0.20, then return 10.0.0.1, and so on. But I did not succeed. The "Host overrides" does not work like this, since I cannot specify specific VLANs for the specific answers.

Using Wireshark I can see that, sometimes, the DNS request asks for router.domain.domain. So sometimes, using https://router.domain. worked immediatelly. BUT sometimes it did not (and that is why I thought of the problem with DNS returning all interfaces' IPs). To avoid this double domain search I tried the "Domain search list" in the interface, unsuccessfully.

I tried some resources (eg. https://homenetworkguy.com/how-to/confused-about-dns-configuration-in-opnsense/) but could not make much sense for my situation.

Is there anything else I can try to configure properly this?  Is it not possible to configure this like I want as I am expected to use different domains for different VLANs to solve these issues?

Thanks

Hi, this should be an easy question.

I have recently updated my router and the old DDNS still appears (Services: Dynamic DNS (legacy)). What package should I remove to get rid of it? I do not want to remove something necessary.

Thanks

Actually, yesterday I updated my system at midday:

Code Select Expand

Type opnsense
Version 22.1.1_3
Architecture amd64
Flavour OpenSSL
Commit 6b667da6f
...
Updated on Mon Feb 21 14:49:37 UTC 2022

After the different reboots, I was losing Internet connection, but I knew what it was. I just had to login via the router IP (no DN) and re-run the Unbound DNS in the dashboard.

Losing DNS does not occur immediatelly. Tonight I went to sleep with Internet. Today I woke up and there was no Internet - again, the Unbound DNS was deactivated.

By the way, this is the same issue I had before, where I mistakenly though I lost connectivity, and then I discover it was only DNS:
https://forum.opnsense.org/index.php?topic=25947.msg125084#msg125084

Suricata also stops after a few minutes. But I cannot make it work, it always stop. On the contrary, DNS stays running if I do not reboot the router.

How can I research what is going on?

Is there a solution for this?

When I reboot OpnSense, at some point all my devices are left with apparently no Internet access and it is just a DNS issue - because the Unbound DNS service is stopped.

[I DO know]

After many more days, I can confirm that the problem has not been reproduced again.

So I was not able to see the problem again or to find ways to research the issue. I think it was something making DHCP and DNS services go down.

To be clear (especially wrt the previous post), you are referring to the other person, I never said this was a version problem. I did not know what the problem source was but I DO know it started after I rebooted the router in a long time after a version update -- BUT this does not mean that it is a problem of the new release, I do not know. I was just looking for ways to research what the problem was.

This:

Code Select Expand

  os-dyndns (misconfigured)   1.27_1   173KiB   OPNsense   Dynamic DNS Support
is solved via:
https://forum.opnsense.org/index.php?topic=22529.0#msg111227

"System: Firmware: Status", bottom right: "Resolve plugin conflicts" option "Reset all local conflicts"

The only thing that stays is a Suricata problem, but I think this should be reported in a new forum post.

In my case, keeping 21.7.6 with Suricata off (it was stopped automatically, without my intervention, probably something went wrong) I have not experienced the issue again in the past days. I think that for some reason some of the services were probably shut down automatically and that is why I experienced the DHCP/DNS problems.

I am still not sure how to research the source of the problem, but at least it is not repeating itself.

Yes, of course you can use OPNsesnse and reach the Internet from the LAN.

I suppose the problem is how you have configured OPNsense...

Even though it is not your specific situation, check if any of this can help:
https://forum.opnsense.org/index.php?topic=4794.0
https://www.reddit.com/r/OPNsenseFirewall/comments/p16ee0/route_lanopnsense_traffic_to_existing_router/

Glad I could help!

If it is related to the load I think you can also use OPNsense to investigate if there is a computer using a lot of bandwidth so, for example, someone/something at home is doing a lot of connections and degradating the network  user experience. There is even an option (I recall it was at the beginning) that shows you a graph.

Similarly, you can also put devices in different VLANs, limit traffic from some devices so they do not overload the modem, and give priority to e.g. the gaming computers so they do not suffer lag if other devices want to overload the system.

But I will be cautious since sometimes the source of problems is not as clear as we initially think.

Hi,

I am just going to think out loud some ideas to find out more about the issue... Apologies if you have already done all this testing.

Does the issue happen almost consistently when pinging different servers?

Have you tried connecting the PC directly to OPNsense to see if the issue persist? (since you said there is a switch in the middle).

Do you experience the same from the router itself? Try to do a ping (with a large count) from OPNsense "Interfaces - Diagnostics - Ping" and see what you get.

I would also try to do Traceroutes from the computer and from OPNsense (also in Interfaces - Diagnostics).

Ping Plotter is a tool I used in the past to check latency issues too (they have a free trial).

I remember a jitter issue I found via Wireshark and Smart TV and Plex were to be blamed, but your case seems different. The fact that this happens in more than one computer and that it is a ICMP ECHO request make me think that it is not related to PC processor congestion or TCP windows. Router congestion seems like a possible reason but you already said it is unlikely.

I am not sure this is the source of the issue but you are right there is something odd there. Yesterday I found Suricata was stopped for some reason, and the logs were saying:

Code Select Expand

2021-12-12T07:04:15 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'ET.telnet.busybox' is checked but not set. Checked in 2023019 and 2 other sigs
2021-12-12T07:04:15 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_WARN_FLOWBIT(306)] - flowbit 'et.DocVBAProject' is checked but not set. Checked in 2020170 and 0 other sigs
2021-12-12T07:03:48 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-user_agents.rules:250 uses unknown classtype: "pup-activity", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:44 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-malware.rules:15756 uses unknown classtype: "credential-theft", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:41 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-malware.rules:9890 uses unknown classtype: "social-engineering", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:41 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-malware.rules:8962 uses unknown classtype: "external-ip-check", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:39 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-info.rules:694 uses unknown classtype: "coin-mining", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:37 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-exploit.rules:800 uses unknown classtype: "exploit-kit", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:37 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-dns.rules:112 uses unknown classtype: "targeted-activity", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:37 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-attack_response.rules:488 uses unknown classtype: "domain-c2", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:03:37 suricata[4057] [100200] <Warning> -- [ERRCODE: SC_ERR_UNKNOWN_VALUE(129)] - signature at /usr/local/etc/suricata/opnsense.rules/emerging-activex.rules:788 uses unknown classtype: "command-and-control", using default priority 3. This message won't be shown again for this classtype
2021-12-12T07:02:25 suricata[4057] [100200] <Notice> -- rule reload starting
2021-12-11T13:44:20 suricata[4057] [100200] <Notice> -- all 5 packet processing threads, 4 management threads initialized, engine started.

This might be a misconfiguration from my side but I cannot see where. All rules are updated and enabled.

Not sure what I have to modify to have Suricata working... Disabling it is a workaround, but not ideal.

I was checking similar issues and found some posts, but nothing useful...

Thanks. It's useful to know that the issue is happening to other people...
I have not seen anything unusual though. I will keep checking logs, but if anyone has an idea of where to look and for what, it would be appreciated.

During the last two days I went to bed with Internet access and I woke up without it. My question is: How can I research what is happening?  What should I look for and where? I looked into logs but I could not find anything strange.

Symptoms:
- The router is operating but devices have no Internet access
- However, devices can access machines within the local VLANs, so my computer can see data from the camera, locally
- Cannot access the router GUI by DN but I can by IP
- From the router I can ping google.com and get DN for www.google.com
- I can connect externally via VPN
- When Windows tries to fix the issue by reseting DHCP, I lost the assigned IP (DHCP not working?)
- I had to restart the router to get everything back. I found out that restarting some services a couple of times seems to work too.


Some context:
It all started when I rebooted the router after many months of uninterrupted operation and I upgraded Opnsense to the latest version:
Type   opnsense   
Version   21.7.6   
Architecture   amd64   
Flavour   OpenSSL   
Commit   acdaa7649   
Mirror   https://pkg.opnsense.org/FreeBSD:12:amd64/21.7   
Repositories   OPNsense   
Updated on   Wed Dec 8 13:52:49 UTC 2021   
Checked on   Sat Dec 11 13:29:34 UTC 2021

All packages are up to date:
Your packages are up to date.

I only see this issue, but I don't see the reason, and it seems to work fine:
os-dyndns (misconfigured)   1.27_1   173KiB   OPNsense   Dynamic DNS Support

WAN connection is OK:
   Name   Interface   Protocol   Priority   Gateway   Monitor IP   RTT   RTTd   Loss   Status   Description   
      WAN_... (active)   WAN   IPv4   254 (upstream)   x.x.x.x      ~   ~   ~   Online   Interface


From a client computer I get no DNS access:
> tracert google.com
Unable to resolve target system name google.com.

> nslookup www.google.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  10.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

But from the router I can ping and receive DNS responses with no problem


It seems to me that I could be a problem related to DHCP or DNS, but what should I look for, and in which GUI option, to find the source of error?

Thanks

This doesn't look like a software bug to me. Written in words, i see your configuration like this:

Display only packets which match rule 1.
Rule 1: Does {at least one of: src, dst} not contain {10.10.10.50}?

Your packets (with red underlined src) match rule 1, because their dst does not contain "10.10.10.50".

You might feel this software behavior doesn't make sense. But to me it makes sense, because the implementation of both filter aspects ("src,dst" and "does not contain") seems correct. You might feel the "src,dst" should be implemented as "and" and not "or". But i think the "or" is necessary to be able to filter packets which have a given host as dst or src.

If you want to see only packets which have a given host neither as src nor as dst, you probably need to create 2 rules, one for src and one for dst.

I see... I think you are right. This sounds to me like the != behaviour on Wireshark. But in this case, it is very confusing to give the option "host does not contain X.X.X.X" because it will never do anything.

And you are right about your 2nd comment, it should have been in a new thread. Just seemed quite small to create a new thread and this thread was ignored for a long time, now it's not.

Also... I captured packets for two VLANs and the WAN, and the one in the WAN is named incorrectly as:

packetcapture_igb0_vlan20.cap

This seems like a (minor) bug to me.