Topics

1

18.1 Legacy Series / Unbound crashed

« on: April 08, 2018, 10:02:58 pm »

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]

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.

2

18.1 Legacy Series / When is 18.1.6 going to be released?

« on: April 05, 2018, 07:19:07 am »

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

Thanks.

3

18.1 Legacy Series / OPNsense panics in my multiwan setup

« on: March 30, 2018, 12:52:07 pm »

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?

4

18.1 Legacy Series / [Solved] Change logging level of OPNsense

« on: March 27, 2018, 12:56:21 pm »

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.

5

General Discussion / For all ill-intentioned pfsense fans

« on: March 27, 2018, 08:17:04 am »

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.

6

Tutorials and FAQs / [Tutorial] Testing OPNsense in an isolated VMware environment

« on: March 25, 2018, 11:18:25 am »

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!

7

18.1 Legacy Series / [Solved] 18.1.5 issues

« on: March 22, 2018, 06:58:39 pm »

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

8

18.1 Legacy Series / Multiwan

« on: March 14, 2018, 12:29:18 am »

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

9

Hardware and Performance / Dell/Intel PRO/1000 VT Quad Port Server Adapter

« on: March 12, 2018, 09:19:47 am »

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.

10

18.1 Legacy Series / Another installer failure

« on: March 09, 2018, 10:16:27 pm »

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)

11

18.1 Legacy Series / 18.1.3 release

« on: March 05, 2018, 09:57:38 pm »

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

Thank you for your hard work!

12

18.1 Legacy Series / [False alarm - ignore] Firewall pass/block/reject & live view or logging issue

« on: February 19, 2018, 10:17:02 pm »

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.

13

18.1 Legacy Series / What's generating this traffic?

« on: February 19, 2018, 07:40:42 pm »

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?

14

Intrusion Detection and Prevention / Suricata experts, help :)

« on: February 16, 2018, 11:35:52 pm »

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]

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!

15

Romanian - Română / Mno amu ashe ardeleneste, primul post

« on: February 16, 2018, 10:01:36 pm »

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