Topics

A new BIOS is available for DEC 700 and 2700 series. It was created in February 2025 and the available information simply states CVE Update.

Reminder - the appliance automatically powers off once the update process reaches 100%

DEC700 and DEC2700 series

02-2025 Version 32

Download

Code Select Expand



          Insyde H2OFFT (Flash Firmware Tool) Version (SEG) 200.02.00.06
         Copyright (C) 2022 Insyde Software Corp. All Rights Reserved.


                      Loading New BIOS Image File: ..Done

                  Current BIOS Model Name: NetBoard-A10_Gen.3
                  New     BIOS Model Name: NetBoard-A10_Gen.3
                  Current BIOS Version: 05.38.09.0023-A10.30
                  New     BIOS Version: 05.38.26.0025-A10.32


                           Updating Block at FFFFF000h
          0%          25%         50%          75%         100%
           **************************************************     100%

BIOS Version : 05.38.26.0025-A10.32
BIOS Build Date : 02/08/2025
   

SHA256 Checksum 1fc2efa0f16e3630bbdedcce5e6626c45378cce2e8c6739b19b436d957066903

CVE Update

BIOS updates page

Due to dependency issues between mongo and icu, while upgrading to 25.1.2 the Unifi controller is uninstalled.

Michael knows about this issue and will probably chime in whenever possible with an update or an ETA for an update.

Code Select Expand

Updating OPNsense repository catalogue...
OPNsense repository is up to date.
Updating mimugmail repository catalogue...
mimugmail repository is up to date.
All repositories are up to date.
The following 6 package(s) will be affected (of 0 checked):

Installed packages to be REMOVED:
        mongodb60: 6.0.19
        os-unifi-maxit: 1.3
        unifi8: 8.6.9

Installed packages to be UPGRADED:
        boost-libs: 1.86.0_1 -> 1.87.0_1 [OPNsense]
        icu: 74.2_1,1 -> 76.1,1 [OPNsense]

FYI - there is a pf regression in the 24.7.10 kernel that causes OPNsense to crash and reboot -- twice for me on two different FWs in the first hour.


I've been working on this with Franco and there's a test kernel that is stable for me for 3.5+ hours and counting.

https://github.com/opnsense/src/commit/83757627

Code Select Expand


# opnsense-update -zkr 24.7.10-state

# opnsense-shell reboot


[-oKexAlgorithms=mlkem768x25519-sha256]

Starting with OPNsense 24.7.7 it is now possible to connect to your firewall using a new post quantum key exchange.

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

o ports: openssh 9.9.p1[11]

[11] https://www.openssh.com/txt/release-9.9

It is therefore imperative that both client and server are on version 9.9 of OpenSSH.

To verify the client is able to connect using the new algorithm use this command:

Code Select Expand

root@opnsense ~# ssh -Q kex | grep mlkem
mlkem768x25519-sha256

Now for the hardening part, go to System - Settings - Administration:

Code Select Expand

- Key exchange algorithms - mlkem768x25519-sha256
                          - sntrup761x25519-sha512
                          - sntrup761x25519-sha512@openssh.com    

- Ciphers - aes256-gcm@openssh.com
          - chacha2020-poly1305@openssh.com

- MACs - hmac-sha2-256-etm
       - hmac-sha2-512-etm

- Host Key Algotythms - ssh-ed25519
                      - ssh-ed25519-cert-v01@openssh.com

- Rekey Limit - System Defaults
              - otherwise if in a highly regulated environment adjust as needed.


Sample output, some lines removed:

Code ("Failed connection") Select Expand

root@localhost ~# ssh -v -oKexAlgorithms=sntrup761x25519-sha512 192.168.1.1
OpenSSH_9.9p1, OpenSSL 3.1.4 24 Oct 2023
debug1: Reading configuration data /usr/etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-suse.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: /usr/etc/ssh/ssh_config line 33: Applying options for *
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_9.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 FreeBSD-openssh-portable-9.9.p1,1
debug1: compat_banner: match: OpenSSH_9.9 FreeBSD-openssh-portable-9.9.p1,1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.1:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: (no match)
Unable to negotiate with 192.168.1.1 port 22: no matching key exchange method found. Their offer: mlkem768x25519-sha256,ext-info-s,kex-strict-s-v00@openssh.com


Code ("Successful Connection") Select Expand

