Messages

I'm sorry, but I am not clear on the point of your post. It seems to be out of context; perhaps you posted in the wrong place?

I am trying to troubleshoot a problem. I have several hosts on my network that use `dhcpcd` (DHCP Client Daemon). I've used `dhcpcd` for years, and it seems to work quite well, but I am having an issue with a couple of hosts recently that are configured with the `inform` option. All that means is that the hosts send a DHCPINFORM message, and receive a DHCPACK as shown in the log messages below.


2022-05-17T16:40:52   dhcpd[42083]   DHCPACK to 192.168.1.57 (b8:27:eb:3a:b9:78) via em1   
2022-05-17T16:40:52   dhcpd[42083]   DHCPINFORM from 192.168.1.57 via em1


`dhcpcd` seems to be happy with this result; its log shows the following:


May 17 22:40:26 raspberrypi1bp dhcpcd[265]: dev: loaded udev
May 17 22:40:29 raspberrypi1bp dhcpcd[265]: eth0: waiting for carrier
May 17 22:40:31 raspberrypi1bp dhcpcd[265]: eth0: carrier acquired
May 17 22:40:32 raspberrypi1bp dhcpcd[265]: eth0: probing address 192.168.1.57/24
May 17 22:40:36 raspberrypi1bp dhcpcd[265]: eth0: received approval for 192.168.1.57
May 17 22:40:36 raspberrypi1bp dhcpcd[265]: eth0: adding route to 192.168.1.0/24
May 17 22:40:36 raspberrypi1bp dhcpcd[265]: eth0: adding default route via 192.168.1.1
May 17 22:40:37 raspberrypi1bp dhcpcd[265]: forked to background, child pid 371


The host seems to operate correctly, `ip addr` & `ip route` give expected results, the host can reach other hosts on the LAN, and on the Internet, and the host can be found by other hosts on the LAN.

The only odd thing is that this host is never listed in the lease table when the inform option is used. I have another host that is configured identically, and it does show up in the lease table as follows:


I/f      IP addr      MAC addr           Hostname      Description               Lease type
LANem1 192.168.1.51  b8:27:eb:a7:8c:00  raspberrypi0w  RPi Zero W - WiFi client  static


I suspect that one of these two clients is failing to send something that's needed for the log entry, but I have no idea what that "something" is. Beyond the DHCPINFORM, and the DHCPACK, what is needed by the OPNsense DHCP server to make an entry in the lease table?

[A log of my investigation into "Fix the DNS" follows:]

A log of my investigation into "Fix the DNS" follows:

There is definitely something amiss with DNS. Using the diagnostics in OPNsense, I can't ping pkg.opnsense.org - or anything else for that matter. The output is:

Code Select Expand

# /sbin/ping -c '3' 'pkg.opnsense.org'
ping: cannot resolve pkg.opnsense.org: Host name lookup failure

Oddly, I get intermittently successful (but rather slow) DNS lookups (see attachment); sometimes I get a result - sometimes I don't!

I didn't (knowingly) change anything during my string of updates yesterday - except to disable the plugin for Dynamic DNS. This system has been running for years; I started with a much older version, and have updated it repeatedly without incident. My configuration tends to remain very stable. Here's how my DNS is set up currently:

Dnsmasq is enabled on both (LAN & WAN) interfaces, Port 53

MDNS Repeater is also enabled - on the LAN only; this is contrary to the "Help recommendation": "At least two interfaces must be selected."  I didn't change this during my machinations yesterday - at least not intentionally. No other DNS services are enabled; only Dnsmasq & MDNS Repeater. I do not recall why MDNS repeater is installed!! I have intermittently run a VPN on OPNsense - perhaps it was added to support that?

This may be relevant: Viewing my Firmware plugins, I see this:

Code Select Expand

os-dyndns (orphaned) 1.24_2 169KiB OPNsense Dynamic DNS Support
os-mdns-repeater (orphaned) 1.0_1 14.7KiB OPNsense Proxy multicast DNS between networks

Perhaps this is a result of the failure to resolve pkg.opnsense.org ?

On the LAN hosts I checked, DNS seems to work perfectly & prompt responses are received:

Code Select Expand

$ host pkg.opnsense.org
pkg.opnsense.org has address 89.149.211.205
pkg.opnsense.org has IPv6 address 2001:1af8:4f00:a005:5:: 

