Messages

1

General Discussion / Re: Setting up an IOT LAN

« on: June 15, 2021, 06:47:43 pm »

Hello could the OP and responders post their firewall rules.

I too have an IOT VLAN set up but currently only have firestick on there and not any home automation devices on there due to the need to switch between regular LAN and IOT network to control these devices.

Would be nice to be able to send commands from my phone on LAN and control a device (e.g light switch) connected to IOT network.

Thanks!

2

Intrusion Detection and Prevention / Error reconfiguring IDS: error installing ids rules ()

« on: May 17, 2021, 10:38:08 pm »

Hello,

I'm getting this error "Error reconfiguring IDS: error installing ids rules ()" when trying to enable IDS/IPS and not sure how to further diagnose/fix.

I using an APU2/4G RAM that's running the current OPNsense 21.1.5-amd64 release. For DNS using unbound and strictly DNS over TLS forwarded to Cloudfare and Quad 9 servers.

I looked through https://forum.opnsense.org/index.php?topic=18424.0 for suggestions but nothing helped. I have disabled IDS/IPS for the time being and would appreciate any help to further troubleshoot this.

I've included part of my configd.log around the time when the error is thrown:

Code: [Select]

May 17 16:03:42 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/reference.config
May 17 16:03:42 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rule-updater.config
May 17 16:03:42 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rule-policies.config
May 17 16:03:42 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rules.config
May 17 16:03:42 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/suricata.yaml
May 17 16:04:07 homehost configd.py[16836]: [3742f419-3143-4020-90a8-a89480ac2a68] Show log
May 17 16:07:34 homehost configd.py[16836]: [5d79ee33-c54d-4edc-84ef-f970a68e7c1b] Show log
May 17 16:08:39 homehost configd.py[16836]: [fc6ee590-4d91-4ea8-8bf6-6f4a129bec38] request suricata rule metadata
May 17 16:10:15 homehost configd.py[16836]: [a08ef3c4-1f9c-4e05-8d29-495bdf8af6dd] get suricata daemon status
May 17 16:10:15 homehost configd.py[16836]: [7580e51f-a640-4bad-8c10-52d4bb994ee0] request suricata rule metadata
May 17 16:10:15 homehost configd.py[16836]: [51f49706-2a98-4d2e-b153-059d94e77756] request suricata rule metadata
May 17 16:10:16 homehost configd.py[16836]: [bdaaf3bc-f785-40d1-83fd-ea59b8e977e4] request suricata rule metadata
May 17 16:10:50 homehost configd.py[16836]: [5586026c-9b3a-454d-a6b5-080feefd7a32] request suricata rule metadata
May 17 16:10:50 homehost configd.py[16836]: [c5761b53-b036-4b47-9da8-8e1f030558c5] request suricata rule metadata
May 17 16:10:50 homehost configd.py[16836]: [43c5523c-39ff-4dea-9212-2856e4bdd568] get suricata daemon status
May 17 16:10:50 homehost configd.py[16836]: [bfa03c84-a58a-4d8e-bd2d-109230f72e4e] trigger config changed event
May 17 16:10:50 homehost configd.py[16836]: [bee27c63-d4c5-4d71-bbd1-156aa4a75859] generate template OPNsense/IDS
May 17 16:10:51 homehost configd.py[16836]: generate template container OPNsense/IDS
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rules/OPNsense.rules
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/classification.config
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/custom.yaml
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //etc/newsyslog.conf.d/suricata
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //etc/rc.conf.d/suricata
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/reference.config
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rule-updater.config
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rule-policies.config
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rules.config
May 17 16:10:52 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/suricata.yaml
May 17 16:10:52 homehost configd.py[16836]: [8653a10b-0f6f-4aca-bbb9-64168e034a21] request suricata rule metadata
May 17 16:12:26 homehost configd.py[16836]: [c5394681-a080-40ab-b0d9-914142f983d4] get suricata daemon status
May 17 16:12:26 homehost configd.py[16836]: [12449fc6-2262-4176-9684-8ad0e4b4e68f] request suricata rule metadata
May 17 16:12:27 homehost configd.py[16836]: [c7af7ec0-9f6f-4733-a9ba-23de866015dc] request suricata rule metadata
May 17 16:12:27 homehost configd.py[16836]: [4871c442-9862-4b83-ac37-0ab9706ed360] get suricata daemon status
May 17 16:12:27 homehost configd.py[16836]: [3029c861-351e-4314-8811-67c6ee80b7bd] trigger config changed event
May 17 16:12:27 homehost configd.py[16836]: [0d47f230-1780-4105-9978-d996e2876dde] generate template OPNsense/IDS
May 17 16:12:27 homehost configd.py[16836]: generate template container OPNsense/IDS
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rules/OPNsense.rules
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/classification.config
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/custom.yaml
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //etc/newsyslog.conf.d/suricata
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //etc/rc.conf.d/suricata
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/reference.config
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rule-updater.config
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rule-policies.config
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/rules.config
May 17 16:12:29 homehost configd.py[16836]:  OPNsense/IDS generated //usr/local/etc/suricata/suricata.yaml
May 17 16:12:29 homehost configd.py[16836]: [f147ee96-5734-43de-aec1-3e8288450c70] install suricata rules
May 17 16:14:31 homehost configd.py[16836]: [a0df7db3-864a-4925-a678-3bdb8c5e5993] request suricata rule metadata
May 17 16:14:39 homehost configd.py[16836]: [85a64293-5a57-40ec-9f97-11347379ce4f] get suricata daemon status
 homehost configd.py[4550]: [eea30bd2-a3c3-4c8c-be0b-90adf871a830] Retrieve upgrade progress status

