Messages

Hi, thanks again for publishing your plugin and sharing your work.

I forked your repository and used it as a starting point for my environment. 
I've rewritten a large part of it since then, but your project was the base that made this possible, so I want to explicitly acknowledge that.

I'm using it on OCN Fixed IP (IPoE) and it's working well here. 
Really appreciate you open-sourcing this and sharing the initial implementation.

I revert the patches in order and found that communication is not possible if the following commits are applied

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

I referred to that commit and found the cause

It was caused by using a 10Gbp/s line and setting Shaper's default pipe to 10Gbp/s!

You cannot view this attachment.

In my previous input, I used
https://github.com/opnsense/core/issues/5224
There was a section where I had entered 10000 Mbp/s because there was no limit on the number of Mbp/s, and I had to retype this as 40000 Mbp/s or 4 Gbp/s, or use the command revert

# opnsense-patch e4f0e92

Communication was restored with no problems.

Captive Portal is not used.
You cannot view this attachment.

Firewall is configured as follows
You cannot view this attachment.
You cannot view this attachment.

> You don't share any details about your topology that could narrow the problem down. Physical isolation? VLAN?

OPNsense is running as a VM in XCP-ng and has a virtual NIC assigned to it
You cannot view this attachment.
You cannot view this attachment.

After updating to OPNsense 25.1.5, I'm unable to reach the DMZ  network.
Cannot communicate directly to the DMZ network from the LAN/WAN to a global address and cannot ping the DMZ network.
Internet connection from LAN is not a problem

https://github.com/opnsense/core/commits/25.1.4
https://github.com/opnsense/core/commits/25.1.5

I've been comparing commits, and I haven't been able to find a commit on my own that relates to this event.

• I've diff'd the routing table output from 25.1.4 and found no difference from 25.1.5.
• I have tried shutting down services that can be shut down, but communication is not restored.
• I logged into the router via SSH and tried pinging the DMZ address, but no response.
• I tried installing again from the ISO, but at the time of upgrade to 25.1.5, communication with the DMZ is lost.
• Pinging OPNsense from a server located in the DMZ still does not return a ping.
• 25.1.5 during startup There is a timing when the ping returns when the interface becomes active, but Configuring fireuall.... However, pings are not returned around the timing of "Configuring fireuall.

This issue did not occur in 25.1.4. Are there any known issues or changes that might cause this?

The problem was solved by upgrading to 24.7.1.
Thank you for your excellent work.

Upgraded from 24.1 to 24.7 running on XCP-ng

Intrusion Detection is turned off or IPS mode in Suricata is unchecked and kernel panic does not occur

Code Select Expand

