Messages

I'm trying to locate it, but the latest I can find is "https://pkg.opnsense.org/releases/26.1.6/"

Sorry, I know the Zenarmor issue has already been reported, but frustration is high.

This upgrade is causing havok.

Upgrade itself from 26.1.11 didn't give any issues. However after the upgrade to 26.7, zenarmor (elasticsearch to be specific) failed to start failed to start and ET Pro telemetry widget failed to load. The system was unstable and rebooted unexpectedly twice.

Then I did a clean install from USB and reloaded the config, but Zenarmor isn't installing and ET Pro isn't downloading the rulesets.

BR. Peter

I'm trying to set up sftp backup to replace googledrive.

Dest is a synology with sftp enabled on port 2222
I've created an rsa key and I can connect to the dest with winscp/sftp, from my PC.
The dest is pingable from the FW

However, I get the following error trying to connect from the FW.

"The following input errors were detected:
** WARNING: connection is not using a post-quantum key exchange algorithm. ** This session may be vulnerable to "store now, decrypt later" attacks. ** The server may need to be upgraded. See https://openssh.com/pq.html backup@prnnas02.xxxx.yyy: Permission denied (publickey,password). Connection closed[/i]"

What am I doing wrong?

/Peter

I think I've fixed it now.

I ran into another little nag, as tranfferring 4,5'ish GB also broke the connection.
Turns out to be on the ASA, changing the parameters as per the screenshot have fixed most of the isses.
Only ting I haven figured out is why its worked flawlessly for several years.

Hi

I'm working on setting up a site-to-site IPsec connection that has been running smoothly for years between an Arista ETM and a Cisco ASA. Now, I'm replacing the Arista ETM with OPNsense. The configuration on the ASA remains unchanged. The tunnel establishes successfully and works fine for about an hour, but then it stops or breaks.

The relevant connection in the logfile.txt is 185.xx.xxx.x to 91.yyy.yyy.yy. The conncection breaks at 2024-12-23T13:23:55 and is reestablished at 2024-12-23T13:24:09:

Info:
OPNsense 24.7.11_2-amd64
FreeBSD 14.1-RELEASE-p6
OpenSSL 3.0.15
StrongSwan 5.9.14
CPU 12th Gen Intel i5-1245U
Mem 16GB
Disk 512GB nvme


/Peter

Thanks for the feedback, and I have the gut feeling that somthing isn't right. whether its something malicious or misbehaving sw I dont know, soI guess I'll do a clean install of the fw.

PS. no my real WAN ip is not 192.168.0.157, this is a lab setup. I've been running untangle/arista for some years and they have recently decided to discont. the homepro version, hense license fee will 10x.

Again thanks for input  :)

Hi

I'm trying to figure out why the firewall (WAN ip: 192.168.0.157) is trying to ssh to almost every host on the WAN net. This happens every 15mins

