Topics

16

German - Deutsch / Interface in/out errors

« on: August 03, 2020, 05:30:37 pm »

Hallo zusammen,

nach dem Upgrade von 20.1.9 auf 20.7 habe ich viele In/Out-Fehler auf mehreren Schnittstellen. Diese Schnittstellen nutzen den igb-Treiber und werden unter XEN zur virtualisierten opnsense durchgereicht. Ich habe solche Fehler in der Vorgängerversion noch nie gesehen und keine Änderungen an der Konfiguration vorgenommen (CRC, TSO, LRO sind gesetzt).

Was kann ich tun, wo kann ich den Grund / die Lösung suchen? Ist sonst noch jemand betroffen?

Ausgabe in der GUI (netstat -i liefert ebenfalls die Fehler):

Code: [Select]

Status up
MAC address 00:16:3e:a0:16:f1 - Xensource, Inc.
MTU 1500
IPv4 address 192.168.20.1 / 24
IPv6 Link Local fe80::216:3eff:fea0:16f1 / 64
IPv6 address XXXXX / 64
Media 1000baseT <full-duplex>
In/out packets 3732 / 4960(748 KB / 3.27 MB )
In/out packets (pass) 3715 / 4960(748 KB / 3.27 MB )
In/out packets (block) 544 / 0(17 bytes / 0 bytes )
In/out errors 28880759300096/189112
Collisions 0
Interrupts
irq device total rate
irq261 igb2:rxq0 7002 7
Beste Grüße
Torsten

17

20.7 Legacy Series / Interface in/out errors

« on: August 03, 2020, 03:25:19 pm »

Hi all,

after upgrading from 20.1.9 to 20.7 I have many in/out errors on serveral interfaces. These interfaces  are passed trough from my XEN-Server to the virtualized opnsense with uses the igb driver. I have never seen such errors in the prior version and I made no changes to the configuration (CRC, TSO, LRO are checked).

What can I do, where can I look to find the reason/solution? Anybody else affected?

Code: [Select]

Status up
MAC address 00:16:3e:a0:16:f1 - Xensource, Inc.
MTU 1500
IPv4 address 192.168.20.1 / 24
IPv6 Link Local fe80::216:3eff:fea0:16f1 / 64
IPv6 address XXXXX / 64
Media 1000baseT <full-duplex>
In/out packets 3732 / 4960(748 KB / 3.27 MB )
In/out packets (pass) 3715 / 4960(748 KB / 3.27 MB )
In/out packets (block) 544 / 0(17 bytes / 0 bytes )
In/out errors 28880759300096/189112
Collisions 0
Interrupts
irq device total rate
irq261 igb2:rxq0 7002 7
Kind regards
Torsten

18

20.1 Legacy Series / Intel i350 SR-IOV + VLAN does not work properly in OPNSense

« on: May 17, 2020, 02:38:09 pm »

Hi all,

I got the same problem with OPNsense 20.1.6 as mentioned in

...
Created SR-IOV virtual function, VF on physical interface enp5s0,
then tagged it with VLAN ID 20.
...
After passing Virtual Function device, it should have changed into untagged packet
But instead, it got VLAN ID 1024.

My setup is host Ubuntu 18.04 with Xen 4.9 and Intel i350 NIC

Created SR-IOV virtual function, VF on physical interface and tagged all VFs with VLAN ID 20. One VF is passed to OPNSense VM and a second VF is passed to another VM.

I tried with and without VLAN tagging in the VMs. Neither worked and there is "no" communication (PING, DNS,..) between the VMs.

Looking at the traffic in case no VLAN tagging in the VMs, which should be the right way using VLANs with SR-IOV. All traffic coming in to OPNSense VM is tagged with 1024.

Anybody got a similar setup with running SR-IOV and VLAN?

Kind regards
Torsten

EDIT:
tcpdump ubuntu VM

Code: [Select]

ping 192.168.20.1
PING 192.168.20.1 (192.168.20.1) 56(84) bytes of data.
18:06:03.256121 00:16:3e:a0:18:f1 > 00:16:3e:a0:16:f1, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 18868, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.20.250 > 192.168.20.1: ICMP echo request, id 767, seq 1, length 64

tcpdump opnsense VM

Code: [Select]

