Topics

1

22.1 Legacy Series / [SOLVED] Unbound not responding?

« on: July 08, 2022, 11:42:21 am »

tl;dr: Unbound doesn't appear to be responding properly to DNS queries, though DNSmasq does.  I suspect it's related to my multi-WAN setup, but I haven't been able to figure out where.

I'm running OPNsense 22.1.10; I was seeing the same behavior under 22.1.9.

Unbound won't respond to queries via dig; I get the same result using the shell on the OPNsense box itself or via a remote client:

Code: [Select]

root@opnsense:~ # dig @localhost google.com

; <<>> DiG 9.18.4 <<>> @localhost google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2147
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(localhost) (UDP)
;; WHEN: Fri Jul 08 04:33:05 EDT 2022
;; MSG SIZE  rcvd: 39


Code: [Select]

✘ dan@Dan-Mac-Mini-2  ~  dig @192.168.1.1 google.com

; <<>> DiG 9.10.6 <<>> @192.168.1.1 google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3653
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com. IN A

;; Query time: 1 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 08 04:32:37 EDT 2022
;; MSG SIZE  rcvd: 39
But when I do a DNS lookup through the web UI (Interfaces/Diagnostics/DNS Lookup), I do get a result.

The background is a little confusing, but since the problem seemed to start when I plugged in my main WAN connection, I'll try to explain as clearly as I can.

I have three Internet connections available: Cable (with a static IP) for the primary, Starlink (in bridge mode) for secondary, and cellular is third.  I'm setting up this system to replace a pfSense box, so I was trying to configure everything (or at least as much as possible) under OPNsense before moving my main home Internet connection to it.

So, initially, I put Starlink on the main WAN connection (using DHCP), and the cellular modem on WAN2 (also using DHCP), and then proceeded to set up WAN failover following https://docs.opnsense.org/manual/multiwan.html#wan-failover.  This appeared to work--I didn't actually test the failover functionality, but I had Internet access through the router, and no apparent problems with Unbound.

But realizing that my main Internet connection didn't use DHCP, I disconnected the cellular modem, moved Starlink to WAN2, and configured WAN for my static IP, leaving WAN disconnected.  This required reconfiguration of the gateway list, since there wasn't a WAN_DHCP gateway any more.  This also appeared to work; Internet access continued to be available, and Unbound continued to respond to queries as normal.

Yesterday afternoon, thinking I had everything preconfigured that I was going to be able to, I plugged my cable modem into WAN, and LAN into my switch.  And at that point, Unbound stopped working.  When I turned it off and turned on DNSmasq, it worked (and continues to work) just fine, and Internet access works well, but with Unbound enabled it no longer seems to be able to resolve DNS queries.

I've tried checking log files, but I don't see anything logged anywhere that's associated with the failing queries.  Where else should I be looking?

2

20.7 Legacy Series / Can't reach OpenVPN clients from LAN

« on: August 22, 2020, 11:54:52 am »

tl;dr: Clients on my LAN can't connect to OpenVPN clients through OPNsense, but OpenVPN clients can reach hosts on my LAN.  I can reach OpenVPN clients (i.e., ping them) from OPNsense itself.  This started around the time I configured multi-WAN failover and upgraded to 20.7.1.

Networks:

LAN: 192.168.1.0/24
OpenVPN: 192.168.3.0/24
WAN: static IP
WAN2: 192.168.5.something (assigned by DHCP, but in that subnet)

I'm running an OpenVPN server on my OPNsense box, primarily for the sake of two remote hosts that need to be able to access services on my LAN.  At the same time, some devices on my LAN need to be able to access one of those remote hosts.