From the System Log it seems to point to a timeout error

Code: [Select]

2021-05-17T16:14:31 sudo[80583] admin : TTY=pts/0 ; PWD=/var/log ; USER=root ; COMMAND=/bin/cat configd.log
2021-05-17T16:14:31 configd[18782] Timeout (120) executing : ids install rules

I've also noticed in dmesg, repeated messages about promiscuous mode enabled/disabled and igb1 but now sure what to make of it.

Code: [Select]

igb0: link state changed to UP
igb1: link state changed to UP
intsmb0: <AMD FCH SMBus Controller> at device 20.0 on pci0
smbus0: <System Management Bus> on intsmb0
lo0: link state changed to UP
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS> on motherboard
amdtemp0: <AMD CPU On-Die Thermal Sensors> on hostb5
igb1: link state changed to DOWN
vlan0: changing name to 'igb1_vlan10'
igb0: link state changed to DOWN
igb1: link state changed to UP
igb1_vlan10: link state changed to UP
igb0: link state changed to UP
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
igb1: permanently promiscuous mode enabled
igb1: link state changed to DOWN
igb1_vlan10: link state changed to DOWN
igb1: link state changed to UP
igb1_vlan10: link state changed to UP
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
igb1: link state changed to DOWN
igb1_vlan10: link state changed to DOWN
igb1: link state changed to UP
igb1_vlan10: link state changed to UP
igb1: link state changed to DOWN
igb1_vlan10: link state changed to DOWN
igb1: link state changed to UP
igb1_vlan10: link state changed to UP
igb1: link state changed to DOWN
igb1_vlan10: link state changed to DOWN
igb1: link state changed to UP
igb1_vlan10: link state changed to UP


3

High availability / Public or Private IP on the WAN side?

« on: May 13, 2021, 11:11:50 pm »

Hello,

A bit about me so you know where I'm coming from
I'm a home networking enthusiast and have been running OPNsense for several years now and want to learn about and deploy HA.

I'm just starting my education on this topic and I've looked at the OPNsense CARP documentation and also documentation from PF project and I see a disconnect on the WAN side of the firewall cluster.

The OPNsense documentation (see attached image) shows private IP address 172.18.x.x, while documentation from the other project shows public IP addresses 198.51.100.200-202 (see attached image).

I'm trying to rationalize the discrepancy between the documentation. Are 3 real IPs needed or can private IPs be used? In orther words, can HA be achived with one (1)  ISP-assigned IP address via DHCP fed to a switch that then splits that into private IPs as shown in the OPNsense documentation?

Thank you for any advise and insight

4

21.1 Legacy Series / Re: [Solved] Help troubleshooting why DNS over UDP does not reach DNS resolver

« on: May 04, 2021, 04:43:20 am »

I think you meant remove the Port Forward WAN rule.  Outbound NAT should still have a rule (likely Automatic).

That makes sense; you're doing a DNS redirect.  I would disable it and get it working on a PC then work on your redirect.

Thank you disabling this rule worked. I also re-arranged AdGuard's position in the DNS request chain to look like the below.

(all clients on local network) --> AdGuard --> OPNSense (unbound forwarding mode to Quad 9 ips)

Advantage of this setup is I can see which requests are coming from which device ip's on the local network. Disadvantage of this setup is for now I've lost the DoH/DoT/DoQ that is configured out of the box on AdGuard Home and not replicated on Unbound by default.

(1) Install minugmail's repo (see https://www.routerperformance.net/opnsense-repo/), (2) install AdGuard Home plugin in OPNsense, (3) set your OPNsense unbound resolver to another port than 53, (4) go to adguard home webpage to configure, (5) define your OPNsense unbound resolver:customport as a PTR / upstream DNS server in adguard home (for resolution of local names).

(6) Firewall: create floating rules to allow DNS requests to DNS (53), DoQ (784) and DoT (853); consider carefully whether to open DoH (443). NAT rules should be created automatically (I think).

