Topics

I wasn't doing anything spectacular, i was working via a rdp connection when everything went dark, suddenly no more internet (apparently). When logging into the WebGUI, i noticed Unbound wasn't running anymore.

I found these in the logs:

Code Select Expand


Apr  8 21:35:04 gateway configd.py: [23ab9b35-a78b-4362-9cc8-d36317cc3d9d] Reloading filter
Apr  8 21:35:05 gateway configd.py: [d871e2ee-e679-4c7e-8d69-c522201e12b3] generate template OPNsense/Filter
Apr  8 21:35:05 gateway configd.py: generate template container OPNsense/Filter
Apr  8 21:35:05 gateway configd.py: [c640a92f-1db9-4516-b542-a8806bd48fc3] refresh url table aliases
Apr  8 21:35:16 gateway kernel: pid 19657 (unbound), uid 59: exited on signal 11
Apr  8 21:39:29 gateway configd.py: [eb29b026-4b4a-436b-b35a-81b9f13bd71e] updating dyndns WAN2_DHCP


What just happened? Did anybody notice anything similar?
First time i ever noticed this. Restarting Unbound got things working again.

I need this info (if possible to disclose) because of some logistical decisions i need to make.

Thanks.

Hi guys,

So.. testing multiwan on my system...
I have a WAN1 which is my PPPoE link and WAN2 which is a Mikrotik with a Huawei 3G modem in it.

I configured a failover group with "packet loss", having as TIER1 the IPv4 gateway of the PPPoE link and as TIER2 the IPv4 gateway of the Mikrotik.

OPNsense crashes every time I disconnect the PPPoE link from Interfaces: Overview.

I submitted the crash report from the WebGUI, don't know if it got uploaded...

Any ideas what's happening?

Where/how can I change the default logging level to a more verbose logging level of the entire OPNsense system? Except maybe for services that have this feature built-in the GUI, of course.

Thank you.

I got a feeling that some users here report false bugs or issues (or repeat existing ones) just to highlight how well pfsense works.

Please stop. If pfsense works out that good for you, you have no reason to be threatened by OPNsense. Any other intentions will only discredit pfsense by your actions, and not OPNsense.

This is getting really annoying, it's childish and ridiculous. And will have a significant negative impact on pfsense. Please, stay on your forum, it's better for everyone.

[checked]

If you would like to first test OPNsense in an isolated virtual environment, this is a basic guide to get you started.

This guide assumes the following:
1. You have downloaded an OPNsense ISO image; for this guide, 18.1.5 was used and tested
2. You have installed VMware Workstation; for this guide, v14 is referenced
3. You already have an active DHCP server in your network (or any working LAN and internet connection basically, adjust your OPNsense WAN interface accordingly)
4. You want to isolate your new OPNsense-controlled test network so that it will not interfere with your current one. For this, we will also use/need another VM as a LAN client of the OPNsense-controlled network
5. You have enough resources on the host machine for VMware to run at least 2 VMs. For the OPNsense machine, please refer to https://wiki.opnsense.org/manual/hardware.html. For your other VM, please refer to your other OS requirements