Interface      Time   Source   Destination   Proto   Label   
wan      2024-03-29T12:30:46   192.168.0.157:1186   192.168.0.50:22   tcp      
wan      2024-03-29T12:30:45   192.168.0.157:1184   192.168.0.50:22   tcp      
wan      2024-03-29T12:30:45   192.168.0.157:1183   192.168.0.40:22   tcp      
wan      2024-03-29T12:30:44   192.168.0.157:1181   192.168.0.40:22   tcp      
wan      2024-03-29T12:30:44   192.168.0.157:1180   192.168.0.33:22   tcp      
wan      2024-03-29T12:30:43   192.168.0.157:1177   192.168.0.33:22   tcp      
wan      2024-03-29T12:30:43   192.168.0.157:1176   192.168.0.27:22   tcp      
wan      2024-03-29T12:30:43   192.168.0.157:1173   192.168.0.27:22   tcp      
wan      2024-03-29T12:30:43   192.168.0.157:1172   192.168.0.25:22   tcp      
wan      2024-03-29T12:30:43   192.168.0.157:1170   192.168.0.25:22   tcp      
wan      2024-03-29T12:30:43   192.168.0.157:1169   192.168.0.229:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1167   192.168.0.229:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1166   192.168.0.224:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1164   192.168.0.224:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1163   192.168.0.220:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1161   192.168.0.220:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1160   192.168.0.22:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1158   192.168.0.22:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1157   192.168.0.21:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1155   192.168.0.21:22   tcp      
wan      2024-03-29T12:30:42   192.168.0.157:1154   192.168.0.208:22   tcp      
wan      2024-03-29T12:30:41   192.168.0.157:1152   192.168.0.208:22   tcp      
wan      2024-03-29T12:30:41   192.168.0.157:1151   192.168.0.204:22   tcp      
wan      2024-03-29T12:30:40   192.168.0.157:1149   192.168.0.204:22   tcp      
wan      2024-03-29T12:30:40   192.168.0.157:1148   192.168.0.201:22   tcp      
wan      2024-03-29T12:30:39   192.168.0.157:1146   192.168.0.201:22   tcp      
wan      2024-03-29T12:30:39   192.168.0.157:1145   192.168.0.200:22   tcp      
wan      2024-03-29T12:30:38   192.168.0.157:1143   192.168.0.200:22   tcp      
wan      2024-03-29T12:30:38   192.168.0.157:1142   192.168.0.20:22   tcp      
wan      2024-03-29T12:30:38   192.168.0.157:1140   192.168.0.20:22   tcp      
wan      2024-03-29T12:30:38   192.168.0.157:1139   192.168.0.199:22   tcp      
wan      2024-03-29T12:30:37   192.168.0.157:1137   192.168.0.199:22   tcp      
wan      2024-03-29T12:30:37   192.168.0.157:1136   192.168.0.198:22   tcp      
wan      2024-03-29T12:30:37   192.168.0.157:1134   192.168.0.198:22   tcp      
wan      2024-03-29T12:30:37   192.168.0.157:1133   192.168.0.171:22   tcp      
wan      2024-03-29T12:30:36   192.168.0.157:1131   192.168.0.171:22   tcp      
wan      2024-03-29T12:30:36   192.168.0.157:1130   192.168.0.163:22   tcp      
wan      2024-03-29T12:30:36   192.168.0.157:1128   192.168.0.163:22   tcp      
wan      2024-03-29T12:30:36   192.168.0.157:1127   192.168.0.162:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1125   192.168.0.162:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1124   192.168.0.161:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1122   192.168.0.161:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1121   192.168.0.160:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1119   192.168.0.160:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1117   192.168.0.16:22   tcp      
wan      2024-03-29T12:30:35   192.168.0.157:1116   192.168.0.159:22   tcp      
wan      2024-03-29T12:30:34   192.168.0.157:1114   192.168.0.159:22   tcp

I've also spotted a couple of forign IP's
PR  DIR  SRC                        DEST                       STATE              AGE       EXP     PKTS    BYTES
tcp  Out 192.168.0.157:4685  90.201.245.177:22  SYN_SENT:CLOSED  00:01:51  00:00:09  1  60
tcp  Out 192.168.0.157:9815  92.10.20.150:22  SYN_SENT:CLOSED  00:01:48  00:00:12  1  60
tcp  Out 192.168.0.157:35230  97.106.22.123:22  SYN_SENT:CLOSED  00:01:42  00:00:18  1  60
tcp  Out 192.168.0.157:48424  97.227.172.3:22  TIME_WAIT:TIME_WAIT  00:01:35  00:00:00  2  100
tcp  Out 192.168.0.157:64406  98.90.241.255:22  TIME_WAIT:TIME_WAIT  00:01:32  00:00:00  2  100
tcp  Out 192.168.0.157:45567  99.129.42.74:80  SYN_SENT:CLOSED  00:01:29  00:00:31  1  60
tcp  Out 192.168.0.157:30475  99.129.42.74:22  TIME_WAIT:TIME_WAIT  00:01:28  00:00:02  2  100
tcp  Out 192.168.0.157:4522  9.0.0.0:22  TIME_WAIT:TIME_WAIT  00:01:17  00:00:14  3  160

I have not been able to find a PID claiming responcibility of the connections.

/Peter

I had the same issue, but it's gone away now and the only thing I can remeber changing was toggling the "Lock" - "Preventing interface removal" for my LAN and WAN interfaces.