Agreed probably better to drop the Pi altogether and would solve my issue of not having presently having DoH/DoT/DoQ to do swap mentioned above and use of Unbound in forwarding mode. Why do you suggest carefully considering whether to open DoH? Idk hence asking.

5

21.1 Legacy Series / Re: Help troubleshooting why DNS over UDP does not reach DNS resolver

« on: May 03, 2021, 09:00:52 pm »

Hi rhubarb,

Thank will try you suggestion and remove the outbound NAT rule. The reason for the Outbound NAT rule was to enforce use of AdGuard + my choise of outbound DNS rather than permit use of other DNS providers (for example hardlinked DNS servers inside of IoT devices, i've seen alot of requests for 8.8.8.8 from devices).

DHCP address are handed out by OPNsense and AdGuard gets handed a fixed IP based.

6

21.1 Legacy Series / [Solved] Help troubleshooting why DNS over UDP does not reach DNS resolver

« on: May 03, 2021, 02:10:22 pm »

Hello,

I've reached a wall trying to troubleshoot this and hoping the community can help. I've tried searching forum posts for similar issues and haven't found any suggested fix.

I'm using OPNsense 21.1.5 (amd64) to route DNS requests to AdGuard Home (v0.106.1) installed on a raspberry pi (address 10.x.x.240) with Quad 9 as the upstream DNS resolver.

Ignoring the Guestnet VLAN to simplify the troubleshooting process, any DNS requests from my network LAN1  over UDP are not working while any DNS requests over TCP work. I can't figure out why UDP isn't working.

I've attached in image to pictorially represent my setup. For some reason UDP based requests appear to be blocked (see error messages) while TCP based requests.

My firewall rules are fairly basic having followed guides from homenetworkguy.com for guidance. I've attached screenshots of the firewall rules used for LAN along with NAT rules. On the WAN interface I only have rules to Block spamhaus DROP and EDROP.

On the AdGuard Home side there isn't any configuration that I've done that should be blocking requests.

Any suggestions on how to further troubleshoot this to figure out where and why UDP packets are being dropped/blocked?

Thank you,
George

7

21.1 Legacy Series / Re: [Solved] Troubleshooting sporatic connectivity drops

« on: May 03, 2021, 01:05:08 pm »

Possibly related: https://github.com/opnsense/src/issues/107

Thank you the fix posted in that thread seems to have fixed the issue.

8

21.1 Legacy Series / Re: Troubleshooting sporatic connectivity drops

« on: March 03, 2021, 10:52:25 pm »

The issue was present for me in 20.7 as well; did you test any versions before 21.1?

Hi, for me 20.7 and the 20.x branch worked very well and I have only noticed the problem recently with 21.1.1+2.

Thank you for the github link I'm trying 21.7.a_40 in case it works

9

21.1 Legacy Series / [Solved] Troubleshooting sporatic connectivity drops

« on: March 03, 2021, 06:02:49 pm »

Hello all,

I'm trying to troubleshoot a recurring connectivity dropout in both LAN and WAN where for 30-60 seconds I lose connectivity and then without action on my part connectivity is restored. This is happening a few times per day with no pattern.

I've been experiencing these issues since 21.1.1/21.1.2, I can't say it's related and may be coincidental but looking for advice on what I could check to determine the cause.

So far, I've tried using a hardlink ethernet connection after thinking it was WiFi related but I'm still experiencing the same issue whether wirelessly connected or hardlinked.

What I've noticed so far is that when there is a connectivity dropout, even accessing the opnsense admin portal is not possible (login page will show up because it's cached in browswer but it not responsive to any user input).

Any guidance on where to look. Network switches appear to be working fine, other than that I don't know what to check to systematically determine the issue.

Would appeciate any advice you can provide

Thanks,
George

10

17.1 Legacy Series / Re: Advice for integrating WiFi AP with OPNsense router

« on: February 05, 2017, 08:29:07 pm »

Hi Bart,

Thanks for your reply, I did try putting the AP in the basement and it worked, but the connection quality wasn't good in the upper level of our home. The office room is centrally located would offer good coverage throughout the home.

11

17.1 Legacy Series / Advice for integrating WiFi AP with OPNsense router

« on: February 05, 2017, 07:38:18 pm »

Hi,

I've installed OPNsense 17.1 on a pcengines APU2. The APU2 has 3x NICs.

My question:
I'd like to connect a WiFi AP to a spare NIC (NIC #2) on the router to allow wireless clients to connect to the internet. To do this do I need to bridge the internal NIC's together (i.e. NIC 1&2) or do I simply assign NIC #2 a valid internal network ip address (e.g. 192.168.1.100)?

My setup:
The physical setup I'm envisioning is shown in the attached diagram.
NIC #1 (192.168.1.1/24) - connects computers in the basement to the router
NIC #3 (DHCP) - connects the WAN modem to the router

Thank you,
geo