Messages

Hi Folks,

I just upgraded a couple of my firewalls to test the new 25.x release stream before committing to move our entire estate.

So far everything looks good and we've only encountered one niggle, specifically the API responses seems to have changed e.g.

On a 24.x series and earlier instance calling core/system/status would return:

{
  "CrashReporter": {
    "statusCode": 2,
    "message": "No problems were detected.",
    "logLocation": "/crash_reporter.php",
    "timestamp": "0",
    "status": "OK"
  },
  "Firewall": {
    "statusCode": 2,
    "message": "No problems were detected.",
    "logLocation": "/ui/diagnostics/log/core/firewall",
    "timestamp": "0",
    "status": "OK"
  },
  "System": {
    "status": "OK"
  }
}

Since the 25.x upgrade this same call now returns:

{
  "metadata": {
    "system": {
      "status": 2,
      "message": "No pending messages",
      "title": "System"
    },
    "translations": {
      "dialogTitle": "System Status",
      "dialogCloseButton": "Close"
    },
    "subsystems": []
  }
}


It appears that the 3 previous sections, crash reporter / firewall / system, have been combined into a single 'No pending messages' response.

No problem and this kinda makes sense, the issue is I can't find documentation on what the various responses will be in the event of say a PHP crash or a firmware update failure, thus we cannot code around that change.

Can anyone provide me with info or a link to the 'Status/Message' responses that may be returned?

Cheers :)

Changelogs are pulled from the main mirror for exactly that reason... local solutions go out of sync and people forget that updates ever existed. If you wish to avoid that just block access to pkg.opnsense.org via alias.

Perfect thank you!

Hi Folks,

I have a question regarding updates or more accurately the availability check of updates.

I have a few OPNsense firewalls in use and to conserve in-bound bandwidth I RSYNC the contents of a remote 'official' repo to a local web server on my site. Each firewall is then configured with a custom repo URL pointing at this local web server.

This solution works well and allows me to conserve bandwidth as designed. It does however leave me with one question. If I DON'T update my local repo my firewalls still 'detect' firmware updates/releases. Attempting to update from the local 'out of date' repo correctly gives a 'No updates available on repo' error.

So if the configured repo does not have an update where is the firewall looking to 'find' the updates availability? What other un-configured 'dial home' activities does the firewall do?

Simon

Just ran into the same/similar issue i.e. trying to pass VLAN tagged traffic over an LACP trunk to a Cisco 2960-S. The solution for me was to set the system MTU to 9000

conf t
system mtu jumbo 9000

A switch reboot is needed.

Sorry I cannot help, I wanted to comment that I've just upgraded to 17.7.1 from 17.7 and now my Out traffic graph is showing as zero.

Thanks Franco,

Patch applied, I'll report back on my progress.

root@XEN-FW:~ # opnsense-patch a039ad4d
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From a039ad4db4d5819fa427c694c94d09846a377e3e Mon Sep 17 00:00:00 2001
|From: Franco Fichtner <franco@opnsense.org>
|Date: Fri, 19 May 2017 16:19:24 +0200
|Subject: [PATCH] ipsec: fix widget count after 5.5.2 update
|
|---
| src/www/widgets/widgets/ipsec.widget.php | 12 +++++++++---
| 1 file changed, 9 insertions(+), 3 deletions(-)
|
|diff --git a/src/www/widgets/widgets/ipsec.widget.php b/src/www/widgets/widgets/ipsec.widget.php
|index 4a98e13a5..58eb9e258 100644
|--- a/src/www/widgets/widgets/ipsec.widget.php
|+++ b/src/www/widgets/widgets/ipsec.widget.php
--------------------------
Patching file www/widgets/widgets/ipsec.widget.php using Plan A...
Hunk #1 succeeded at 34.
Hunk #2 succeeded at 66.
Hunk #3 succeeded at 109.
done
All patches have been applied successfully.  Have a nice day.
root@XEN-FW:~ #

Hi Folks,

Sorry me again :)

More of an observation than a bug. I have a number of 'site to site' IPsec VPN's in place between 5 different sites. All sites run OPNsense, mostly 17.1.7 but a one is 17.1.4.

Everything works and for the most part is trouble free but on each host I see odd numbers reported for the number of connected tunnels. For example I have one FW configured with 1 phase link and two phase two using IKEv1. The Dashboard shows 4 Active tunnels and -2 In-Active.

