OPNsense
  • Home
  • Help
  • Search
  • Login
  • Register

  • OPNsense Forum »
  • Profile of jenix »
  • Show Posts »
  • Topics
  • Profile Info
    • Summary
    • Show Stats
    • Show Posts...
      • Messages
      • Topics
      • Attachments

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

  • Messages
  • Topics
  • Attachments

Topics - jenix

Pages: [1]
1
24.1 Legacy Series / Multicast only crc errors
« on: March 17, 2024, 11:38:00 am »
Hey everyone

I am experiencing the strange issue, that IPTV multicast packages sent from OPNsense to my switch are dropped there due to crc errors. My OPNsense (a DEC840) is connected to an Aruba 2540 via DAC. Everything worked fine until I had to replace the disk of the DEC840 recently. I did a clean reinstall of 24.1 and imported my previous config. Everything is working fine apart from my IPTV setup. All the configuration is correct (and was working previously) on the OPNsense side, I can see the IGMP subscription and the broadcast of the multicast stream into the network.
However, the Aruba switch is claiming that it receives the multicast packages with crc errors (or "FCS errors" as Aruba / HPE calls it). The strange thing is, that this only applies to the IPTV multicast packages. As soon as I subscribe to a stream on a client, the RX errors on the switch port connected to the OPNsense firewall go through the roof until I stop the stream / unsubscribe again. Then all RX errors stop as well. I do not see any errors with other traffic, independently of the amount. This lets me believe that this is not a physical issue as I would expect that crc errors would appear with 'normal' traffic as well.

As the whole setup / configuration of the switch has not changed, the only possibility that I see is that OPNsense somehow messes up the crc computation of the packages. I tried to enable the CRC hardware offloading, but the issue is still the same. Now I'm at a loss how I can debug this issue further or what I can try next.
Does anyone has an idea? Any help is really apprechiated.

Thanks already.

2
Virtual private networks / OPNsense 24.1 does not recognize (legacy) IPSec tunnel config
« on: February 10, 2024, 10:53:21 am »
Hi all

