Menu

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.

Show posts Menu

Messages - Mirio

#1
It was the 6.8.12-13-pve. Yes i've found the issue on the pve forum
#2
After some deep dive into it, i've resolved it downgrading the kernel for proxmox to 6.8.12-7-pve.
Thank you!
#3
The concept behind it is quite straightforward, although I'm not sure if it's the right choice. If that's the case, I'd appreciate it if you could let me know if there are more tailored or specialized options for OPNsense. All the VMs in that network have only one NIC within that bridge, and OPNsense manages all the traffic acting as a gateway.

#4
Yeah, below the the routes

Routing tables

Internet:
Destination        Gateway            Flags        Netif Expire
default            xxx.xxx.xxx.xxx    UGS            igc0
127.0.0.1          link#5            UH              lo0
....
192.168.50.0/24    link#3            U            vtnet0
192.168.50.1      link#5            UHS            lo0
....


# ifconfig vtnet0

vtnet0: flags=1088843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,STATICARP,LOWER_UP> metric 0 mtu 1500
    description: LAN50 (opt1)
    options=80028<VLAN_MTU,JUMBO_MTU,LINKSTATE>
    ether [REDACTED]
    inet 192.168.50.1 netmask 0xffffff00 broadcast 192.168.50.255
    media: Ethernet autoselect (10Gbase-T <full-duplex>)
    status: active
    nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

You cannot view this attachment.



I'm not sure if it's relevant, but OPNsense is hosted inside Proxmox (yes, proxmox needs a IP in the network for a specific reason), and this interface is configured as follows on the Proxmox side:
auto vmbr50
iface vmbr50 inet static
    address 192.168.50.210/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0
#5
No, the node 192.168.50.100 is a old node pre migration. Same network as .189.
How can I search for problems on the nic? Do i have to launch some cmd?
#6
Hi all,
Yesterday, I performed an upgrade from OPNsense 25.1 to 25.7 via the web UI. I immediately encountered issues regarding the addition of new nodes.

What is the issue?
The issue is that when I try to add a new node (new MAC address and IP), the DHCP packet arrives successfully. However, any other packet (TCP/ICMP/UDP, etc.) seems to be correctly sent and received by OPNsense (verified via packet capture), but the opnsense node does not respond. Meanwhile, all older nodes (configured before the migration) continue to function without issues. Firewall rules are exactly the same for both old and new nodes.

A particular curiosity I noticed is that new nodes are not pingable from OPNsense and return the error **"invalid argument"**.

Here's a small snippet for reference
# opnsense > ping -c 2 192.168.50.189
PING 192.168.50.189 (192.168.50.189): 56 data bytes
ping: sendto: Invalid argument
ping: sendto: Invalid argument

--- 192.168.50.189 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss

# opnsense > ping -c 2 192.168.50.100
PING 192.168.50.100 (192.168.50.100): 56 data bytes
64 bytes from 192.168.50.100: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 192.168.50.100: icmp_seq=1 ttl=64 time=0.149 ms

--- 192.168.50.100 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.141/0.145/0.149/0.004 ms

What types of tests and actions have I already done?
- I've manually migrated from ISC to DNSMASQ (DHCP+DNS)
- Flush ARP table
- Full restart of OPNSENSE and 'target' VM
- Firewall rules reviewed (floating and automatic included)
- Search on the forum and google

Any idea?
Thank you
#7
Thanks to Monviech on IRC
Quote
Try to set "State Type" in the Advanced Features of the firewall rule that allows the traffic to "Sloppy State" and TCP flags to "Any flags.

And now it works!
Thank you
#8
Hi all,
I am encountering a particular behavior, specifically the traffic between two nodes is first allowed and shortly after various data is blocked by the default deny. I would like to point out that there is a specific permit rule for this traffic.

More specifically:

  • Source server: 192.168.50.32 (VM)
  • Destination Server: 192.168.150.21 (K8s with MetalLB + BGP rule with os-frr)
  • Traffic: PSQL (5432 TCP)
  • LAN 50 = VM Networking
  • LAN 150 = Dedicated for BGP routing
  • Firewall rule: I have a specific rule on LAN 50/150 to allow that traffic.

Lan50:


Lan150:


Step to replicate:

  • Jump on the VM
  • Use psql import to import psql dump (10Mb)
  • Some data pass and then blocked

Below the image of firewall log:


Any tips?
Thanks