OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of 9axqe »
  • Show Posts »
  • Messages
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Messages - 9axqe

Pages: [1] 2 3 ... 14
1
Documentation and Translation / Re: AdGuard Home setup guide
« on: December 02, 2024, 10:01:17 am »
I use AdGuard only on the LAN bridge intf, not on the WAN, but I do use IPv6 as well and I do not see udp46 and tcp46, only udp4, tcp4, udp6 and tcp6. According to my search-fu this is a socker that can handle both IPv4 and IPv6. Didn't even know that existed...

2
General Discussion / Re: Alerting without emails?
« on: November 29, 2024, 07:58:21 am »
Old topic but in case anyone stumbles on it, mailrise is also an option. It takes SMTP email traffic and turns it into notifications.

3
Tutorials and FAQs / Re: HOWTO - Redirect all DNS Requests to Opnsense
« on: November 05, 2024, 11:01:31 am »
What does your server use in terms of DNS protocol? HTTPS, QUIC, TLS...?

If it's using DNS over HTTPs for example, you're going to have to block 8.8.8.8:443 (both UDP and TCP).

If you want to go down that route, there are lists of public DNS over HTTPS/TLS providers, such as https://public-dns.info/nameservers.txt, which you then need to configure as FW aliases.

For DNS over TLS or QUIC it's simpler, you simply block anything to port 853 or 8853 (no point in redirecting, the certificate would not match).

4
Tutorials and FAQs / Re: HOWTO - Redirect all DNS Requests to Opnsense
« on: November 03, 2024, 08:30:14 pm »
That's what I'm doing, yes.

5
Tutorials and FAQs / Re: HOWTO - Redirect all DNS Requests to Opnsense
« on: November 02, 2024, 07:51:08 am »
I did a redirect, just in case there’s some badly configured device on the network with static DNS server IP.

6
24.7 Production Series / Re: Migrating to vlans
« on: October 28, 2024, 02:02:19 pm »
>What is the purpose of the bridge of which igb1 is a member? What other members are there?

There was LAN1 and LAN2 that's it, because I had two devices plugged into opnsense at some point. But since I now have a managed switch, I can move away from it and I do not need a bridge anymore.

I'm all for VLAN1001, that's fine for me, IF the managed switch can take untagged traffic in the 192.168.1.0/24 subnet and transform this in tagged VLAN1001 traffic on the trunk toward sense. I need to check if openwrt is able to do this, I think it should be possible though.

7
24.7 Production Series / Migrating to vlans
« on: October 28, 2024, 01:42:50 pm »
Hello all,

it's my second attempt at migrating, the first one wasn't very successful, probably due to lack of preparation.

