Messages

Hello,

I would like to make the sshd config file to contain a match directive, I could just go straight to the .conf file generated by /usr/local/etc/inc/plugins.inc.d/openssh.inc but I believe this wouldn't survive a reboot/upgrade.

What would be best practice approach you would suggest me to follow? I envision 2 solutions, perhaps here I can find some other approach that suits best.

1/ Make the /usr/local/etc/ssh/sshd_config immutable and add the Match directive.

2/ Write a simple script in /usr/local/etc/rc.d/ to append the Match directive to the sshd_conf?

Thanks in advance!

Sorry to "resurrect" this thread but I just wanted to add my 5cents as I had the same need and dmesg didn't show all the messages that happen on main console upon boot, rather only kernel messages.

For example you may want to see the scripts that are executed upon boot from

Code Select Expand

/usr/local/etc/rc.syshook.d/<subdir>/

Perhaps somebody has a better approach but I could only check that doing Scroll Lock on main console and pageup/pagedown. 

Hope this helps!

I'm running a LAGG on trunk, so all tagged. My clients are on access mode, tho.

I want to report that I've found a workaround for this issue.

After testing different workarounds I've come to fix it blocking traffic for port 67-68 from all my vlan interfaces but the point-to-point one, so eventually I just created a floating rule for that instead of creating single rules on each interface.

Now, this fix puzzles me, because if you check the output from my neighbour DHCP server, the duplicate request comes from the Point-to-Point vlan iface, one would expect that I should block the DHCP traffic from that iface (which is a no-go).

Anyway, I don't know if this is because the nature of my setup or if it's some weird interaction from the DHCP Relay service @ OPNSense, I thought on sharing this knowledge and maybe devs or other users can make any use of this.

Cheers.

Hello,

I'm having an issue where my DHCPv4 Relay is sending duplicate requests to my neighbour DHCP server.

The setup looks the following:

- I have multiple VLAN interfaces for my own network (acting as GW for each vlan).
- DHCP server is located in another network.
- In order to establish communication between OPNSense DHCP Relay and neighbour DHCP Server a point-to-point vlan between networks has been created, these 2 networks are going through same network topology (same hardware and cabling).
- A static route has been applied to reach the DHCP server via the point-to-point VLAN.

Some info regarding the setup:

- Point-to-point VLAN = VLAN1100 10.10.10.10 (subnet 10.10.10.8/30)
- DHCP Server = VLAN2200 10.21.0.100 (subnet 10.21.0.0/22)
- Static route to 10.21.0.100 via 10.10.10.10

Now up to the issue. Well, under this setup, the DHCP Relay seems to be sending duplicate DHCP requests to the server. See below output from the server dhcpd logs.

Code Select Expand

Jul 27 13:49:14 cp0385 dhcpd: DHCPREQUEST for 10.33.0.11 from ####### via 10.33.0.1
Jul 27 13:49:14 cp0385 dhcpd: DHCPACK on 10.33.0.11 to ####### via 10.33.0.1
Jul 27 13:54:14 cp0385 dhcpd: DHCPREQUEST for 10.33.0.11 from ####### via 10.10.10.10: wrong network.
Jul 27 13:54:14 cp0385 dhcpd: DHCPNAK on 10.33.0.11 to ####### via 10.10.10.10
Jul 27 13:54:14 cp0385 dhcpd: DHCPNAK from ####### via 10.10.10.10: unknown network segment

Network 10.10.10.8/30 is not configured on DHCP server, this is intended.

As you can see, every five minutes a duplicate request is sent via the wrong GW. I have checked my configuration on GUI level for the DHCP Relay, VLAN1100 interface is not selected to relay requests.

Is there anything I can check or change on my end to make this setup work without duplicate requests? I haven't been able to see antyhing relevant on the logs both GUI or /var/log/dhcpd/latest.log (which look the same to me) and I can't seem to be able to find any cfg file for the DHCP Relay where I could see more options than the ones given in the GUI.

Thanks in advance!

Basically all lagg0_vlan3XYZ were created before the new convention was in place, the other VLANXY ifaces are created recently since new convention has become standard.

This, as discussed before doesn't make much sense for end use and doesn't get along with legacy interfaces. I've cropped the picture because I don't feel the need to share more information to make this point.