18:10:09.974113 00:16:3e:a0:18:f1 > 00:16:3e:a0:16:f1, ethertype 802.1Q (0x8100), length 102: vlan 1024, p 0, DEI, ethertype IPv4, (tos 0x0, ttl 64, id 39437, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.20.250 > 192.168.20.1: ICMP echo request, id 778, seq 1, length 64


19

20.1 Legacy Series / DoT with unbound-plus in 20.1.5

« on: April 24, 2020, 12:48:13 pm »

Hi all,

after upgrading to 20.1.5 the unbound-plus plugin should have "Add DNS over TLS (DoT) support" as the changelog says. In the WebGui are new fields for private domains and DNS over TLS Servers.

I got the following settings in the custom field of unbound:

Code: [Select]

server:
    private-domain: "dbl.spamhaus.org"
    private-domain: "sbl.spamhaus.org"
    private-domain: "xbl.spamhaus.org"
    private-domain: "zen.spamhaus.org"
    private-domain: "bl.spamcop.net"
    private-domain: "XXXXX"
    private-domain: "YYYYY"
    private-domain: "ZZZZ"
    do-not-query-localhost: no
forward-zone:
    name: "."
        forward-addr: 1.1.1.1@853 # cloudflare
        forward-addr: 2606:4700:4700::1001@853 # cloudflare
         forward-addr: 185.49.141.37@853 #getdnsapi.net
         forward-addr: 2a04:b900:0:100::38@853 #getdnsapi.net
         forward-addr: 2a03:b0c0:0:1010::e9a:3001@853 # SecureDNS.eu
          forward-ssl-upstream: yes
How can I convert this to the new fields and what standard unbound parameters have to be set or unset to use DoT with the plus plugin? Have I to keep any parameter still in the custom field? Is there any documentation?

Kind regards
Torsten

20

19.7 Legacy Series / VLAN xen HVM crashes

« on: December 31, 2019, 12:08:58 am »

Hi all,

after several days of nightly crashes and some commands / functions, which crashes OPNsense immediately, I testes all day long what could be the reason.

Here is my configuration:

• Ubuntu 18.04.3 LTS (Bionic Beaver) with XEN 4.9.2
  xn0: bridge for WAN (Intel NIC)
  xn1: bridge for LAN (Intel NIC)
  xn2: bridge for DMZ (w/o NIC)
  xn3: bridge for WLAN (Intel NIC)
• OPNsense 19.7.8-amd64 as HVM domU
  3 GB RAM
  40 GB disk (with 4GB swap)
  
• FreeBSD 11.2-RELEASE-p16-HBSD
  
• DHCPD, NTPD, RADVD, UNBOUND
  

Starting tests from LiveCD and then a fresh installed domU. I think I could narrow down the reason for my crashes.

The crashes started, when I use VLANs on the WLAN interface xn3 in the new OPNsense domU again - without them, I couldn't force a crash. The VLANs have been configured in OPNSense with parent interface MTU 1504 and for the WLAN bridge set in dom0 to 1504 either. The VLANs work well and no TX drops in dom0 or domU.

I'm pretty sure now, that he VLANs are the reason for the nightly crashes too, since I introduced them some days before the update to 19.7.8. Here is what i tested and the results for the commands / functions that crashes the domU:

domU from LiveCD mode:
OPNsense 19.7-amd64
FreeBSD 11.2-RELEASE-p11-HBSD
OpenSSL 1.0.2s 28 May 2019

without IPv6 on WAN
no configuration
sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
---
domU from fresh install:
OPNsense 19.7-amd64
FreeBSD 11.2-RELEASE-p11-HBSD
OpenSSL 1.0.2s 28 May 2019

without IPv6 on WAN
minmal configuration (WAN & LAN)
sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
----
install os-xen 1.2 and reboot
sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
----
update --> 19.7.8
OPNsense 19.7.8-amd64
FreeBSD 11.2-RELEASE-p16-HBSD
OpenSSL 1.0.2t 10 Sep 2019

sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
----
activate DHCPv6 on WAN
sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
----
activate IPv6 on LAN (track WAN)
sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
----
restore DHCP, DHCPv6, system tunables, unbound conf from backup and reboot
sysctl -a via CLI: OK
Audit health via GUI: OK
edit pppoe via GUI: OK
---
restore interfaces (with VLANs) from backup and reboot
sysctl -a via CLI: crashes
Audit health via GUI: OK
edit pppoe via GUI: crashes

Hopefully somebody else has a working installation of OPNsense as HVM domU with VLANs. Since I haven't found anything similar here in the forum or with google, any advice what could be wrong with my configuration is appreciated.

A crash report (sysctl -a) was sent after reboot with the last configuration from my test domU. If necessary, I can do more tests or try to debug /  to trace.

Kind regards
Torsten

21

19.7 Legacy Series / Editing / Adding Point-to-Point Devices crashes system

« on: December 25, 2019, 11:03:22 am »

Hi all,

while trying to identify the reason for my frozen system (https://forum.opnsense.org/index.php?topic=15354.0), I found another problem on my system running:

OPNsense 19.7.8-amd64
FreeBSD 11.2-RELEASE-p16-HBSD
OpenSSL 1.0.2t 10 Sep 2019

For my WAN connection I use the configuration type PPPoE which works fine. But when I try to edit (Interfaces -> Point-to-Point -> Devices) the existing device pppoe0 my system crashes. Same when I try to add a new device. After the reboot, I found a crash report in the GUI, which I sent via the  GUI.

In the case of editing the existing device, I found this information in a open ssh session:

Code: [Select]

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x0
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff80d1404f
stack pointer           = 0x28:0xfffffe00963505d0
frame pointer           = 0x28:0xfffffe00963505d0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 89259 (sysctl)
Couldn't find anything similar in the forum.

Kind regards and merry XMas
Torsten

22

19.7 Legacy Series / OPNSense GUI / CLI not accessable (obsolete)

« on: December 24, 2019, 02:40:12 pm »

Hi all,

since the last update to

OPNsense 19.7.8-amd64
FreeBSD 11.2-RELEASE-p16-HBSD
OpenSSL 1.0.2t 10 Sep 2019

something strange happens every night to my OPNsense system running as VM under XEN. The system isn't accessable neither trough GUI nor via CLI (ssh) in the morning. All other functions seem ok, at least I can access the internet.

I can't find anything in the logs and even a new installation with backup of the configuration shows the same behavior.

I can force this behavior when doing a health check via GUI or with  pkg check -sav in a ssh session. Both will let the GUI and CLI die.

What can I do? Where can I look for more information what is going wrong?

Any help is appreciated, since I'm new to OPNSense...

Kind regards
Torsten