VMware environment setup:
1. You will need to create an isolated LAN network serving as the OPNsense LAN network. The DHCP server of your virtual LAN network will run on a custom interface, part of this network, making sure your OPNsense LAN clients will automatically receive an IP address
- open VMware and go to Edit -> Virtual Network Editor
- click on Add Network and create a new interface; select "Host-only", making sure "Connect a host virtual network adapter" is checked and "Use local DHCP service..." is unchecked
- for Subnet IP and Subnet mask use something it's not used anywhere in your actual network. If your actual network uses 192.168.100.1/24 for example, you can use 192.168.10.0/255.255.255.0 here
- click OK to add the interface
- select the newly created interface from the list then click on "Rename network" to something easy to identify, like "OPNsense LAN"
2. Create a new virtual machine:
- select Custom configuration
- select the OPNsense ISO you downloaded
- configure at least 2 CPU cores and 4gb RAM for the OPNsense vm
- select "Use bridged networking" for the network type
- the last config window will display a summary of your VM and has a "Customize hardware" button; click on it and add a new network adapter and click "Finish" to add the adapter
3. Uncheck "Power on this VM after creation" and click "Finish" once again
4. Go to VMware -> VM -> Settings:
- make sure your first network adapter is set on "bridged"; select this network adapter and go to "Advanced" and write down the MAC address of this adapter, then click on OK or Cancel (we just need the MAC). This will be the WAN of your OPNsense VM
- go to your second network adapter and instead of "bridged" or whatever is its default, select "custom" and from the drop-down menu select "OPNsense LAN (Host-only)", then go to "Advanced" and write down the MAC address of this adapter as well
- save all settings power up the vm and create your OPNsense VM