I have just now disabled MDNS Repeater (no reboot), and it seems to have no effect: pings are 100% failures, DNS lookups remain intermittent, updates remain "constipated".

I re-booted several times yesterday trying to clear the update failure with no effect, but I decided to try a reboot again today...   Voilà !!!
Updates are responsive again, all pings work, and DNS lookup is more responsive.

I am whole again, but please allow me to continue - I still have questions:

1. The only change I made was to disable MDNS Repeater. I expected OPNsense to prompt if a reboot were required, but got none. I'm left wondering exactly what the "fix" was???

2. Is an enable/disable of MDNS Repeater expected to throw a reboot prompt in the web gui?

3. In an effort to find an answer (by replicating the issue), I re-enable MDNS Repeater and Dynamic DNS under all options used previously, and test before and after a series of reboots:
   a. before reboot: ping works 100%, DNS Lookup seems more reliable, but failed to yield a result for 1 of 3 tests
   b. after reboot: ping works 100%, DNS Lookup worked 100%
   c. I find this result confusing as it implies that nothing I did made any difference at all. Any comments???

4. I have read the documentation for Dnsmasq. My 'take-away' from this is that OPNsense team recommends use of the Unbound DNS - is that a correct interpretation?

Looking forward to any and all replies & thank you for your help.

~ S

[I did see that a couple of plugins were 'orphaned':]

I have gotten behind in my updates, and so today was a 'catch-up' day.

Things have gone x-well until just now; I first encountered a series of messages re missing packages during the OPNsense 21.1.9_1-amd64 update. And now, when I am attempting to update to 21.7 (my final destination for the time being), this message displayed for a very long time:

***GOT REQUEST TO CHECK FOR UPDATES***
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...

Eventually, it seems to have worked through the process, and the complete message appeared:

***GOT REQUEST TO CHECK FOR UPDATES***
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/latest/meta.txz: No address record
repository OPNsense has no meta file, using default settings
pkg: https://pkg.opnsense.org/FreeBSD:12:amd64/21.1/latest/packagesite.txz: No address record
Unable to update repository OPNsense
Error updating repositories!
pkg: Repository OPNsense cannot be opened. 'pkg update' required
Checking integrity... done (0 conflicting)
Your packages are up to date.
***DONE***

I've not skipped any steps (e.g. when the pkg mgr required an update).

I did see that a couple of plugins were 'orphaned':

os-dyndns (orphaned)   1.24_2   169KiB   OPNsense   Dynamic DNS Support   
os-mdns-repeater (orphaned)   1.0_1   14.7KiB   OPNsense   Proxy multicast DNS between networks

I have the option to delete either or both of these two plugins... Should I ???

I've tried "Check for Updates" again, but it's headed for the same dead-end as above.

I've run an "Audit" on "Health"; it seems all "core package consistency" checks FAILED with the message: 'no upstream equivalent' as follows:

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 21.1.9_1 (amd64/OpenSSL) at Mon Mar 28 17:02:10 CDT 2022
>>> Check installed kernel version
Version 21.1.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 21.1.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 66 dependencies to check.
Checking packages: .
beep-1.0_1 has no upstream equivalent
Checking packages: .
ca_root_nss-3.68 has no upstream equivalent
Checking packages: .
choparp-20150613 has no upstream equivalent

...

Checking packages: .
wpa_supplicant-2.9_11 has no upstream equivalent
Checking packages: .
zip-3.0_1 has no upstream equivalent
***DONE***

What should I do? I don't seem to be able to get my next upgrade!

[1.]

Here's one way to make this work:

After asking a couple of related/similar questions here, I managed to get the final puzzle piece I needed on reddit (the OPNsense sub-reddit). I thought I'd share the answer here. Please note: I don't claim this is the best/optimal answer - I claim only that this does work for my particular situation. Perhaps the OPNsense experts here can identify improvements; perhaps even add something to the documentation?

1. Ref the attachment here below for a crude schematic of my network. The Firewall/LAN gateway at 192.168.1.1 is OPNsense running on an appliance with two (2) Ethernet ports. The OPNsense configuration was mostly the default configuration generated during initial installation some time ago. Recently, I added a small embedded device to the network - the "pocketbeagle" device connected to a laptop running Ubuntu 20.04.

2. The objectives are as follows:

• Internet access for the pocketbeagle device
• SSH access to the pocketbeagle device from hosts on the 192.168.1.0/24 subnet