This all worked well for quite a while--on pfSense before I moved to OPNsense, then it worked under 20.1.8 and 20.1.9, and when I upgraded to 20.7 it continued to work.  Around a week ago, though, following my fourth multi-hour Internet outage in several weeks, I set up multi-WAN failover with a cellular modem (following the instructions at https://docs.opnsense.org/manual/how-tos/multiwan.html), and I also updated to 20.7.1.  And since about that time (I can't say for certain if the problem started with one or the other of these changes, but it started about the time I made them), clients on my LAN aren't able to reach the remote host via the VPN.

Specifically, the remote host is at 192.168.3.100.  If I ping that IP from my OPNsense box itself, it reaches it just fine.  But if I ping it from anywhere else on my LAN, I just get timeouts.  My Google-fu is apparently weak here; I get lots of hits about routing from VPN clients to the LAN (which already works), but nothing about routing from the LAN to those clients.  Any ideas on where to start looking?  Settings attached if they help.  I tried adding the "IPv4 remote network" as you see in those settings, but it didn't help--I'm getting the same results.

3

20.7 Legacy Series / OpenVPN both running and not running?

« on: August 05, 2020, 01:40:46 pm »

I've been having a few problems with OPNsense since I installed it, that I haven't been able to sort out.  My problem with ntpd (https://forum.opnsense.org/index.php?topic=18253.0) seems to have stumped the experts, so here's another one: OpenVPN.

I've set up an OpenVPN server on my OPNsense box  I have two remote computers connected to that server full-time, on the VPN subnet.  I know they're connected, because they're able to run backups to my FreeNAS server on my LAN every day.  But both the services widget in the dashboard, and the OpenVPN widget, say the service isn't running--see the attachments for screen shots.

A little stumped here on what to be checking--any thoughts?

Edit: The process appears to be running:

Code: [Select]

root@opnsense:~ # ps aux | grep vpn
root     6744   5.5  0.2 1066500  7996  -  Rs   Fri13    509:10.81 /usr/local/sbin/openvpn --config /var/etc/openvpn/server1.conf
root@opnsense:~ #
Not sure if there's anything out of the ordinary in the log file:

Code: [Select]

root@opnsense:/var/log # tail openvpn.log
Aug  5 06:46:36 opnsense openvpn[14976]: OpenVPN 2.4.9 amd64-portbld-freebsd12.1 [SSL (OpenSSL)] [LZO] [LZ4] [MH/RECVDA] [AEAD] built on Jul 28 2020
Aug  5 06:46:36 opnsense openvpn[14976]: library versions: OpenSSL 1.1.1g  21 Apr 2020, LZO 2.10
Aug  5 06:46:36 opnsense openvpn[91988]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/server1.sock
Aug  5 06:46:36 opnsense openvpn[91988]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Aug  5 06:46:36 opnsense openvpn[91988]: Diffie-Hellman initialized with 4096 bit key
Aug  5 06:46:36 opnsense openvpn[91988]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  5 06:46:36 opnsense openvpn[91988]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Aug  5 06:46:36 opnsense openvpn[91988]: ROUTE_GATEWAY 96.68.219.30/255.255.255.252 IFACE=igb0 HWADDR=00:08:a2:0a:d5:04
Aug  5 06:46:36 opnsense openvpn[91988]: TUN/TAP device ovpns1 exists previously, keep at program end
Aug  5 06:46:36 opnsense openvpn[91988]: Cannot open TUN/TAP dev /dev/tuCLOG? ??root@opnsense:/var/log #


4

20.1 Legacy Series / ntpd both running and not running?

« on: July 25, 2020, 05:51:53 pm »

I recently installed OPNsense (currently on 20.1.9), and it's working well, though with a few oddities.  One of them is that, at least from what the web UI shows, the ntpd service won't start.  The dashboard shows:
(see attachment)
...and in what's probably the relevant section, the log shows:
(see other attachment)

And indeed, there is a process listening on *:123, but it's ntpdate, not ntpd:

Code: [Select]

root@opnsense:~ # sockstat -l | grep :123
root     ntpdate    77157 4  udp6   *:123                 *:*
root     ntpdate    77157 5  udp4   *:123                 *:*
root@opnsense:~ # service ntpdate status
Cannot 'status' ntpdate. Set ntpdate_enable to YES in /etc/rc.conf or use 'onestatus' instead of 'status'.
root@opnsense:~ # service ntpdate onestatus
ntpdate is not running.
Something's strange--what should the next steps be to track this down?

5

Tutorials and FAQs / Automatic config backups using os-api-backup

« on: July 23, 2020, 12:09:17 pm »

I just migrated from pfSense to OPNsense.  Under pfSense, I had my FreeNAS box running a daily script to download a config file backup from the pfSense box, using the method recommended in their own docs.  It was a little messy.  OPNsense has the os-api-backup plugin, which makes the process (especially the script) much simpler.  However, I didn't see everything pulled together in one place, so here goes:

Assumptions:

• You have a Unix-y machine (Linux, BSD, macOS, maybe even Windows Subsystem for Linux) to run the backup script on
• The WebUI cert on your OPNsense router is trusted on that Unix-y machine
• curl is available on that Unix-y machine

That's really it, so let's get started.

First step, of course, is to install the os-api-backup plugin if it isn't already installed.

Next, you'll want to create a group with limited permissions.  In the OPNsense WebUI, go to System -> Access -> Groups and add a new group (I called mine backup).  Save the group, then edit it.  On the edit screen, under Assigned Privileges, click the edit button, find "Backup API" in the list, and check it.  Leave everything else unchecked and click Save.  Click Save again to return to the Groups screen.

Now create a user in that group.  Go to System -> Access -> Users and add a new user (I called mine, creatively enough, backup_user).  I generated a long random password using my password manager, and then discarded it--this user will never log in using that password.  Add the user to the backup group and save.  Then edit the user, find the API keys heading, and click + to create a new one.  This will download a small text file containing an API key and a secret, save it someplace convenient.  Click Save to return to the users screen.

That's all you need to do in the OPNsense UI.  Now it's time to create the script.

Go to whatever machine you're going to use to run the backup script, fire up your favorite text editor (I like nano--don't judge me), and create the script.  Contents are as below:

Code: [Select]

#!/bin/bash
KEY="api_key"
SECRET="api_secret"
HOST="opnsense_hostname"
PATH="/path/to/backups"

curl -s -k -u $KEY:$SECRET https://$HOST/api/backup/backup/download \
 -o $PATH/opnsense-config-$(date +%Y%m%d).xml

find $PATH/ -type f -name '*.xml' -mtime +30 -exec rm {} \;No doubt it's obvious, but edit the variables at the top to match your environment.  This will save the backup files with a filename of "opnsense-config-yyyymmdd.xml", and delete everything over 30 days old.

Set up a cron job to run this on your desired schedule, and you're set

6

20.1 Legacy Series / Installation on ZFS

« on: July 20, 2020, 06:50:29 pm »

I'm looking at moving from pfSense to OPNsense, but I'm a definite fan of pfSense's root-on-ZFS installation option.  I don't see that in OPNsense, unless it's hidden somewhere--it's certainly not as prominent as it is in the FreeBSD 11.2 installer.

But OPNsense has the bootstrap installer, so I can install FreeBSD 11.2 on ZFS and then run that script, right?  I've tested it, and it seems to work--at least to the point of being able to pull up the OPNsense web GUI.  But I'm a little concerned, since the documentation says:

What it will also do is turn a supported stock FreeBSD release into an OPNsense installation, given that UFS was used to install the root file system.

Am I setting myself up for trouble here?  Is this an obsolete caveat in the manual?  Or is something else going on?