Fatal trap 12: page fault while in kernel mode
cpuid = 10; apic id = 14
fault virtual address = 0x30
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80a0f15f
stack pointer         = 0x28:0xfffffe0121e228e0
frame pointer         = 0x28:0xfffffe0121e22970
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 = 34811 (W#01-xn1^)
rdi: fffff80006de9000 rsi: fffff80008746300 rdx: fffff80008746300
rcx: fffff80004175800  r8: 00000000000000f8  r9: 00000ac9ea080000
rax: 00000000000000ff rbx: fffffe006d2f3000 rbp: fffffe0121e22970
r10: de19cd6057e97e01 r11: fffff8000bb94c60 r12: 0000000000000000
r13: fffff80006300800 r14: fffffe0121e22944 r15: fffff80008746300
trap number = 12
panic: page fault
cpuid = 10
time = 1721996741
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0121e225d0
vpanic() at vpanic+0x131/frame 0xfffffe0121e22700
panic() at panic+0x43/frame 0xfffffe0121e22760
trap_fatal() at trap_fatal+0x40b/frame 0xfffffe0121e227c0
trap_pfault() at trap_pfault+0x46/frame 0xfffffe0121e22810
calltrap() at calltrap+0x8/frame 0xfffffe0121e22810
--- trap 0xc, rip = 0xffffffff80a0f15f, rsp = 0xfffffe0121e228e0, rbp = 0xfffffe0121e22970 ---
xn_txq_mq_start_locked() at xn_txq_mq_start_locked+0xdf/frame 0xfffffe0121e22970
xn_txq_mq_start() at xn_txq_mq_start+0x76/frame 0xfffffe0121e229a0
nm_os_generic_xmit_frame() at nm_os_generic_xmit_frame+0xa0/frame 0xfffffe0121e229f0
generic_netmap_txsync() at generic_netmap_txsync+0x3a2/frame 0xfffffe0121e22ae0
netmap_ioctl() at netmap_ioctl+0x1a7/frame 0xfffffe0121e22bb0
freebsd_netmap_ioctl() at freebsd_netmap_ioctl+0x79/frame 0xfffffe0121e22bf0
devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfffffe0121e22c40
vn_ioctl() at vn_ioctl+0xce/frame 0xfffffe0121e22cb0
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0121e22cd0
kern_ioctl() at kern_ioctl+0x255/frame 0xfffffe0121e22d40
sys_ioctl() at sys_ioctl+0xff/frame 0xfffffe0121e22e00
amd64_syscall() at amd64_syscall+0x100/frame 0xfffffe0121e22f30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0121e22f30
--- syscall (54, FreeBSD ELF64, ioctl), rip = 0x82dcc75fa, rsp = 0x8466f7df8, rbp = 0x8466f7e20 ---
KDB: enter: panic
panic.txt0600001214650712705  7140 ustarrootwheelpage faultversion.txt0600007514650712705  7544 ustarrootwheelFreeBSD 14.1-RELEASE-p2 stable/24.7-n267758-4ad7ad40bc77 SMP
/var/crash/textdump.tar.1:

Over the last few days I've done quite a bit of research in ipsec.conf and debug logs, and while I can't be sure, I have a feeling it's a FreeBSD 13 and Strongswan issue.

I'm thinking of waiting a bit to see if the problem resolves itself.

Over the last few days I've done quite a bit of research in ipsec.conf and debug logs, and while I can't be sure, I have a feeling it's a FreeBSD 13 and Strongswan issue.

I'm thinking of waiting a bit to see if the problem resolves itself.

I raised it to 22.1.4 and revalidated it.

IPv6 is still not available only

I raised the debug level and investigated the logs

Code Select Expand

[KNL] <con1|1> installing route failed: 2001:AAAA:BBBB:5::1/128 via <ISP Upstrem> src %any6 dev pppoe0
[KNL] <con1|1> adding PF_ROUTE route failed: Invalid argument


adding PF_ROUTE route failed

I have looked up various descriptions of this error

https://wiki.strongswan.org/issues/3285
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678
https://github.com/strongswan/strongswan/issues/275

This will be fixed in 13.1-RELEASE?

But what I wonder is that the same error appears in 21.7.8, but the communication itself is fine.

I also thought it might be a strongswan issue, so I ran pkg create strongswan on 21.7.8, then pkg install and restart on 22.1.4... same problem, only IPv6 was not available.
On the contrary, strongswan-5.9.4 works fine on 21.7.8


It may still be a problem with FreeBSD 13.0

I upgraded to 22.1.3 and the problem is still there!

I tried setting it to IPv4 over IPv6 phase 2 tunnel only, but icmp still does not go through

I tried with 22.1.2 and the development version, but still icmp does not reach only v6 as well

But while changing the settings, I noticed something odd.

Change any of the interface options in the WebGUI and apply them, and icmp will pass!

Or, at the console, you can use the
11) Reload all services
the icmp goes through with no problem, and the actual IPv6 communication is fine!

If you reboot and do not perform this procedure manually the problem will not be solved

Why?

I tried to set it up from the beginning, but still only v6 does not pass the icmp.

But I did notice something odd.
When I connect the VPN client from the LAN side of the router, it returns an icmp
If I switch my iPhone to a 4G/LTE network and go through the WAN, it still doesn't seem to be able to communicate!

Perhaps it is not pf but routing that is causing the problem.
I don't know the cause yet.

No, 22.1.1 does not solve the problem.

Rolled back the OPNsense VM from Snapshot to 21.7.8 and it is working fine on 21.7.8

I also checked the difference in routing tables between 22.1 and 21.7.8, and there was no problem.

I hope this problem will be solved.