Messages

No one.....
I guess these settings really are a mystery.

I just tested my VPN still running after 24 hours. My DPD settings used are as follows
45 seconds - 5 retries - Restart the tunnel - 10 Keyingtries

Any comments?

Guessing you are using legacy tunnels?

I have a lot of clients with always-on tunnels over a less-reliable ISP (Shaw/Rogers Cable). They generally use a live booking/Client information database app at a central location, and satellite office access it via the tunnel.  I have long (> 7 years) set my DPD to numbers like 31s and 59 retries with "restart the tunnel" as the DPD action.

I'm actually looking to translate these into the new connections settings, and I'm pretty frustrated by the extremely low quality of documentation I've been able to find.

I haven't seen issues earlier to be honest, when suspecting a bug you can always open a ticket on GitHub.

... or ask for this bug to be re-opened
https://github.com/opnsense/core/issues/7416

I am attempting to get monit to send me an alert when an IPsec [legacy] tunnel is down.

I am seeing some behaviours that I do not understand, I'm reluctant to apply the potential solutions I've found during my searching 'til I know better what's going on.

monit shows this in the logs when I disable the tunnel I am attempting to monitor

Code Select Expand


2023-10-29T21:13:30-07:00 Error monit Aborting event
2023-10-29T21:13:30-07:00 Error monit Mail: Delivery failed -- no mail server is available
2023-10-29T21:13:30-07:00 Error monit Cannot open a connection to the mailserver 192.168.254.9:25 -- Operation now in progress
2023-10-29T21:13:30-07:00 Error monit Cannot connect to [192.168.254.9]:25 -- Connection timed out
2023-10-29T21:13:00-07:00 Error monit 'restart_PCC_IPsec_tunnel' ping test failed
2023-10-29T21:13:00-07:00 Error monit Ping response for 192.168.78.254 5/5 timed out -- no response within 5 s
2023-10-29T21:12:55-07:00 Warning monit Ping response for 192.168.78.254 4/5 timed out -- no response within 5 s
2023-10-29T21:12:50-07:00 Warning monit Ping response for 192.168.78.254 3/5 timed out -- no response within 5 s
2023-10-29T21:12:45-07:00 Warning monit Ping response for 192.168.78.254 2/5 timed out -- no response within 5 s
2023-10-29T21:12:40-07:00 Warning monit Ping response for 192.168.78.254 1/5 timed out -- no response within 5 s
2023-10-29T21:12:35-07:00 Informational monit 'gw1.domain.tld' Monit reloaded


Additional information:
1st - the firewall running monit [OPNsense 23.7.7_3-amd64] is at 192.168.17.254
2nd - the mail server is at 192.168.254.9
3rd - the mail server at 192.168.254.9 is reachable from any other host on the 192.168.17.0/24 network

example from a normal host on the LAN:

Code Select Expand


root@ns1:~# ip addr show dev enp0s4 | grep inet
    inet 192.168.17.14/24 brd 192.168.17.255 scope global noprefixroute enp0s4
#
root@ns1:~# ping -q -c 3 192.168.254.9
PING 192.168.254.9 (192.168.254.9) 56(84) bytes of data.

--- 192.168.254.9 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2014ms
rtt min/avg/max/mdev = 14.848/16.489/18.878/1.727 ms
#
root@ns1:~# telnet 192.168.254.9 25
Trying 192.168.254.9...
Connected to 192.168.254.9.
Escape character is '^]'.
220 mx-backup.bisi.ca ESMTP Postfix (Ubuntu)


Example from the shell of the OPNsense box:

Code Select Expand


root@gw1:~ # ifconfig re0 | grep inet
inet 192.168.17.254 netmask 0xffffff00 broadcast 192.168.17.255
#
root@gw1:~ # ping -q -c 3 192.168.254.9
PING 192.168.254.9 (192.168.254.9): 56 data bytes

--- 192.168.254.9 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
#
root@gw1:~ # telnet 192.168.254.9 25
Trying 192.168.254.9...
^C


This description from the netgate docs seems to describe the situation, as well as a fix, but is this really what's going on here?
https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html
https://web.archive.org/web/20231030051250/https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html

I have obtained the same result from 4 other OPNsense firewalls of various generations, both from the shell and from Interfaces -> diagnostics -> ping.

All firewalls can ping (or telnet/ssh) to) hosts outside the firewall, and hosts on their own class C LAN (192.168.17.x in this example).