Install OPNsense on the VM:
1. Power it up and install OPNsense referring to https://wiki.opnsense.org/manual/install.html
2. After installation, hit any key when prompted to manually assign interfaces and type in the interface corresponding to the MAC address intended for the WAN interface, then for the LAN interface
3. After OPNsense fully boots and prompts for credentials, reboot (option #6 from the console menu)
4. After the reboot, login and select option #12 (Upgrade from console)
5. Reboot once more it will not reboot automatically


Create and/or edit an existing VM serving as a LAN client for your new OPNsense network:
1. If you already have a VM, select it and go to VMware -> VM -> Settings
2. Edit your existing network adapter, select "Custom (specific virtual network)" and from the drop-down menu select "OPNsense LAN (Host-only)"
3. If you have no VM to edit, create one using the OS of your preference, making sure its network adapter has the "OPNsense LAN (Host-only)" network connection selected
4. Power up / create this VM as well


Verify your setup:
1. Make sure you have a working internet connection on your new OPNsense VM and its LAN client (ping, traceroute, web etc.)
2. Make sure you can load the OPNsense WebGUI and log on (by default, its address is http://192.168.1.1/)
3. To access the OPNsense WebGUI from your "real" network (aka your actual LAN network which is the WAN network of the OPNsense VM), you have to allow private/bogon networks on the WAN interface of the OPNsense VM and add rules to allow access to the WebGUI and/or ssh from the WAN interface of OPNsense
4. If everything works, power off your OPNsense VM and create a snapshot; you can always return to it as a basic setup if you break something while testing


Good luck!

I don't know what's happening after the upgrade on my box.

So, here it goes:

1. Whenever I restart the box, I have no internet connectivity on the LAN clients; pinging from the OPNsense GUI works fine, pinging from the LAN clients (using IP or FQDN) fails
2. To make things work again on the LAN side, I have to either:
- disconnect/connect my PPPoE link (on the WAN)
- or edit the default gateway without any modification, save and apply
3. Right after the reboot, a lot of things are still loading of course, but the GUI is available at one point. When some of the services loaded (as pictured in the attached Screenshot_36.png), internet works on the LAN side. When everything is fully loaded (as pictured in Screenshot_37.png) internet on the LAN side no longer works
4. Sometimes I can't even ssh to the box from the LAN if I don't reconnect the WAN to fix the internet connectivity (something is not binding to some interfaces, I guess)

Errors in the log:
Line 63: Mar 22 19:40:49 gateway kernel: module_register_init: MOD_LOAD (vesa, 0xffffffff810ab110, 0) error 19
Line 97: Mar 22 19:40:49 gateway kernel: pcib0: _OSC returned error 0x10
and a bunch of "Line 268: Mar 22 19:40:54 gateway sshd[48206]: error: Bind to port 22 on ... failed: Can't assign requested address."

I already tried a clean install, which in my case is a pain in the *ss:
1. Install 17.7.5 first, because I get the segmentation fault error with 18.1
2. Upgrade to the latest version
3. Install plugins
4. Restore backup

Just wanted to let you know it works great for me - so far (dual wan, both dhcp, to be precise).
OPNsense 18.1.4

Is there anybody using this network adapter:
https://www.databug.com/YT674-p/0yt674.htm

Probably a variant of this:
https://www.intel.com/content/www/us/en/support/articles/000006624/network-and-i-o/ethernet-products.html

If so, have you encountered any issues with OPNsense?

Thank you.

So, another brand new PC with top hardware (i7-8700k, Gigabyte Z370 Aorus Gaming K3, 32GB Ram, Samsung 850 Pro SSD) and another installer failure. It just hangs right after formatting the HDD, right before partitioning.

Neither OPNsense 17 or 18 installed.

The workaround is easy though: install FreeBSD 11.1 and on top of it install OPNsense (https://github.com/opnsense/update#opnsense-bootstrap)

I updated remotely. Everything seems to work well in my case (PPPoE, OpenVPN, IDPS etc).

Thank you for your hard work!

[except]

For the purpose of this test, I set up 5 URL IP table aliases (which is the blocklist) and one "Host(s)" alias containing 4 FQDNs which have static public IPs (which is the whitelist).
The URL Table (IPs) lists are a mixed content of 145.146 IPs and subnets (with a grand total of 657.109.432 unique IPs - that's a lot, I know, moving forward).
The rules are all "quick" floating, blocking all 657.109.432 unique IPs from any direction on the WAN, except the whitelist, as I am allowing anything from any direction from those 4 FQDNS.

Then I start to edit some rules, apply -> reloading of rules starts in the background, in the meantime, I start editing yet another rule -> another reloading starts in the background and so forth.

Then I go to the live firewall view to check how things are settling. I get to see a bunch of logs, allowed traffic coming from and to my whitelist FQDNs, but the thing is the IPs listed there do not match with my whitelisted FQDNs. So the firewall is (theoretically) allowing traffic from and to IPs which are not on the whitelist or at least this is how it reports it does. Like stuff are getting mixed up, blocked with allowed, allowed with blocked.

This is bad. Maybe it has something to do with those huge aliases, the editing of rules and quickly applying them, or the parallel reloading of rules in the background (? assumption). If so, probably a limit should be applied to allow only one reload of rules at a time?

Did anybody notice this?

If I reboot and do not edit/apply anything, no strange stuff happens on my box, at least right after the reboot.

I don't even use these subnets.
Does anybody else have these or it is just one of my LAN clients?
These events are generated because of custom block rules (Firehol Level 1), and there are a few of them, 1-2/sec.

Basically, on my WAN interface (RDS in the snapshot), something is constantly trying to send data to an unknown 192.168.1.1 on port 3394. I don't have either of them (192.168.1.0/24 or services listening on 3394). Is there something hardcoded in OPNsense?

[do not]

So I've come up with some custom suricata rules.
The tutorial written by dcol was very helpful to integrate them in OPNsense, thanks (https://forum.opnsense.org/index.php?topic=7209.0)!
All of them are working, meaning I get either dropped packets or alerts, except these (or other similar variants, using suricata dns keywords):

Code Select Expand

drop tcp any any -> any !53 (msg:"DNS TCP query custom port"; flow:to_server; app-layer-protocol:dns; sid:2271015; rev:1;)

drop udp any any -> any !53 (msg:"DNS UDP query custom port"; flow:to_server; app-layer-protocol:dns; sid:2271017; rev:1;)

The culprit here looks like to be app-layer-protocol:dns; which in this case cannot identify (?) DNS queries by dig or nslookup for example, on non-standard ports, for example 208.67.220.220:5353. In Wireshark they do not appear as DNS protocol queries, but MDNS. Copy-pasting a standard DNS protocol query (on p53) hex stream (which appears on Wireshark as DNS protocol) and sending it to a public DNS server on port 5353 will list the query as MDNS (as in the attached picture), exactly like dig on non-standard ports.

I have no idea if this is the actual failing point of the rules. No errors importing them in suricata.

What I want to achieve is to block all non-standard port (53) DNS queries. Do I need byte_test, offsets, content regex matching and so forth?

Thank you!

Tulai ca'i mandru OPNsensu' asta, tzuka'l'ar tata :P

If you're installing OPNsense 18.1 on a new hardware and the installer crashes with "Segmentation fault (core dumped)" no matter what you try (mbr or uefi, disabling safety features from the BIOS etc.):

1. This is because of FreeBSD 11.1
2. To get around this error, install OPNsense 17.7 first, then upgrade to 18.1
3. If the scope was a clean install, well...: after upgrading to 18.1, install your plugins first, then import your 18.1 settings

So... for those unlucky ones who have a specific PPPoE link, and when that link goes down, for some reason, they need to reboot to get the link working again, I wrote a very simple script to do this automatically, without the need of user intervention. The script reboots the OPNsense box a customizable number of times if the PPPoE interface goes down and never gets and IPv4 from the ISP. It's not ideal, but until Franco comes up with a solution... this is good enough for me.

Here's the script:

Code Select Expand


#!/bin/sh

#####################################################
# NUMBER OF REBOOTS TO PERFORM IF PPPOE HAS NO IPv4 #
#####################################################

rebootnr=10;

###################################################

sleep 60
dtstart=$(date '+%d/%m/%Y %H:%M:%S');
echo "Started at $dtstart" > /root/pppoerebootlog.txt
[ -e /root/pppoerebootcount.txt ] ||  echo "0" >  /root/pppoerebootcount.txt;
pppoeif=$(ifconfig pppoe0 | grep "inet ")
if [ ! -z "$pppoeif" ]; then
echo "IPv4: $pppoeif" >> /root/pppoerebootlog.txt;
echo "0" >  /root/pppoerebootcount.txt;
else
pppoerebootcount=$(head -1 /root/pppoerebootcount.txt);
echo $(((pppoerebootcount+=1))) > /root/pppoerebootcount.txt;
fi
sleep 1
pppoerebootcount=$(head -1 /root/pppoerebootcount.txt);
if [ "$pppoerebootcount" -gt "0" ] && [ "$pppoerebootcount" -le "$rebootnr" ]; then
echo "$dtstart PPPoE down, rebooting..." > /root/pppoe_lastreboot.txt
echo "PPPoE down, rebooting..." >> /root/pppoerebootlog.txt
sleep 1
reboot
else
if [ "$pppoerebootcount" -le "$rebootnr" ]; then
echo "Franco, all good, PPPoE is up, no need to reboot" >> /root/pppoerebootlog.txt
else
echo "We reached the max number of reboots!" >> /root/pppoerebootlog.txt
fi
fi


1. Create a file on your PC with this content and save it as a shell script (pppoe.sh for example - the tutorial & script will use this name and also the /root folder)
2. IMPORTANT: If you are using a Windows machine, you need to take care of the EOL conversion. If you are using Notepad++, go to Edit > EOL Conversion > select Unix (LF) and save the file
3. Login with your root user, upload the script (using WinSCP for example) to your OPNsense box in the /root folder and issue this command from the shell (from WinSCP or putty for example): chmod +x /root/pppoe.sh
4. Create an action conf file in /usr/local/opnsense/service/conf/actions.d/, for example actions_pppoereboot.conf with this content (also taking care of EOL conversion):

Code Select Expand

[pppoereboot]
command:/root/pppoe.sh
parameters:
type:script
message:Check if PPPoE is down, reboot if it is
description:Check if PPPoE is down, reboot if it is

5. From the shell, issue this command: service configd restart
6. In the WebGUI (refresh the page if already there), go to System: Settings: Cron and click on the + sign
7. Add a cron job similar to the attached snapshot, selecting as command to execute "Check if PPPoE is down, reboot if it is" (it will execute the script every 5 minutes)
8. Save and verify the script is working - disconnect the WAN cable or disconnect the PPPoE link from the web interface or bring down the pppoe interface from ssh (read below)

The script basically verifies if the PPPoE interface has an IPv4 address. If not, it will reboot the OPNsense box a number of times. If the PPPoE link has no IPv4 address and the box was restarted up to (and including) the configured number of reboots, it will stop rebooting the box to avoid infinite reboots. You can customize that number by changing "rebootnr=10;" in the script.
It also creates some extremely basic files, in the /root folder:
- pppoerebootcount.txt > keeps the number of reboots
- pppoerebootlog.txt > keeps some very basic logging
- pppoe_lastreboot.txt > keeps the last reboot occured because of the broken PPPoE link

Verified and working on my OPNsense 18.1.2_2 :-)

Good luck :)

Monit itself is a great plugin, but the OPNsense implementation has some inconsistencies IMO.
Let's start with this: if it cannot notify the user, the plugin is almost useless (I'm sorry if it sounds harsh).

1. The alerting (general settings) page has features specific to a general email client (like "Secure Connection"), but it cannot take hostnames, making it unusable with most public email servers.
2. There is no easy way to select the OPNsense notification system. Once you have edited the Monit server settings (with plugin-validated settings - but inexistent email servers -> because of a misspelling for example), and you want to get back to the OPNsense notification system, according to https://forum.opnsense.org/index.php?topic=7103.msg32293#msg32293, you have to uninstall the plugin, export the entire OPNsense backup, edit the xml and delete the monit section, then import the backup. Just not practical and also dangerous.
3. It is unclear what "Secure connection" mean" (SSL, TLS, StartTLS)
4. The "Apply" button sometimes never stops spinning (or it spins for a long time), I need to go to some other settings and go back to the Monit plugin. Might be some performance or cosmetic issues with it, because the settings are applied (so it works) :)

I now got to the point where I cannot be notified if an alert matches my settings, unless i use my own public email server and add it as IP (also had to modify some encryption settings). The OPNsense notifications are working fine, receiving emails. I'm constantly (according to the poll interval) getting errors (again, without my public email server):

Mail: Delivery failed -- no mail server is available

Thank you.

[Interfaces: [WAN]]

Go through each of this and you will have a working IPv6 from RDS with OPNsense.
Do not apply any settings, just save. When you're done, just reboot OPNsense.
Info: ISP using PPPoE for residential, PPPoE and Static IPs for business consumers. These settings are for PPPoEv6.
More info here: http://www.rcs-rds.ro/internet-digi-net/ipv6/en

Interfaces: [WAN]

General configuration
IPv6 Configuration Type: DHCPv6

DHCPv6 client configuration
Configuration Mode: Basic
Prefix delegation size: 64
Uncheck: Request only a IPv6 prefix, Send IPv6 prefix hint, (optional) Enable debug, Prevent release
Check: Directly send SOLICIT, Use IPv4 connectivity
Use VLAN priority: disabled

[SAVE]


Interfaces: [LAN]

General configuration
IPv6 Configuration Type: Track Interface

Track IPv6 Interface
IPv6 Interface: WAN
IPv6 Prefix ID: 0


[SAVE]
[REBOOT]


Then renew your LAN client's IPs (or just reboot the clients) and then verify if everything is ok here:
https://test-ipv6.com/
or (10x to @phoenix)
https://ipv6.chappell-family.com/ipv6tcptest/

.. and finally test the security:
https://www6.chappell-family.co.uk/cgi-bin6/ipscan-js.cgi

Quick feedback:

Upgrade from 18.1.1 was successful, smooth, no errors.
All my services are up and running, no issues so far.

Performance the same:
http://rcs-rds.speedtestcustom.com/result/89f04970-0cda-11e8-bb8d-15d42d0ab0bf

Congrats and thank you!