Messages

Ich habe bei mir solche Services unter Proxmox mit OPNsense als einer VM laufen, der Traffic läuft vom Host über die OPNsense zu den anderen VM, die Quelladresse bleibt aber erhalten trotz 1:1 NAT oder Portdorwarding und Nutzung von privaten IP für die internen Verbindungen.

Warum sollte die Quelle IP überschrieben werden, die Ziel IP muss richtig gesetzt werden und Outbou d wieder korrekt erfolgen. Das passiert aber bei Port Forward bzw 1:1 NAT

I see the same issue after upgrading to 24.1.10

kex_exhange_identification: Connection closed by remote host.

Luckily I could access the console via Proxmox and after reloading all services, ssh did work again.

I did some more checks and the firewall blocks *all* IPv6 traffic with the "Default deny / state violation rule" even when a matching global ACCEPT rule on all interfaces is defined.

@Franco Looks like the packet filter is not processing any IPv6 rules despite that they're shown in the GUI.

Of course, IPv6 is enabled in the Interface settings.

Hey!

A user of my system reported issues access my IMAP server by IPv6.

After some digging around, I found his IPv6 in the firewall-logs

Code Select Expand

17,,,02f4bab031b57d1e30553ce08e0ec131,vtnet4,match,block,in,6,0x00,0xeb111,64,tcp,6,40,2a01:XXXX:fe02::110,2a00:XXXX:ea05,993,61465,0,SA,3642631772,3523825403,21420,,mss;sackOK;TS;nop;wscale

Rule 17, label 02f4bab031b57d1e30553ce08e0ec131 is the global IPv4/6 Default deny / state violation rule

Code Select Expand

@16 block drop in log inet all label "02f4bab031b57d1e30553ce08e0ec131"
  [ Evaluations: 1886      Packets: 279       Bytes: 12488       States: 0     ]
  [ Inserted: uid 0 pid 79740 State Creations: 0     ]
@17 block drop in log inet6 all label "02f4bab031b57d1e30553ce08e0ec131"
  [ Evaluations: 1886      Packets: 427       Bytes: 45298       States: 0     ]
  [ Inserted: uid 0 pid 79740 State Creations: 0     ]

