Messages

When I disable my vpnclient (and only have my WAN in my WAN Group) and restart OPNSense WAN comes online, when I remove my WAN group and reboot it also comes online.
My vpn has 'Disable Gateway Monitoring' enabled.
Looks like (but I'm not an expert ;) ) that the option 'Disable Gateway Monitoring' might not be honored.

I have 2 OpenVPN clients configured.
On 22.7.11 they stayed connected (according to the webinterface anyways), but on 23.1 they keep reconnecing every few minutes.
Besides updating nothing changed.
Also the time it takes to connect the vpn seems way longer than before.
Everytime a vpnclient drops the connection I get a notification. At v22 I received none, now my mailbox gets flooded.

Is there a setting I had to alter (and obviously forgot) or is there another explanation?

TIA!

Login via ssh as root and try:

Code Select Expand

sh -x /usr/local/etc/rc.d/os-udpbroadcastrelay start

That should give you a hint at what exactly is failing.

That gave me

Code Select Expand

IP_ADD_MEMBERSHIP on rcv: Invalid argument
I had 192.168.70.255 as multicast address. Removed it and the line turned green and the service started.
Needed to add a rule to allow (in my case udp/5901) traffic to other vlan.
For my ChromeCast this was not needed to add additional firewall-rules (but the broadcast address there is: 224.0.0.251).

Running 22.1.r2 and I'm having some difficulty getting it to run:

Code Select Expand

2022-01-24T16:48:55-06:00
root /usr/local/etc/rc.d/os-udpbroadcastrelay: WARNING: failed to start osudpbroadcastrelay

Are there any known compatibility issues known at this moment?

I have the same issue, for all but the first rule...
No other logging available, unfortunately...
How can I find out what is causing this?
(Running on latest - OPNsense 22.7.1-amd64)

I got the same issue...
In my case ssh-sessions get killed, because after the first allow it is followed by denials.
I read somewhere this might be caused by packages being out of order/sequence.
Could this be caused by my use of vlans and a switch? (Although one system is also connected through the same switch and that one works fine.)

Changed the script to also echo the value returned with 'ifconfig'.
When I stop the openvpn client it changes the value, but when the client is started the value remains the as if the client is stopped....
(Running the script from commandline works fine, OPNSense seems to have an issue with updating the value...)
Also using another script that does a wordcount on the result of ifconfig only changes on the first status change, after that it keeps that value... Also echoing the result of ifconfig here returns the value of the client being stopped. (Also this script works fine on commandline.)

What is the cause of this behaviour?

For a couple of days I've been trying to get Monit to monitor my openvpn-client and (re)start the client if needed.
According to the monit manual this should work:

Code Select Expand

check network vpn_cl_openvpn interface vpn_cl_openvpn
   start program = "/usr/local/sbin/pluginctl -s openvpn start 3"
   stop program = "/usr/local/sbin/pluginctl -s openvpn stop 3"
   if check network vpn_cl_vpn interface ovpnc3 then alert
The logging however says

Code Select Expand

/usr/local/etc/monitrc:33: syntax error 'check network'.
Can anybody help me fix this (and get the monitoring working  ;D)?

-- EDIT

Tried the manual approach....

Apparently the gui does not work well...
When I enter this

Code Select Expand

check network vpn_cl_openvpn interface vpn_cl_openvpn
   start program = "/usr/local/sbin/pluginctl -s openvpn start 1"
   stop program = "/usr/local/sbin/pluginctl -s openvpn stop 1"
   if link down then restart
in /usr/local/etc/monitrc and test (and run) it it is fine. The gui, however, gives me an error the syntax is wrong, the interface does not exist and the tab 'Status' shows me the link is down.
Also the log spams me with this

Code Select Expand


2022-06-12T20:28:31 Informational monit 'vpn_cl_openvpn' start: '/usr/local/sbin/pluginctl -s openvpn start 1'
2022-06-12T20:28:31 Informational monit 'vpn_cl_openvpn' stop: '/usr/local/sbin/pluginctl -s openvpn stop 1'
2022-06-12T20:28:31 Informational monit 'vpn_cl_openvpn' trying to restart
2022-06-12T20:28:30 Error monit 'vpn_cl_openvpn' link data collection failed -- Cannot udate network statistics -- interface vpn_cl_openvpn not found

I have tried changing the interface to ovpnc1 (the name it has according to ifconfig), then the gui does not give me errors but does not (re)start the openvpn-client (although the service is stopped).

-- EDIT 2 --
Tried it with running a script which returns 1 when the interface is down en 0 when it is up.
The value 1 makes the openvpn service start (as described above), but Monit keeps the value 1 and thus restarts the interface every 2 minutes...

I can't believe the integration of Monit in OpnSense is that crippled... What am I missing?

Since a couple of weeks I get the following error:

git-backup unknown error, check log for details (remote: remote: Gitea: branch master is the default branch and cannot be deleted To https://git.domain.org/mine/opnsense.git ! [remote rejected] master (pre-receive hook declined) error: failed to push some refs to 'https://git.domain.org/mine/opnsense.git'; )

If I create a new branch, the backup is created successfully but the branch is removed directly afterwards.
Removing and reinstalling did not resolve this.
Anyone got an idea how to fix this?

tried that, but I still get

Code Select Expand

1627146179.753839: critical: error opening channel: No such file or directory
1627146179.753911: critical: error opening channel
1627146179.753959: critical: failed to create guest agent channel
1627146179.753978: critical: failed to initialize guest agent channel
What am I missing?? :-[

--edit
nvm... found it... forgot to enable qemu guest agent in Proxmox for vm...

Every 32 hours my WAN connection goes down for 1 minute... As such not a big issue, but during calls it's a PITA...
The renewal time of the ipaddress is 4 days, but it gets renewed every 32 hours...
Where can I change this behaviour?

And more importantly, how can I prevent the connection to go down for 1 minute.
In the logging I found this, but this does not hint me in the right direction:

Code Select Expand

2020-11-25T17:30:14 opnsense[30029] /usr/local/etc/rc.newwanip: On (IP address: ###.##.###.##) (interface: WAN[wan]) (real interface: bge0).
2020-11-25T17:30:14 opnsense[30029] /usr/local/etc/rc.newwanip: IPv4 renewal is starting on 'bge0'
2020-11-25T17:30:14 dhclient[56458] New Routers (bge0): <WANIP2>.1
2020-11-25T17:30:14 dhclient[6882] New Broadcast Address (bge0): <WANIP>.255
2020-11-25T17:30:14 dhclient[99685] New Subnet Mask (bge0): 255.255.252.0
2020-11-25T17:30:14 dhclient[90625] New IP Address (bge0): <WANIP>.54
2020-11-25T17:30:14 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:30:11 dhclient[89327] DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 13
2020-11-25T17:30:01 dhclient[89327] DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 10
2020-11-25T17:29:55 dhclient[89327] DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 6
2020-11-25T17:29:51 dhclient[89327] DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 4
2020-11-25T17:29:49 dhclient[89327] DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 2
2020-11-25T17:29:44 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:29:42 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:29:40 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:29:39 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:29:38 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:29:37 dhclient[89327] DHCPREQUEST on bge0 to 255.255.255.255 port 67
2020-11-25T17:29:37 kernel bge0: link state changed to UP
2020-11-25T17:28:57 opnsense[9477] /usr/local/etc/rc.linkup: Clearing states for stale wan route on bge0
2020-11-25T17:28:57 kernel bge0: link state changed to DOWN
2020-11-24T09:43:43 opnsense[20489] /usr/local/etc/rc.newwanip: On (IP address: <WANIP>.54) (interface: WAN[wan]) (real interface: bge0).

Some additional info:

Code Select Expand

cat /var/db/dhclient.leases.bge0
lease {
  interface "bge0";
  fixed-address <WANIP>.54;
  next-server <WANIP2>.1;
  option subnet-mask 255.255.252.0;
  option routers <WANIP2>.1;
  option domain-name-servers <DNS>.57,<DNS2>.215;
  option dhcp-lease-time 490060;
  option dhcp-message-type 5;
  option dhcp-server-identifier <DNS>.55;
  renew 5 2020/11/27 04:47:33;
  rebind 0 2020/11/29 07:50:22;
  expire 1 2020/11/30 00:51:23;
}
lease {
  interface "bge0";
  fixed-address <WANIP>.54;
  next-server <WANIP2>.1;
  option subnet-mask 255.255.252.0;
  option routers <WANIP2>.1;
  option domain-name-servers <DNS>.57,<DNS2>.215;
  option dhcp-lease-time 604800;
  option dhcp-message-type 5;
  option dhcp-server-identifier <DNS>.55;
  renew 0 2020/11/29 04:30:14;
  rebind 2 2020/12/1 19:30:14;
  expire 3 2020/12/2 16:30:14;
}


The leasetime from my provider is 604800 seconds, but after 32 hours my WAN goes down and it does a renew.
Everytime the connection goes down it takes about one minute to get back up again. Not very convenient if you're videoconferencing  :o.
I took a look at dhclient.leases.bge0 and it shows me (right after the last renew) the following:

Code Select Expand

lease {
  interface "bge0";
  fixed-address xxx.xxx.xx5.54;
  next-server xxx.xxx.xx2.1;
  option subnet-mask 255.255.252.0;
  option routers xxx.xxx.xx2.1;
  option domain-name-servers yyy.yyy.yy1.57,yyy.zzz.zz3.215;
  option dhcp-lease-time 604800;
  option dhcp-message-type 5;
  option dhcp-server-identifier yyy.yyy.yy1.55;
  renew 0 2020/10/25 18:12:36;
  rebind 3 2020/10/28 09:12:36;
  expire 4 2020/10/29 06:12:36;
}
lease {
  interface "bge0";
  fixed-address xxx.xxx.xx5.54;
  next-server xxx.xxx.xx2.1;
  option subnet-mask 255.255.252.0;
  option routers xxx.xxx.xx2.1;
  option domain-name-servers yyy.yyy.yy1.57,yyy.zzz.zz3.215;
  option dhcp-lease-time 489798;
  option dhcp-message-type 5;
  option dhcp-server-identifier yyy.yyy.yy1.55;
  renew 1 2020/10/26 10:10:57;
  rebind 3 2020/10/28 13:12:06;
  expire 4 2020/10/29 06:12:36;
}
The first lease-time is 7 days, but the renew 0 is in about 32 hours.
The second lease-time is a bit over 5 days, and the renew 1 is in 48 hours.

Is it possible to have the renew 0 and 1 run later and have the WAN not go down, but continue running??

oh. you can try save your Sites2Block once again and shoud get "error fetching alias url 172.217.17.46" in logs.
URL(IPs) alias type is for fetching list from remote IP (once).
change Sites2Block type to Networks or Hosts type
https://docs.opnsense.org/manual/aliases.html

The link helped... (Why didn't I find that.... :/)
I assumed URL (IP) meant url or ip....
Now used Hosts and fqdn (which I wanted/needed) and now it works fine.

It's a Quick-rule and these are the aliases:

Code Select Expand


Clients2Block Host(s) Clients 2 Block 192.168.30.109
Sites2Block URL (IPs) Sites 2 Block 172.217.17.46

The rule basically is

Code Select Expand


Protocol Source Port Destination Port Gateway Schedule Description
IPv4 * Clients2Block  * Sites2Block * * * Block Sites 4 Clients

Edit:
apparently using an alias for Sites2Block does not work.
Changed both to ip one at a time and tested and changed them back to alias.
When I changed the alias to Sites2Block traffic was possible again.

I have created a rule (at first with a schedule, but removed the schedule for testing purposes).

The rule consists of an alias (for now with 1 ip address) which is blocked access to another alias (for now with 1 ip address).
It is the first rule in the rules definitions for that vlan, the last rule is triggered - which allows the traffic.
Access from that client is permitted to that ip address.
The rule is evaluated over 100.000 times and triggered 0 times...
There is nothing in the logging to be found regarding this traffic (being blocked).

How/where can I find out why traffic is not blocked?

@franco,
For my previous mentioned problem I will start a new thread.
The statistics help, but it would be nice to have a possibility to log (for a short period of time) the rules it passed and (maybe?) on what it tried to match and why it didn't match. Until it finds the last rule on which it matches.
(Sort of an enhancement of the 'Detailed rule info'?)