I have a very simple network, with 192.168.1.0/24 (and IPv6, but let's just consider IPv4 for this, I think I can extrapolate IPv6 config from there). I intend to make this VLAN1. I know best practice is to have a separate VLAN for mgmt, but we're talking about a home, I don't want to switch SSID just to connect to a device in my home – and many of my IoT are unable to separate mgmt and user traffic anyway...

Requirements:
1. keep existing IP/DHCP config and make this VLAN1 / native VLAN.
2. introduce a vlan for guest wifi (VLAN10, 192.168.1.10/24)


I don't really need a LAGG interface, I don't expect more than gigabit on the network (it's a home network).
The switch in front of the opnsense is managed, it's running a recent openwrt and I configured one port to tag both VLAN1 and VLAN10

So far, what I plan:
* remove LAN2/igb2 assignment
* create VLAN intf "vlan0.10" with parent interface igb2, and static IPv4 192.168.10.1
* assign igb2, interface will be now named "igb2_vlan10_GUEST"

Now I'm a little stuck as to how I assign VLAN1 (192.168.1.0/24) to igb2 as well.

Currently, all traffic is coming via LAN1/igb1, which is also part of a bridge. What would be the recommended approach to move this to igb2 as well?

8
General Discussion / Re: cloudflare tunnel over GRE
« on: October 26, 2024, 09:53:47 am »
Seems to me there's (now) a typo on the page.

The page used to look like this a couple of months back:

https://web.archive.org/web/20240202030437/https://www.jackpearce.co.uk/cloudflared-opnsense/

You can clearly see that the line

Code: [Select]
: ${cloudflared_conf:="/usr/local/etc/cloudflared/config.yml"}
is removed in the "/usr/local/etc/rc.d/cloudflared" file.

On the current version though, the line is not removed any more, which contradicts the accompanying text which states "We’re just removing ${cloudflared_conf} from the command arguments".

I just added # at the beginning of this line to comment it out – I prefer it to deleting the line.

I'm not sure what you meant by "I can't seem to get to the config.yaml portion" though, so I'm not sure my comment helps.

9
Documentation and Translation / Re: AdGuard Home setup guide
« on: October 23, 2024, 08:48:30 am »
I made the experience that AdGuard stopped working when internet was down (not even resolving local DNS) and that having unbound as upstream DNS worked around this issue.

I still run it like this, but that was a while back.

There's also a whole debate about using a recursive DNS resolver vs. using a DNS client.

1/ AdGuard is a simple DNS client to whatever is upstream (you can configure Cloudflare DNS, Google DNS, et,).

Con: whatever is configured upstream sees every single DNS query you make
Pro: DNS lookups are all encrypted (if you configure it) – but this is of limited use until all your connections are made with QUIC, as the full domain is still transmitted in clear text (I believe it's the SNI) for every TLS handshake.

2/ Unbound is a recursive DNS resolver, meaning, it will talk to multiple different DNS servers, depending on what you are trying to resolve. For example, if attempting to resolve "example.com", it will talk to the authoritative server for ".com" and ask "who is authoritative for example.com". And so on.
Con: not all DNS servers out there support DNS over HTTPS/TLS/QUIC, resulting in plain text DNS lookups.
Pro: there is no single entity seeing all your DNS lookups.

My view is that 2/ is what will be the best method in the long term, as DNS over QUIC and QUIC in general gain popularity. But as of today, YMMV.

10
General Discussion / UniFi controller cannot access keystore after ACME cert update
« on: October 21, 2024, 06:10:15 pm »
My opnsense letsencrypt cert renewed 2 days ago, and the ACME automation updates the cert in the UniFi keystore, as it always does.

I recently update the UniFi plugin, maybe that's related.

These are some logs I can see under /usr/local/share/java/unifi/logs/server.log:

[2024-10-21T17:37:45,968+02:00] <main> INFO  system - [internal] unable to set file permission on /usr/local/share/java/unifi/data/keystore: /usr/local/share/java/unifi/data/keystore: Operation not permitted
[2024-10-21T17:37:45,984+02:00] <main> INFO  system - [internal] unable to set file permission on /usr/local/share/java/unifi/data/keystore_original: /usr/local/share/java/unifi/data/keystore_original: Operation not permitted
[...]
[2024-10-21T17:39:42,557+02:00] <ble-load-keystore> WARN  blebridge - unable to load local keystore for BLE bridge /usr/local/share/java/unifi/data/keystore (Permission denied)


I noticed the keystore is owned by root:wheel somehow, while other files in the same directory are owned by user unifi:

Code: [Select]
root@opn:~ # ll /usr/local/share/java/unifi/data/
total 86
drwx------  3 unifi wheel     5 Oct 15 14:03 backup/
drwx------  4 unifi wheel   365 Oct 21 17:55 db/
drwx------  3 unifi wheel     4 May 18 03:54 firmware/
-rw-------  1 unifi wheel 26177 Oct 21 17:40 firmware.json
-rw-r-----  1 root  wheel  3029 Oct 19 00:01 keystore
-rw-r-----  1 root  wheel  3029 Oct 19 00:01 keystore_original
-rw-------  1 unifi wheel  1424 Oct 21 17:39 model_lifecycles.json
drwx------  3 unifi wheel     3 May 19 10:06 sites/
-rw-------  1 unifi wheel  1393 Oct 21 17:39 system.properties
-rw-------  1 unifi wheel  1393 Oct 21 17:39 system.properties.bk
-rw-------  1 unifi wheel 76067 Oct 19 01:03 uidb.json

I ran

Code: [Select]
chown unifi:wheel /usr/local/share/java/unifi/data/keystore
chown unifi:wheel /usr/local/share/java/unifi/data/keystore_original

restarted the unifi service and it seems to fix the issue.

My problem is, the next cert renewal in 2 months will cause this to fail again I expect.

I would like to check the command used to update the keystore but I'm not sure where this is defined. Pointers welcome.

11
24.7 Production Series / Re: rc.conf not starting cloudflared at bootup anymore
« on: October 13, 2024, 01:07:21 pm »
I did, there's not a single line when the router boots up. As if the /etc/rc.conf file wasn't even read on startup anymore...

12
24.7 Production Series / Re: Huge current_arp_table6.txt full of redundant lines
« on: October 11, 2024, 10:31:53 am »
Already found the culprit, I think. Seems OPN-Arp is causing this, the file stops growing when I stop the service.

13
24.7 Production Series / Huge current_arp_table6.txt full of redundant lines
« on: October 11, 2024, 10:28:27 am »
I noticed that there's a "sort -u /tmp/current_arp_table6.txt" process that is often shooting up in terms of CPU usage on my opnsense, so I checked the size of the file.

it appears there is 110 unique entries (checked using "sort /tmp/current_arp_table6.txt | uniq | wc -l") but there is 1.7 millions lines in total, so there's some cleanup not working.

Any idea where I can do some manual cleanup to start?

14
24.7 Production Series / rc.conf not starting cloudflared at bootup anymore
« on: October 07, 2024, 12:51:57 pm »
This used to work and stopped somewhen in the last month or two, not entirely sure when.

I have configured cloudflared service to start at boot up in rc.conf:

Code: [Select]
cloudflared_enable="YES"
cloudflared_mode="tunnel --no-autoupdate run --post-quantum --token <my_token>"

But it does not seem to work. If I manually start it, it works fine:

Code: [Select]
/usr/sbin/daemon -o /var/log/cloudflared.log -p /var/run/cloudflared.pid -f /usr/local/bin/cloudflared tunnel --no-autoupdate run --post-quantum --token <my_token>
Has something changed in 24.7 in regard to rc.conf?

15
General Discussion / Re: cloudflare tunnel over GRE
« on: October 07, 2024, 12:44:48 pm »
The correct path is /usr/ports/net/cloudflared

Pages: [1] 2 3 ... 14
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2