I have also noted at times that all the tunnels on a host can be 'Active' and working and the Dashboard shows 0 Active and 0 in-active. When this occurs checking VPN/IPSec/Status Overview shows nothing. Restarting the StrongSWAN daemon corrects this.

Whilst this odd behaviour doesn't seem to affect the IPSec function it does make diagnosing problems somewhat tricky.

Cheers

I've had a similar issue with ProxMox 4.4, eventually put the issue down to buggy VirtIO nic drivers in FreeBSD.

Moving my exact same config (Back/restore) to physical hardware with Intel e1000 style nics and everything works.

Have you tried changing the Nic type to e1000?

Sorted, thanks for the replys

Quick update, if I force passive mode on the client ftp -p I can connect.

Trouble is I don't have control over which clients connect so cannot rely on this as a solution.

Hi Folks,

I'm having an issue with FTP Proxy so need some guidance again.

Ok first off the network plan is as follows:

[Internet] > [OPNSense] > [FTP Server vsftpd]

So far I've:

/ I've installed the FTP-Proxy plugin
/ Configured a single proxy instance listening on 127.0.0.1:8021, reverse address set to internal ip of ftp server port 21
/ Added a WAN rule allowing ftp/21 to the WAN IP Address
/ Added a port forward rule forwarding WAN ftp/21 to 127.0.0.1:8021

Ok, if I ftp to the WAN IP Address I can connect to the FTPProxy and logon to the target FTP server (either anonymous or a local user account). However if I then try and perform any action I get the following, the command hangs hence the Ctrl+C to cancel:

yyyyy@GC-JUMPBOX:~$ ftp -v 159.8.x.x
Connected to 159.8.x.x.
220 Welcome to the Txxx Sxxxx Patching FTP service.
Name (159.8.x.x:yyyyy): ftp
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
200 PORT command successful. Consider using PASV.
^C
421 Service not available, remote server has closed connection

receive aborted
waiting for remote to finish abort
ftp>

The clients tested are Debian's default FTP and MS Windows, both can connect to ftp.debian.org for example eliminating the local firewall.

It looks like when the FTP client issues the N+1 request the proxy doesn't work.

If I connect directly to the FTP server using a client on the same lan everything works.

Any help very much appreciated.

Simon

[SSE3]

Silly me, the Opteron Istanbul core does support SSE3 and is shown in the DMESG of OPNSense booting however it doesn't support SSSE3 (extra S). Could this be what HYperscan is using not SSE3?

CPU: Six-Core AMD Opteron(tm) Processor 2431 (2400.14-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x100f80  Family=0x10  Model=0x8  Stepping=0
  Features=0x1783fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x80a02001<SSE3,CX16,x2APIC,POPCNT,HV>
  AMD Features=0xee500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow!>
  AMD Features2=0x5f3<LAHF,CMP,CR8,ABM,SSE4A,MAS,Prefetch,IBS>

Thanks franco,

That sounds like an interesting situation. As per your recommendation I will lock the Suricata package now from updates and call on your generosity should a major update occur that I need to deploy.

With regard to your latter statement yes according to everything I can find it should support SSE3 however looking at a Linux VM running on the same host I get the following, as you can see SSE3 is missing for some reason. I've checked on a couple of DL385G6 servers are the results are the same, I'll start looking to see if I can find any microcode issues/updates on Google:

/proc# cat cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 16
model           : 8
model name      : Six-Core AMD Opteron(tm) Processor 2431
stepping        : 0
microcode       : 0x10000da
cpu MHz         : 2400.160
cache size      : 512 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow rep_good nopl extd_apicid pni cx16 x2apic popcnt hypervisor lahf_lm cmp_legacy cr8_legacy abm sse4a misalignsse 3dnowprefetch ibs vmmcall
bogomips        : 4800.32
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 48 bits physical, 48 bits virtual
power management:

Thanks franco!

Surciata has now been up and running for over 1hour!

Now the big question, is this something that can be addressed going forward or would the removal of SSE3 support cause too many performance issues? I guess I'm asking is my ability to run Suricata on this host on borrowed time?

Sorry for the delay

Aha! progress excellent!

Yes it's an Opteron 2431 (Six Core) DL385 G6 server.

Crypto is currently OpenSSL