3. After plugging in the pocketbeagle device, I made an SSH connection from the Ubuntu laptop. I found it was necessary to add a default gateway to the pocketbeagle device:

    $ sudo route add -net 0.0.0.0 gw 192.168.6.1

4. On the Ubuntu laptop, I verified that forwarding was enabled, and that the firewall (ufw) was disabled:


    $ cat /proc/sys/net/ipv4/ip_forward
    1
    # "1" means ip_forward is enabled
   
    $ sudo ufw status
    Status: inactive
    # "inactive" means that no rules are altering traffic patterns on the Ubuntu laptop


5. A return route from the firewall is needed to route packets back to the pocketbeagle device. I did this by creating a static route. Use the GUI from here, be sure to Save, Apply, etc as you complete each step:

• System->Gateways->Single, Add a gateway for the IP on the Ubuntu laptop (192.168.1.104 in this case
• System->Routes->Configuration, Add a route to 192.168.6.0/24 using the gateway defined in the previous step

6. The final step to gain Internet access for the pocketbeagle device is to set up NAT for packets from the 192.168.6.0/24 subnet. Using the OPNsense GUI again:

• Firewall->NAT->Outbound; Change mode to "Hybrid outbound NAT rule generation"
• Add a NAT Rule for the WAN interface for Source Address 192.168.6.0/24

That should do it. My pocketbeagle device can now connect to the Internet, and I can update/upgrade its Debian OS. As far as connecting to the pocketbeagle device from other hosts on the network, I elected not to use OPNsense for this - I simply created a static route on each host that needed access. For example, on my Macbook, this took care of it:

    % sudo route -n add 192.168.6.0/24 192.168.1.104

[were]

Sorry but I can't tell you positive things when you do that wrong.
Just trying to help you. And if you don't want that help and already know how to set it up there shouldn't be a problem in your system.
Here are just people who try to help.

And I think it's not okay if someone is trying to find the bugs in your network, tell you the bugs and you say that these people just spreading negativity.

I appreciate help... really I do. But you weren't helpful. When someone says, "That will not work" a few times, but they are making guesses, I call that negativity. And you were making guesses. How do I know that? Because it does now work - just as I've shown it in the diagram, and configured as I described. Is there more than one way to do it? I'd say that's very likely, but this does work. How? I'll leave that for you to research. 

[am]

On your "Painting" i see that you dont have the 6.0 Network on the OPNsense conencted. That will not work.

So Ping from every device in the 1.0 Network is working. But not from 6.0 to Internet. That is because every Packet from the 6.0 Network is going to your Pocketbeagle, but thats it.

No...  I added the network diagram hoping it would clarify things, but it may be confusing them. It does show a WiFi connection from the Ubuntu Linux host to the gateway at 192.168.1.1. As I explained in my original post, I am routing packets from 192.168.6.0 to 192.168.1.1 with the connections as shown in the diagram.

You can't set your gateway to an address which is not in the Subnet of the device itself. That will not work

I'm ending this thread... your negativity wins - congratulations! You apparently believe I am making this up. FYI, I have better things to do than create imaginary networks, and report results that I didn't actually see.

Simple, they cannot see each other. the x.x..6.0 range will not talk to the *.*.1.0 range without either a gateway or a mask of 255.255.0.0. What make/model is the USB dongle, sounds like it's running in gateway mode rather than access point mode.

I have a gateway - the WiFi interface in the Ubuntu host (see attachment, please). I've created a static route in OPNsense using this gateway. I can ping the OPNsense host at 192.168.1.1 from 192.168.6.2.

The "dongle" is a "pocketbeagle" running Debian: https://beagleboard.org/pocket. It runs its own DHCP server, and is configured to create its own network.

The fact that the subnets don't overlap would indicate two separate security policies. You need to stop hosts bypassing their restrictions by just changing their IP address.

The common way to stop this is to separate the hosts by VLAN. This implements your policy on devices outside the host's control (firewall and switches).

I do wish I had some idea of what you're talking about, but what you've written makes no sense at all to me. I just do not see an answer to my question here.

The subject of this post seems to summarize what I've been asking for a while without a definitive answer:

Is it possible to assign multiple subnets to a single interface?

For example:
I have a 2-NIC appliance running OPNsense. I have been using it as a router/firewall for my LAN at 192.168.1.0/24, and now I want to add 2-3 hosts to my network that use 192.168.6.0/24 (I actually have this situation). I want to give these devices on 192.168.6.0/24 access to the Internet through my OPNsense firewall.

Is this possible?

If so, please explain how.

If not possible, can anyone explain the meaning of this statement in the "Advanced" section of the firewall? https://docs.opnsense.org/manual/firewall_settings.html#static-route-filtering

"This may be desirable in some situations where multiple subnets are connected to the same interface."

A definitive answer would really be much appreciated.

On your "Painting" i see that you dont have the 6.0 Network on the OPNsense conencted. That will not work.

That's surprising. According to this document https://lantan.pl/wiki/_media/sieci:multiple-subnets-one-interface-pfsense.pdf, you can do this in pfSense. Do you know the reason this capability was dropped?

Also - I wonder what this is telling us? https://docs.opnsense.org/manual/firewall_settings.html#static-route-filtering

[NOTE: You will not find the answer here. Instead look here: https://forum.opnsense.org/index.php?topic=18381.msg83553#msg83553]

NOTE: You will not find the answer here. Instead look here: https://forum.opnsense.org/index.php?topic=18381.msg83553#msg83553

My LAN uses 192.168.1.0/24, and it works just fine for all hosts with this address range.  The LAN gateway on my OPNsense firewall is 192.168.1.1. It all pretty much auto-configured itself, so I've not had to do much manual configuration.

I've added a new device to the network that insists on using 192.168.6.0/24. This device uses Ethernet-over-USB, and it's plugged into a Linux laptop whose WiFi is assigned via DHCP: 192.168.1.104. I understand that Ethernet-over-USB is indistinguishable from other Ethernet traffic, and requires no 'special handling'.

I think I've got the Linux laptop and its USB device configured properly: I can make an SSH connection from the Linux laptop to the USB device at 192.168.6.2. I can 'ping' the WiFi from the USB device on its 192.168.6.2 interface, and I can ping 192.168.6.2 from the Linux laptop.

My problem is that the devices on the 192.168.6.0/24 net cannot successfully make a connection to the Internet. In addition, I cannot successfully 'ping' the LAN gateway at 192.168.1.1 from the USB device at 192.168.6.0. I don't understand why this is so because the IPv4 rules on the LAN interface allow ALL sources (*). I've attached a screenshot so that's clear).

I am not sure if ALL sources includes packets with a source address from the 192.168.6.0/24 network or not??? This is a major point of confusion for me. I have searched in vain for anything in the OPNsense configuration GUI that would allow me to create or use this 192.168.6.0 network in a firewall rule. How is this done?... the 192.168.6.0/24 hosts are not directly connected to the OPNsense firewall - they are only connected to the Ubuntu host, and use its WiFi as the gateway to the 192.168.1.0/24 net.

Can someone explain what I need add to OPNsense to get Internet access for the USB device at 192.168.6.0/24? I've searched the OPNsense documentation, but found nothing relevant to this situation... but if I've missed something, I'd like to know that also.

Do a tracert from a 6.0 device. Than you will see where your Packets are going and where they stop

Unfortunately, the 6.0 device/pocketbeagle does not have `traceroute` installed - or anything similar AFAICT. It's a "catch-22": no traceroute w/o Internet, no Internet w/o traceroute.

[am]

On your "Painting" i see that you dont have the 6.0 Network on the OPNsense conencted. That will not work.

So Ping from every device in the 1.0 Network is working. But not from 6.0 to Internet. That is because every Packet from the 6.0 Network is going to your Pocketbeagle, but thats it.

No...  I added the network diagram hoping it would clarify things, but it may be confusing them. It does show a WiFi connection from the Ubuntu Linux host to the gateway at 192.168.1.1. As I explained in my original post, I am routing packets from 192.168.6.0 to 192.168.1.1 with the connections as shown in the diagram.

Yeah delete the route.

Create a Rule on the 192.168.6.0 interface which matches the traffic you want to go to the pocketbeagle. At the bottom of the rule page you can select a Gateway, use the Pocketeagle-Gateway there

I'm confused...

1. I don't see how to create a rule on the 192.168.6.0 network - it's the destination, and there doesn't seem to be a way to specify this network as the destination?


2. when you say "use the Pocketeagle-Gateway there", do you mean the WiFi interface on macbuntupro (192.168.1.104)?