So - any feedback appreciated (other than to migrate the tunnels to "Connections" I've already incurred *way* too many unbillable hours for this client trying to do just that).  Sorely hoping there's a simpler fix to this issue so I can stop hearing from these clients

[and your situation allows it]

if anybody else is trying to figure out ddclient with dyndns.com, I have figured out what was stopping my very vanilla configuration from working.  See this thread:
https://forum.opnsense.org/index.php?topic=35897
and this:
https://sourceforge.net/p/ddclient/mailman/message/20439031/
Essentially it was the poor password handling of ddclient that broke my >20 year history with dyn(dns).com.  Make sure your password has no spaces and no special characters.  Otherwise ddclient works out of the box.

If you are looking for some fine tuning, and your situation allows it, I would also recommend editing /usr/local/etc/ddclient.conf to use the WAN I/F as the source of the ip address, rather than spamming the dyn.com members server. You would need the WAN port connected directly to the internet, and not behind some other router for this to be useful to you.

When I get a production OPNSense host re-configured (I built a freebsd box as part of the troubleshooting), I will try to remember to update the opnsense 23.7 forum post with an example of what a successful connection looks like from the debug perspective. Knowing *that* would have saved me dozens (or more) hours of fruitless troubleshooting time.

And if anybody figures out how to check dyn.com's logs for their view of the transactions, please let us know (ha ha ha ha ha ha...). Posted their reply to my request for help (which had essentially the same information as the 23.7 forum posting).

after repeated attempts over a number of years, and being stuck between the rock of os-ddclient and the hard place of finding a suitable replacement for dyn.com, I was able, with the timely suggestion of 9axqe to see that my years-old very strong password for all 16 of my clients that need dynamicDNS was the source of the problem.

If you are using os-ddclient, especially with dyndns.com, then I suggest you avoid spaces and @ symbols in your password.

Now, if only dyn.com would allow a per-host password, instead of insisting on one password for all (up to 30) hosts on the account.

do you have maybe a special character in your password that may break parsing and hence prevent reading the last line of ddclient.conf where the FQDN is located?

BINGO!  Thank you for that suggestion.  I have been using that (extremely strong) password for this purpose for so long that I never even considered it as a potential issue.  I'm guessing it was either the spaces or the @ symbol.  Not going to experiment to find out, either, ' cause now I have 15 other OPNSense routers that have a broken os-dyndns plugin.  At least I can get os-ddclient installed and working before I upgrade those.

Cheers!
d.

Just out of curiosity, why didn't you configure using the GUI?

I did configure os-ddclient using the GUI. I have done that at every major upgrade and several minor upgrades of OPNSense for a number of years now, never with any success. The syslog detail was insufficient to do much troubleshooting.  So, what I have posted is the verbose debug output derived from using the GUI-configured ddclient.conf file (which looks *very* unlike the one proposed by the dyndns client configurator).  The debug output is obtained by shutting down the daemonized ddclient, and running the noted command in the shell.  The extra detail didn't mean anything to me, hence the posting.

[/usr/local/etc/ddclient.conf]

Well, push has finally come to shove.  I have 15 clients hosted at dyn.com (formerly and a.k.a. dyndns) for which I have repeatedly failed to get os-ddclient to work.  I no longer have the luxury of relying on the os-dyndns plugin. I am faced with a hardware replacement scenario, and I might as well bite the bullet.  I have a new protectli-hosted OPNsense 23.7.3-amd64; FreeBSD 13.2-Release-p2; OpenSSL 1.1.1v 1 Aug 2023.

Everything restored perfectly from backup, excluding of course the os-dyndns plugin. So I've added os-ddclient, and it has reliably failed out of the gate.  After several unproductive troubleshooting attempts, including a file generated by dyn.com's "upate client configurator" https://account.dyn.com/tools/clientconfig.html, I have, per some successful ddclient troubleshooting on the FreeBSD forums, reached an error message that I can't get past, and a large amount of internet searching has not provided any clues.  The basic idea that worked with native FreeBSD does not work here.  I always end up with this message:

Code Select Expand

FAILED:   updating N0T: notfqdn: A Fully-Qualified Domain Name was not provided

So I've reproduced the logs and the troubleshooting in the hope that someone here can elucidate, or suggest something to try, or at least a clue where the problem originates.

The starting conditions:
The OPNSense host is named bogus1.dyndns-at-home.com
There is a DNS record at dyndns.com of the same name, with the IP address of the machine before the hardware failure, from a different ISP

I have os-ddclient set with these parameters:

Code Select Expand

Edit Account
Enabled               < X >
Description           https://account.dyn.com/
Service               DynDNS.com
Username              <redacted>
Password              <redacted>
Wildcard              <  >
Hostname(s)           bogus1.dyndns-at-home.com
Check ip method       Interface
Interface to monitor  WAN
Check ip timeout      10
Force SSL             < X >

Which creates this config file ( /usr/local/etc/ddclient.conf ):

Code Select Expand

syslog=yes                  # log update msgs to syslog
pid=/var/run/ddclient.pid   # record PID in file.
ssl=yes

usev4=ifv4, ifv4=igb0, \
protocol=dyndns2, \
login=<redacted>, \
password=<redacted> \
bogus1.dyndns-at-home.com

Now, get shell access as root via SSH
stop the daemonized ddclient

Code Select Expand

kill -TERM `cat /var/run/ddclient.pid`
verify the .pid file is gone

Code Select Expand

cat /var/run/ddclient.pid
  cat: /var/run/ddclient.pid: No such file or directory
purge the ddclient cache

Code Select Expand

rm /var/tmp/ddclient.cache
run ddclient in debug mode, in the foreground (per FreeBSD troubleshooting)

Code Select Expand

ddclient -daemon=0 -debug -verbose -noquiet

This also fails to update the ip address at dyn.com, ending with the usual.

Code Select Expand

FAILED:   updating N0T: notfqdn: A Fully-Qualified Domain Name was not provided

I have attached two files:
ddclient_debug_output - the output from the debug screen
ddclient_syslog.log - the "all levels" output recorded by syslog during the exercise.

Any help greatly appreciated!
d.

Ah, now I see more clearly, thanks for the clarification regarding OpenSSL 3.

Let me sort that out then. So users using the community client have the following options until OPNsense moves to OpenSSL 3. Clarifications and additions are welcome.

1. Stay with client version 2.5.x as long as support is guaranteed (July 2023?).
https://community.openvpn.net/openvpn/wiki/SupportedVersions

2. Use client version 2.6.x, with "providers legacy default" in client config.

3. Choose export type "File only", without possibility to protect the user certificate and private key with a password.

Can confirm with win10 OpenVPN GUI (community edition) v2.6.0 that appending

Code Select Expand

providers legacy default
to the config file named CLIENT_userID.ovpn
stifled the requirement for an encrypted CLIENT_userID.p12 file.

That is, the dialog box "OpenVPN - Private Key Password (CLIENT_..." did not appear, and the connection was made as it has always been.  screen shot of the offending dialog box attached, just to remove all doubt

It is my own experience that ddclient does *not* work with paid accounts at dyn.com on OPNSense.  I have 15 clients using the os-dyndns plugin, and have been so doing for many years (long pre-dating opnsense).

I have become increasingly jumpy about the notices in the opnsense updates that the os-dyndns plugin will be discontinued (it is not being updated, from what I can determine), and have made sporadic attempts to get the supposedly-supported ddclient working on my clients' machines, and have always had to give up in favour of actually working code.

I have another deployment at hand that will require dynamic DNS, and have yet again tried and failed to get ddclient working (OPNSense 23.1.3).  My logs show similar failures to your own.  This is the only thread that references both dyndns (the actual service) and ddclient, other than my forlorn post in December.  There are indications that freebsd users have had success, but that has a whole lot of extra flexibility, not available to OPNSense users (like being able to persist some of the troubleshooting parameters in the ddclient.conf file).  Anyway, if I'm not called away by other priorities, I'll try yet again and document what I've done here, and perhaps we can get a little closer to a functional plugin.

There *is* another post in January from franko, one of those that makes me jumpy...
https://forum.opnsense.org/index.php?topic=32081.0

Dear members

i have a lenovo desktop sff m93p with one lan and internal wifi

i want to use the <ethernet> port as wan and the wifi as lan so i can share internet with wifi

To echo lilsense's question, did you make any headway on this?  Still trying? 

If so, I succeeded with an m93p tiny that came through my hands on its way to a different configuration.  It had an intel wifi chipset.
This link might help you decide if it is worth the effort with yours:
https://man.freebsd.org/cgi/man.cgi?query=iwn&sektion=4&format=html

If your m93p has a broadcom wifi chipset, then it's probably not worth the effort, unless you want to learn *a lot* about customizing FreeBSD kernels and how OPNsense builds upon it ;-)
https://forums.freebsd.org/threads/bcm4322-wifi-card-freebsd-11-2-not-working.68103/
https://www.reddit.com/r/freebsd/comments/ye42e5/stuck_on_starting_wpa_supplicant_at_boot/

As a general rule, I avoid wifi in the OPNsense boxes I deploy, as the integral wifi in any router (not just opnsense) integrates poorly with the inevitable expansion needed in wifi coverage (unless it's designed to be a mesh system).  This eventuality is much better handled with inexpensive WAPs connected by ethernet (or as a mesh network with at least the base station connected by ethernet).  Since your m93p likely has "One half size mini-PCIe slot (only supports WIFI card)", getting such a card might be an easy and relatively cheap way to get an intel wifi chipset into the box. https://www.newegg.com/p/pl?d=lenovo+pci+express+half+mini+card  Before buying, be sure to verify with the specs for your particular device that you are getting a supported card.

if you just want a wifi router (vs a state-of-the-art firewall), then Bunch's suggestion to use openwrt makes eminent sense.

Unfortunately, it appears one can't upgrade the m93p to have two ethernet ports, so I'll never be deploying one of these particular computers as an OPNsense firewall.

Cheers!
d.

<deleted>
issue fixed at next update from 23.1, which had this patch note:
firewall: prevent possible infinite loop in alias parsing (contributed by kulikov-a)

The only way I guess should work is build under VM (esxi, pve, XCP-NG, etc.)

ummm, why not on bare metal?  something going wrong with the install?

... or at least a web link where I can check every so often?

I have been using dyn.com since they had free accounts (and were called dyndns.org), sometime around the turn of the century.  Anyway, I have quite a large number of clients supported through my account at dyn.com, and I'm getting pretty antsy at the warning that support for os-dyndns is about to be terminated.

I have tried and failed several times to switch to os-ddclient and have it work with my clients using OPNsense/dyn.com, and several browsing sessions on the forums has not enabled me to come up with a reliable recipe/hack, plus a fear that I'm going to have to migrate everyone to another service, in a hurry, when os-dyndns finally joins IE 11 in the bitbucket.

Dyn.com has support instructions for ddclient at https://help.dyn.com/ddclient/, but my I'm really not into leaving my clients with invisible hacks that nobody but me can support in an emergency. Also I don't know how to persist this through upgrades, etc. Finally, the "issues to be aware of" section of those instructions fairly drip with unbillable time.

Any suggestions welcome (including alternate dynamic DNS services with good records, and decent management interfaces for 30 or so names)!

This may or may not be an issue, but I noticed some missing dependencies during the remote upgrade. It came back up and says it is up to date. More of an FYI if this is serious.
...
Message from php74-7.4.28:
===>   NOTICE:
This port is deprecated; you may wish to reconsider installing it:

Upstream Security Support ends on 2022-11-28.
It is scheduled to be removed on or after 2022-11-29.
=====
...
Owl be watching you
Checking integrity... done (0 conflicting)
Nothing to do.
Checking all packages: .......... done
elasticsearch5 has a missing dependency: openjdk8
elasticsearch5 has a missing dependency: jna
py37-markupsafe has a missing dependency: python37
py37-markupsafe has a missing dependency: py37-setuptools
py37-markupsafe is missing a required shared library: libpython3.7m.so.1.0

>>> Missing package dependencies were detected.
>>> Found 4 issue(s) in the package database.

pkg-static: No packages available to install matching 'openjdk8' have been found in the repositories
pkg-static: No packages available to install matching 'jna' have been found in the repositories
pkg-static: No packages available to install matching 'python37' have been found in the repositories
pkg-static: No packages available to install matching 'py37-setuptools' have been found in the repositories
>>> Summary of actions performed:

openjdk8 dependency failed to be fixed
jna dependency failed to be fixed
python37 dependency failed to be fixed
py37-setuptools dependency failed to be fixed

>>> There are still missing dependencies.
>>> Try fixing them manually.
>>> Also make sure to check 'pkg updating' for known issues.
...

You all may find a helpful starting point at this post:

https://forum.opnsense.org/index.php?topic=26618.0