I had to do a fresh install of 24.1 due to some difficulties during the upgrade. During the import of my old config, opnsense seems to discard the IPSec config of my tunnel settings (not my issue, just an annoyance). I have recreated them according to the documentation (https://docs.opnsense.org/manual/how-tos/ipsec-s2s.html), but it seems that strongswan does not 'sees' the configured connection. After enabling the tunnel and restarting IPSec, nothing happens and nothing is displayed in the "Status Overview" or "Lease Status".

The log file (set to debug) just reads:
Code: [Select]
2024-02-10T10:17:27 Informational charon 00[JOB] spawning 16 worker threads
2024-02-10T10:17:27 Informational charon 00[LIB] loaded plugins: charon aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs12 pgp dnskey sshkey pem openssl pkcs8 fips-prf curve25519 xcbc cmac hmac kdf gcm drbg curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam whitelist addrblock counters
2024-02-10T10:17:27 Informational charon 00[CFG] loaded 0 RADIUS server configurations
2024-02-10T10:17:27 Informational charon 00[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
2024-02-10T10:17:27 Informational charon 00[CFG] loading crls from '/usr/local/etc/ipsec.d/crls'
2024-02-10T10:17:27 Informational charon 00[CFG] loading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
2024-02-10T10:17:27 Informational charon 00[CFG] loading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
2024-02-10T10:17:27 Informational charon 00[CFG] loading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
2024-02-10T10:17:27 Informational charon 00[CFG] loading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
2024-02-10T10:17:27 Informational charon 00[NET] enabling UDP decapsulation for IPv6 on port 4500 failed
2024-02-10T10:17:27 Informational charon 00[KNL] unable to set UDP_ENCAP: Invalid argument
2024-02-10T10:17:27 Informational charon 00[CFG] using '/sbin/resolvconf' to install DNS servers
2024-02-10T10:17:27 Informational charon 00[LIB] providers loaded by OpenSSL: default legacy
2024-02-10T10:17:27 Informational charon 00[DMN] Starting IKE charon daemon (strongSwan 5.9.13, FreeBSD 13.2-RELEASE-p9, amd64)

When modifying the phase 1 / phase 2 settings, the following entries appear in the log:
Quote
2024-02-10T10:56:43   Informational   charon   05[CFG] loaded 0 RADIUS server configurations   
2024-02-10T10:56:43   Informational   charon   05[CFG] loaded 0 entries for attr plugin configuration   
2024-02-10T10:56:43   Informational   charon   05[LIB] no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'

Phase1 and Phase2 are enabled, as well as the " Enable IPsec" option. Does anyone have an idea, what I am doing wrong?

I also tried to migrate my tunnel to the new "connection" configuration. But I was not able to find the correct documentation for my use case (an IPSec Tunnel over the internet between my OPNsense and a pfsense firewall with DynDNS). Is there a good guide for that?

Thank you already very much for your support.

3
23.7 Legacy Series / DEC840: Extremly slow boot after 23.7.12 / 24.1 upgrade
« on: January 21, 2024, 04:53:14 pm »
EDIT: I adjusted the topic, as I now believe my initial assumptions (device freezes during boot) are wrong, instead the boot process is extremely slow (around 30 minutes). I suspect the culprit to be either my configuration or the config migration. Please see my latest post (https://forum.opnsense.org/index.php?topic=38266.msg188463#msg188463) for more details.

Initial Post:
So the upgrade to 23.7.12 bricks my DEC840 firewall. I can reproduce the issue as it happened 3 times in a row (initial upgrade, after the fresh installation and once again to verify).
The installation of the upgrades completes, but there seems to be an issue when syncing the filesystem during the shutdown. Console output reads:
Code: [Select]
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining... 6 fsync: giving up on dirty (error = 35) 0xfffff800017f73d0: type VCHR
    usecount 1, writecount 0, refcount 435 seqc users 0 rdev 0xfffff80001785000
    hold count flags ()
    flags ()
    v_object 0xfffff800017e4e70 ref 0 pages 12163 cleanbuf 432 dirtybuf 1
    lock type mntfs: EXCL by thread 0xfffffe00917dee40 (pid 16, syncer, tid 100092)
3 2 0 0 done
All buffers synced.

Then after the reboot, the system gets stuck after enabling the interfaces:
Code: [Select]
uart0: <8250 or 16450 or compatible> port 0x3f8-0x3ff irq 3 flags 0x10 on acpi0
hwpstate0: <Cool`n'Quiet 2.0> on cpu0
Timecounter "TSC" frequency 2096061312 Hz quality 1000
Timecounters tick every 1.000 msec
Trying to mount root from ufs:/dev/ada0p2 [rw]...
ugen0.1: <AMD XHCI root HUB> at usbus0
uhub0 on usbus0
uhub0: <AMD XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <TS256GMTS952T2 02J0T4GB> ACS-2 ATA SATA 3.x device
ada0: Serial Number G752440056
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes)
ada0: Command Queueing enabled
ada0: 244198MB (500118192 512 byte sectors)
uhub0: 8 ports with 8 removable, self powered
ax1: Link is UP - 10Gbps/Full - flow control off
ax1: link state changed to UP
ax0: Link is UP - 10Gbps/Full - flow control off
ax0: link state changed to UP

After that, changes to the interfaces are detected (showing "Link us UP" / "Link is DOWN" when plugging cables in / out), but the system never continues the boot. Both Safe Mode and Single User Mode get stuck at the same stage.

The only solution for me was to reinstall opnsense 23.7 via USB. But as mentioned above, trying to upgrade the fresh install results in the same issue.

I'm not sure what more info I can provide to this issue. Please let me know if I can contribute logs or additional information.
As this is my primary firewall, testing upgrades is difficult (but not impossible if needs be).

Any ideas, what the issue is and how I can solve it?
Thanks already and kind regards

Jens

Pages: [1]
OPNsense is an OSS project © Deciso B.V. 2015 - 2024 All rights reserved
  • SMF 2.0.19 | SMF © 2021, Simple Machines
    Privacy Policy
    | XHTML | RSS | WAP2