I inserted a specific rule for his addresses (beside that the mail server has it's v4/v6 rules allowing access to all mail ports). I see other v6 addresses with the same issue, on v4, it works.

OPNsense 24.1.9_4-amd64

Anybody a good idea how to solve that, I was told it started recently, might be around the 24.1.9 update.

Btw. ist deine Fritzbox nicht auf der *.*.*.1 ‽

Ich habe gerade nochmal geschaut, wenn ein LAN Interface angelegt ist, wird ankommender Traffic auf dem WAN geblockt, wenn keine Regeln dort definiert worden sind. Bei einem neuen Setup kommt man also an die WebGUI vom WAN aus nicht heran, wenn es ein LAN Interface gibt (solange man das nicht per Regel erlaubt).

I only use the GUI, I do not manipulate the config file directly. But still, a DHCP should not crash on that leaving the whole network unusable. It's an error, but not a fatal one.

Hey!

I recently switched a pfSense to OPNsense and after having done so, I added some VLAN to encapsulate IoT and Amazon Devices. Now I am moving devices from the main network to those new VLAN tagged Wifi networks.

Adding another entry (previously assigned an address with DHCP), KEA crashed with

Code Select Expand


2024-06-22T14:57:30 Error kea-dhcp4 ERROR [kea-dhcp4.dhcp4.0x8366ae000] DHCP4_INIT_FAIL failed to initialize Kea server: configuration error using file '/usr/local/etc/kea/kea-dhcp4.conf': failed to add new host using the HW address 'd8:13:2a:4a:09:2c and DUID '(null)' to the IPv4 subnet id '2' for the address 192.168.28.101: There's already a reservation for this address
2024-06-22T14:57:30 Error kea-dhcp4 ERROR [kea-dhcp4.dhcp4.0x8366ae000] DHCP4_CONFIG_LOAD_FAIL configuration error using file: /usr/local/etc/kea/kea-dhcp4.conf, reason: failed to add new host using the HW address 'd8:13:2a:4a:09:2c and DUID '(null)' to the IPv4 subnet id '2' for the address 192.168.28.101: There's already a reservation for this address
2024-06-22T14:57:30 Error kea-dhcp4 ERROR [kea-dhcp4.dhcp4.0x8366ae000] DHCP4_PARSER_FAIL failed to create or run parser for configuration element subnet4: failed to add new host using the HW address 'd8:13:2a:4a:09:2c and DUID '(null)' to the IPv4 subnet id '2' for the address 192.168.28.101: There's already a reservation for this address

I checked the config and there was no duplicate entry for that mac. I managed to get access to the OPNsense again and deleted the single entry from the config thus got it working again.

Beside that, even if, such an error should result in a warning and skipping of the second (duplicate) entry marking him erronous in the reservations section but must not prevent KEA from starting as a running DHCP can be critical to access the network.

Ich erinnere mich zumindest beim Einrichten der OPNSense an Hinweise, dass ohne Firewall Regeln kein Traffic durchgelassen wird. Ich ersetze auch gerade mehrere pfSense durch OPNsense.

Hast du in der Firewall die nötigen Regeln eingetragen?

@franco Thx, I change my config and find another solution. Also thanks for the hot fixes.

@franco

Could you point me to the part of the documentation?

Strange, that never happened before and it's a local address.

@franco

Just found a similar problem. My fw1 on my main node did not properly start after a reboot and 24.1.9 applied, I had to restore a backup with 24.1.8, before the reboot, fw1 worked fine. So I leave fw1 on 24.1.8

fw2 on another node run so far, I applied 24.1.9_1 and restart the VM, the system came up and UI initially worked and then died,

/usr/local/etc/rc.restart_webgui

helped to restart the GUI. Log of the WebGUI only shows the manually restart of the WebGUI.

In the logs, I found this

Code Select Expand

/usr/local/etc/rc.bootup: The command '/usr/local/bin/flock -ne /var/run/lighty-webConfigurator.pid /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2024-06-19 20:24:00: (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.76/src/network.c.604) bind() [fe80::be24:11ff:fe1d:b261]:80: Can't assign requested address'

If you need anything specific, let me know. I try my best.

I needed quite some effort to get the combination of Proxmox 7 and OPNSense on a Hetzner root server running.

Finally, I ordered a /56 (10 Euro one time for assignment although RIPE tells one should get a /56 and not a /65, nice cash cow), created two interfaces (one for routing between the host and OPNSense) and the other one as internal v6 interface between the VMs.

That did work finally.

@eakteam I can give you a copy of my working /etc/network/interfaces but you need to order that additional /56 network.

During the weekend, I migrated all VM to a new machine with Proxmox 8.

Hetzner IP handling requires a manual hardware exchange to keep the existing v4/v6 IPs.

After that was done, I noticed the following day, that IPv6 inbound to the VM was again broken. Ping was possible, outbound from the VM did work and everything has been left untouched.

I just discovered the reason.

On creation of that internal IPv6 vmbr interface for v6 communication between the VMs (OPNsense and the rest), a routing rule was added for this internal /64 before the routing rule to get v6 traffic from the host to OPNsense was added.

This new rule (did not happen with Proxmox 7) took obviously precedence over the routing rule of v6 traffic to OPNsense.

After deleting it before adding the v6 OPNsense routing rule on the host, the problem was gone.

I can only recommend to check not only interface and iptables setting but especially the routing table.

On Proxmox 7 I had a similar issue on the v4 side, I needed to delete a rule there, too.

XXXX:XXXX:XXXX:XXXX:: the /64 network used solely on the host
YYYY:YYYY:YYYY:YY:: the /56 network used for the VM

The troubling rule is marked with ***, the removal of that rule solved it.

Code Select Expand

================ new (troubling) routing table ========================
XXXX:XXXX:XXXX:XXXX::2 dev eno1 proto kernel metric 256 pref medium
XXXX:XXXX:XXXX:XXXX::/64 dev vmbr1 proto kernel metric 256 pref medium
YYYY:YYYY:YYYY:YY01::/64 dev vmbr2 proto kernel metric 256 pref medium
*** YYYY:YYYY:YYYY:YY02::/64 dev vmbr3 proto kernel metric 256 expires 86246sec pref medium ***
YYYY:YYYY:YYYY:YY02::/64 via 2a01:4f8:191:fe01::3 dev vmbr2 metric 1024 pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
fe80::/64 dev vmbr1 proto kernel metric 256 pref medium
fe80::/64 dev vmbr2 proto kernel metric 256 pref medium
fe80::/64 dev vmbr3 proto kernel metric 256 pref medium
fe80::/64 dev eno1 proto kernel metric 256 pref medium
fe80::/64 dev vmbr4000 proto kernel metric 256 pref medium
default via fe80::1 dev eno1 proto kernel metric 1024 onlink pref medium
default via fe80::8031:e8ff:fe74:2ded dev vmbr3 proto ra metric 1024 expires 1646sec hoplimit 64 pref medium


Dazu muss man auf dem Android Gerät OpenVPN installieren und dann lassen sich dort einzelne Apps fest über das VPN routen.

Vlt solltest du erstmal den Beitrag vollständig durch lesen. Habe ja geschrieben das es für Androids Apps gibt in meinen Fall Wireguard. Die saugen mir aber den Akku leer.

Zum Tonfall sage ich lieber nichts.

Ich nutze genau diese Lösung mit OpenVPN for Android permanent auf drei Android Geräten parallel im privaten und im Business Profil, um bestimmte Apps auf das VPN zu zwingen. Sonst hätte ich das nicht so beantwortet. Ich habe deswegen auch bewusst OpenVPN und nicht VPN Apps geschrieben.