In GUI is ok because you still have the descriptions of the interfaces as main guidance to know where you are moving around, but in CLI (when you are in a hurry/panic situation) things get messy, especially if you have a salad of interfaces like I ended up having at the moment. Hence, my request to consider allowing us via some GUI option to stay in old naming convention and embrace the potential issues that lead you guys to make this naming convention change.

Not all environments are going to run with stacked vlans, this change is quite niche but affects us all, IMHO.

First of all I want to thank all the dev team at OPNsense for such a great product. Also I would like to justify that most of us using this product in our professional environment, sadly lack time to be testing the new releases before they go community.

While I understand the reasons behind this change, I'm still not fully satisfied with them. I'm now having a salad of interfaces output @ cli/gui. See below screenshot.

Franco, you've mentioned this might be addressed in a future patch. Would it be possible to give us the option to choose old naming convention/new naming convention somehow on GUI level? For obvious reasons you say is possible to do so via config.xml edit but is not really the best way to go.

Thanks for your patience with us, end users :) Hope you appreciate our feedback even when is not what you'd expect from time to time.

Hello,

I have a jump host sharing a public addressing subnet with my OPNSense firewall.

For the sake of dialogue, let's assume the following:

- Jump host's IP: 2.2.2.2/24
- FW's IP: 1.1.1.1/24
- ISP GW: 3.3.3.3/24

At the beginning I was routing all traffic straight to ISP GW from my jump host, that worked fine for SSH connections, but I would like to filter the traffic. I've been checking the firewall live logs, when I try to connect to the jump host via ssh, an entry appears as follows:

   3000_EXTRANET   IN->   2022-03-21T15:52:30   2.2.2.2:22   193.3.19.178:64001   tcp   

Despite having an IN(gresss) rule accepting (pass) TCP connection from source ip 2.2.2.2 on port 22, it still blocked me the connection, well, checking further the log entries, I've seen the rule was not being evaluated because the tcp flag, so I've edited the pass rule to check for the relevant handshake TCP flags, now it does evaluate and shows on my logs as the pass rule (green color).

Unfortunately, the ssh connection still doesn't go through. And on top of that, I'm getting some notices on my dashboard which I don't fully understand, seems related to the fact that I'm using that rule with TCP Flags.

03-21-22 15:11:06 [ There were error(s) loading the rules: /tmp/rules.debug:191: flags always false - The line in question reads [191]: pass in log quick on lagg0_vlan3000 reply-to ( lagg0_vlan3000 3.3.3.3 ) inet proto tcp from $bastion_iGent port {22} to {any} flags SA/FRPUEW keep state label 4a08b298dba26c3767c59faba4eaa586 # : Allow SSH ]

Another thing that confuses me, is the fact that the Firewall log shows the traffic as IN for a TCP packet that is SYNACK from an ssh connection request from outside, I would had expected this to be OUT (egress)?

I hope somebody can bring some light into this matter, because I'm pretty lost at this point. I will be glad to provide more data if needed.

Thanks in advance!

We also have this NIC and have had internal discussions about this topic, since I had the same concern than you (OP).

We've came to same conclusion, since this is a Firewall solution promiscous mode is kind of mandatory, especially if you use VLANs. But once again, it comes down to how and what you want to use OPNSense for.

Cheers!

Hello,

I'm having issues with a Broadcom NetXtreme Mezannine 10G FIB NIC. Tagged VLAN Traffic doesn't go through. After digging some info on google, this family of NICs are known to be buggy with FreeBSD driver which seems to be the same that OPNSense ships with (haven't really compared tbh).

Tests have been carried in many possible directions.

- Parent NIC (bnxt0) is on promiscuous mode.
- FW rules are open, even tried disabling FW globally.

Code Select Expand

# pciconf -lv | grep -A1 -B3 network
bnxt0@pci0:2:0:0: class=0x020000 card=0x1feb1028 chip=0x16d814e4 rev=0x01 hdr=0x00
    vendor     = 'Broadcom Inc. and subsidiaries'
    device     = 'BCM57416 NetXtreme-E Dual-Media 10G RDMA Ethernet Controller'
    class      = network
    subclass   = ethernet

The kernel module for bnxt is loaded. What can I do to make it work as it does on FreeBSD13? If you need more info/outputs from my end, I'll be glad to provide.

Some links for your reference.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236983

https://forum.opnsense.org/index.php?topic=18312.msg83206#msg83206

Thanks in advance!