root@localhost ~ [255]# ssh -v -oKexAlgorithms=mlkem768x25519-sha256 192.168.1.1
OpenSSH_9.9p1, OpenSSL 3.1.4 24 Oct 2023
debug1: Reading configuration data /usr/etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-suse.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: /usr/etc/ssh/ssh_config line 31: include /usr/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /usr/etc/ssh/ssh_config line 33: Applying options for *
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /usr/etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-suse.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: /usr/etc/ssh/ssh_config line 31: include /usr/etc/ssh/ssh_config.d/*.conf matched no files
debug1: /usr/etc/ssh/ssh_config line 33: Applying options for *
debug1: Connecting to 192.168.1.1 [192.168.1.1] port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_9.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 FreeBSD-openssh-portable-9.9.p1,1
debug1: compat_banner: match: OpenSSH_9.9 FreeBSD-openssh-portable-9.9.p1,1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.1:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: mlkem768x25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: <implicit> compression: none
debug1: kex: mlkem768x25519-sha256 need=32 dh_need=32
debug1: kex: mlkem768x25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:qLYOvRRjxmMxvH7O76j7Ib/+Y6lK7oL
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:qLYOvRRjxmMxvH7O76j7Ib/+Y6lK7oL



Final considerations.

- As of October 2024, neither latest Putty v0.81 nor WinSCP 6.3.5 support MLKEM yet.

   - Putty v0.83 has added support for MLKEM in February 2025, WinSCP should follow suit either with a release on the 6.3.6+ stable branch or with the current beta one starting with v6.4.3+

- There seems to be a bug in the big linux distros that I tested where the ssh connection will fail for MLKEM, which is why I'm requesting it manually with -oKexAlgorithms=mlkem768x25519-sha256. FreeBSD worked fine.

-  For OPNsense Business Edition MLKEM is available in 24.10.1.

- If unsure about any of the options presented here it is absolutely fine leaving every option on System Defaults.

For those interested, Franco built a test kernel based on a sizable import of Intel related fixes that recently made it into FreeBSD. You can review the new commits on Github in opnsense/src section.

To install and verify you're on  the new kernel:

Code Select Expand

# opnsense-update -zkr 24.7.6-intel

Fetching kernel-24.7.6-intel-amd64.txz: ..... done
!!!!!!!!!!!! ATTENTION !!!!!!!!!!!!!!!
! A critical upgrade is in progress. !
! Please do not turn off the system. !
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Installing kernel-24.7.6-intel-amd64.txz... done
Please reboot.

# opnsense-shell reboot

root@OPNsense:~ # uname -a
FreeBSD OPNsense.home.arpa 14.1-RELEASE-p5 FreeBSD 14.1-RELEASE-p5 stable/24.7-n267903-51187ea746d SMP amd64



In case of issues you can always boot the old kernel from the boot menu. Snapshots are also available on ZFS - although in this case it may be a bit overkill.


I'm running on this kernel for over 24h without issues, 3 FWs with igc NICs and one APU with igb.

Any feedback welcome, and potential issues will have a chance to be fixed before these patches make it into 24.7.7+

Available in English and German, links below

Problem für Nutzer einer AVM-FRITZ!Box, die versuchen, aus dem Heimnetzwerk auf die Verwaltungsoberfläche des Routers zuzugreifen. Bei Eingabe der URL fritz.box landen die Nutzer aber nicht auf der Anmeldeseite der FRITZ!Box, sondern werden auf eine externe Webseite umgeleitet. Zwei Nutzer haben mich auf das Problem hingewiesen, wobei ein Nutzer einen Hack vermutete. Ursache ist eine Verkettung zweier Sachverhalte, die dieses Verhalten provozieren. Jemand hat eine Domain fritz.box registriert und DNS-Server von Google lösen dann auf diese Seite auf. Abhilfe schafft die Eingabe der IP-Adresse der FRITZ!Box oder die Verwendung eines anderen DNS-Servers.

https://borncity.com/win/2024/01/26/fritzbox-entering-the-url-fritz-box-suddenly-redirects-to-an-external-page/

https://www.borncity.com/blog/2024/01/26/fritzbox-problem-eingabe-der-url-fritz-box-leitet-pltzlich-auf-externe-seite-um/

Available in English and German, links below

Problem for users of an AVM FRITZ!Box family broadband routers who try to access the router's administration interface from the home network. However, when entering the URL fritz.box, users do not end up on the routers firmware FRITZ!Box login page, but are redirected to an external website. Two users have pointed out the problem to me, with one user suspecting a hack. The cause is a combination of two circumstances that provoke this behavior. Someone has registered a domain fritz.box and DNS servers from Google then resolve to this page. The remedy is to enter the IP address of the FRITZ!Box or to use a different DNS server.

https://borncity.com/win/2024/01/26/fritzbox-entering-the-url-fritz-box-suddenly-redirects-to-an-external-page/

https://www.borncity.com/blog/2024/01/26/fritzbox-problem-eingabe-der-url-fritz-box-leitet-pltzlich-auf-externe-seite-um/

A domain change has been commited today for Adguard, EasyList and EasyPrivacy lists.

-   "ag": "https://justdomains.github.io/blocklists/lists/adguarddns-justdomains.txt",
+  "ag": "https://v.firebog.net/hosts/AdguardDNS.txt",
............................
-   "el": "https://justdomains.github.io/blocklists/lists/easylist-justdomains.txt",
-   "ep": "https://justdomains.github.io/blocklists/lists/easyprivacy-justdomains.txt",
+  "el": "https://v.firebog.net/hosts/Easylist.txt",
+  "ep": "https://v.firebog.net/hosts/Easyprivacy.txt",

Unbound users relying on these lists can apply the following patch and restart Unbound

Code Select Expand

opnsense-patch f314a95 && pluginctl -s unbound restart

https://github.com/opnsense/core/commit/f314a95a3b56d790fdee2a7395124bebc69c578c


Valid for OPNsense CE up to 23.7.10 and OPNsense BE up to 23.10.1

Hi Franco,

Here's an example taken from one of the FWs I moved on to 3.0.12 which hasn't been otherwise modified in a long time other than regular patching.

I already had he alias created or a while, just moved it now at the top and added the explicit deny right after.

Verified in conf.xml the alias_uuid matches in both rule and alias sections, aliases are enabled and no other "garbage" appears to be present in the configuration.



As you can see in the screenshot, the rules are simple and the two running pings fail - so the alias is somehow ignored

1. Allow ICMP to Alias (1.1.1.1, 8.8.8.8 and 9.9.9.9)
2. Deny ICMP


The firewalls are now on OPNsense 23.7.8_14. 

I'll be back shortly after I deploy a fresh VM and try o reproduce it there on stock 23.7 fully updated.

Posting it here for visibility, unsure if this is specific to OpenSSL 3.0.12 that I'm testing or happens on 1.1.1.w as well.

Both FWs where I'm seeing this are configured with DuckDNS and were fine before _1

Code Select Expand

Error configd.py [2750a2c9-94ac-466c-b786-d31293c304b1] Script action failed with Command '/usr/local/opnsense/scripts/ddclient/ddclient_opn.py -l' returned non-zero exit status 1. at Traceback (most recent call last): File "/usr/local/opnsense/service/modules/actions/script_output.py", line 44, in execute subprocess.check_call(script_command, env=self.config_environment, shell=True, File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/usr/local/opnsense/scripts/ddclient/ddclient_opn.py -l' returned non-zero exit status 1.

[DEC800, DEC3800 & DEC4000 series]

I was wondering if there aren't any new BIOS releases that somehow were not announced to Deciso? It's almost impossible to find anything reliable on the INSYDE website.


Below you can see the BIOS reported by a new DEC850 with 2.5Gbe NICs, released either in June or September 2023 - depending on how you read the date.

Latest published version in the docs is from December 2022 for DEC800, DEC3800 & DEC4000 series https://docs.opnsense.org/hardware/bios.html


No sure if this is a DEC850 specific issue or a similar situation would be on other DEC series hardware, both Gen1 and Gen2, so I'm hoping an official inquiry can be made to INSYDE, since it appears the same BIOS would be relevant for many products.


Would probably help if people that bought recent hardware would post the BIOS infomation that came preinstalled on their boards.

Manufacturer    Deciso B.V.
Product Name    NetBoard-A20
Version    R2.0
Serial Number    
Family    NetBoard-A20
BIOS
Vendor    INSYDE Corp.
Version    05.22.01.0021.0013
Release Date    09/06/2023

Second WG issue I have to report today, this might not be visible yet since 23.7.6 didn't require a reboot. No reports on Github yet.


Two WG configurations on different FWs - connecting using IPs so no DNS in play - gateways don't come up post reboot. Need to go into the GUI and disable/reenable Wireguard.

Tried reverting only opnsense to 23.7.5 but that didn't help, so I reverted os-wirguard too and now the GWs are starting fine.

[Cannot assign an IP configuration type to a tunnel interface]

On a firewall using two Mullvad GWs which I set up more than a year ago one of the GWs went down this week. A deeper look revealed the server has been redeployed, same name but different IPs and WG keys.

As I've dealt with this in the past I went to update the GW configuration in all the required places, and all went fine except when trying to update the IP in Interfaces.  The error when trying to save the new IP is Cannot assign an IP configuration type to a tunnel interface

As you can see below, both opt13 and opt14 have the same settings, yet I couldn't update the IP in the GUI, so I just did it in config.xml and service was restored.

Code Select Expand

<opt13>
      <if>wg2</if>
      <descr>WAN_M0</descr>
      <enable>1</enable>
      <spoofmac/>
      <ipaddr>10.175.221.69</ipaddr>
      <subnet>32</subnet>
      <gateway>WAN_M0</gateway>
    </opt13>
    <opt14>
      <if>wg3</if>
      <descr>WAN_M1</descr>
      <enable>1</enable>
      <spoofmac/>
      <ipaddr>10.22.47.75</ipaddr>
      <subnet>32</subnet>
      <gateway>WAN_M1</gateway>
    </opt14>


I don't set up Mullvad too often which is why I cannot pinpoint the OPNsense time frame this GUI restriction b]Cannot assign an IP configuration type to a tunnel interface[/b] has been added.  It is clearly required though so I'm hoping Franco or Ad can look into it.


For reference, this is the tutorial I follow/revisit anytime I need to set up or update a WG configuration

https://schnerring.net/blog/opnsense-baseline-guide-with-vpn-guest-and-vlan-support/

Hi Franco,


Just found a few VMs I did a basic install of 23.1 - upgraded to the latest at the time 23.1.1_2 - to test some IPsec scenarios - haven't used it since.


Went to upgrade the first one and landed on 23.1.11_1 and then moved on to 23.7.1_3

If I'm right then there seem to be two upgrade paths now to 23.7 and I don't know if this is intended - but assume it's not. Any upgrades 23.1.x should be landing on  23.1.11_2 and from there to 23.7.4

Thought about this being a mirror issue but I confirmed the config has pkg.opnsense.org - which I'm always using.


I'll do the other VMs shortly and report back.

Hi there,


Following https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html as reference.

Setup is fairly barebones - in a lab.

OPNsense FWs - cloned* - no VLANS, one linux VM in each Lan pinging each other, allow any out rules on Lan and IPSec.
        * - this is an old VM deployed years ago, fully up to date on 23.1 - kept as a reference. IPSec was never used on it previously and no NAT changes ever happened on it.


The LANs are in the form of 192.168.AAA.0/24 and 192.168.BBB.0/24 - so nothing unusual there either.

WAN interfaces are on the same vlan, all the IPSec rules mentioned in the documentation are present and there's only one additional rule to manage the FWs through the WAN.

I exported the FW configs and did a side-by -side in WinMerge and everything looks as expected.


The tunnel is not coming up for some reason, and I don't see anything helpful in the Live Logs or the IPSec ones, however as soon as I disable pf it all comes to life, phase 2 appears in IPSec Status Overview and ping works - both with Mutual PSK and Mutual PKI.


It took me a few tries redoing the IPSec config on both ends - thinking I might have chosen dhgroups that may not  be fully supported/working - until I did a config with the absolute defaults mentioned in the doc, and when that still failed I disabled pf as the last thing standing that I could think of.


Seeing how everything is completely open, the Winmerge side-by-side diff is clean with the IPSec things mirrored as expected and it all works with pf stopped - I figured I'd ask here first should there be something obscure I'm missing, otherwise this may be a bug after all ?


Thanks,
N

Hi again,

The first time I bumped into this issue was back in December, so this is not 23.1 specific, posting it here since the FW is already on 23.1.RC2.



I'm seeing this weird behavior  on a FW connected to Telus Canada where the WAN doesn't get a routable 2001:: IP yet based on the prefix delegation received the internal network interfaces get configured with 2001::/64 just fine tracking the WAN.


The only information I could find pertains to Edgerouter or pfSense configuration and it's not really 1:1 when compared to the options in the GUI:

https://heald.ca/configuring-telus-optik-ipv6-ubiquiti-edgerouter/

https://www.zacharyschneider.ca/2020/12/pfsense-ipv6-telus/


I tried toggling On and Off "Request only an IPv6 prefix" and  "Send IPv6 prefix hint" along with requesting a different PD Size other than the /56 but it wasn't helpful.




Any guidance on how to move foward troubleshooting this issue is most welcome.



Thank you.

Hi,

Trying to install 21.7.r1 on APU4 and got this error 19 late in the boot process after importing the existing config step. The drive was a Kingston USB v3 - and I'm unsure whether this was coreboot related as it is a known issue there for a while or something in FreeBSD land that can be looked at. I'll paste the full details below.

Code Select Expand

(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 1 more tries remain
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Retrying command, 0 more tries remain
(probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00
(probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error
(probe0:umass-sim0:0:0:0): Error 5, Retries exhausted
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <KINGSTON SUV500MS240G 003056RA> ACS-4 ATA SATA 3.x device
ada0: Serial Number 50026B7782368489
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 228936MB (468862128 512 byte sectors)
Trying to mount root from ufs:/dev/ufs/OPNsense_Install [ro,noatime]...
mountroot: waiting for device /dev/ufs/OPNsense_Install...
Mounting from ufs:/dev/ufs/OPNsense_Install failed with error 19.

Loader variables:
  vfs.root.mountfrom=ufs:/dev/ufs/OPNsense_Install
  vfs.root.mountfrom.options=ro,noatime

Manual root filesystem specification:
  <fstype>:<device> [options]
      Mount <device> using filesystem <fstype>
      and with the specified (optional) option list.

    eg. ufs:/dev/da0s1a
        zfs:zroot/ROOT/default
        cd9660:/dev/cd0 ro
          (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)

  ?               List valid disk boot devices
  .               Yield 1 second (for background tasks)
  <empty line>    Abort manual input

mountroot>
panic: mountroot: unable to (re-)mount root.
cpuid = 2
time = 122
__HardenedBSD_version = 1200059 __FreeBSD_version = 1201000
version = FreeBSD 12.1-RELEASE-p18-HBSD #0  2e2d4484b05(stable/21.7)-dirty: Tue Jun 29 08:38:24 CEST 2021
    root@sensey:/usr/obj/usr/src/amd64.amd64/sys/SMP
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0025a557c0
vpanic() at vpanic+0x1a2/frame 0xfffffe0025a55810
panic() at panic+0x43/frame 0xfffffe0025a55870
sysctl_vfs_root_mount_hold() at sysctl_vfs_root_mount_hold/frame 0xfffffe0025a559f0
start_init() at start_init+0x27/frame 0xfffffe0025a55a70
fork_exit() at fork_exit+0x83/frame 0xfffffe0025a55ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0025a55ab0
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
[ thread pid 1 tid 100002 ]
Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
db>


Also, this is the second APU4 upgraded in the past 24h and both had chrony configured and running with NTS on 21.1.x and the configuration file was both downloaded as a backup and imported when 21.7 was booting from the drive, however the automatic plugin troubleshooter consistently failed to reinstall chrony and its dependencies, and on one FW ZeroTier was missing as well and had to be manually installed so now it's runnning kinda/sorta but I cannot ssh to it so that's still something to troubleshoot on my end.

I've come across an interesting issue with 3 class C networks behind OPNsense where inter-vlan routing works, Internet access works from all 3 networks, however when trying to ssh/ping/traceroute/https from the main VLAN (where most devices are) to the LAN which has the AP/Switch I notice the traffic is flying out the Default GW which is a VPN IP.

I'm unsure why or how this issue came about, or why the traffic destined to a directly attached (virtual) interface would be routed on the GW.


At the very least I should be able to ping the devices from the FW as they're alive and noisy ( plenty of traffic from LAN to DNS VLAN), yet I get this when pinging from OPNSense:

# /sbin/ping -S '192.168.1.1' -c '3' '192.168.1.30'
PING 192.168.1.30 (192.168.1.30) from 192.168.1.1: 56 data bytes

--- 192.168.1.30 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss
ping: sendto: Invalid argument
ping: sendto: Invalid argument
ping: sendto: Invalid argument


Any ideas you may have would be appreciated, as I'm not sure why the routing to the default GW is chosen instead of the local VLAN.

Cheers,