Messages

Maybe it's a feature request

A Feature Request? No, it is a bug.

but it looks like work

Bugs usually are?

and you haven't answered Michael yet.

Because the reply was after I posted this, and I went to sleep?

I posted a bug on Github in Mar of 2021, this is still a problem on 22.1.8_1
https://github.com/opnsense/core/issues/4866

Dual stack Routed IPsec (VTI) has some issues, adding/enabling 2nd Phase 2 with IPv6 breaks IPv4 Phase 2, disabling IPv6 phase 2 allows both IPv4 and IPv6 to work.

Seems the behavior has not changed between 21.1.3_3 and 22.1.8_1.

Anyone seen this, anyone have a fix?

Probably a bug.

But you are going to need to provide more information.

What hardware is OPNsense running on? What NIC? What is on the other side of the link?

Still hoping for something to try, or what information I need to gather to help troubleshoot the issue or anything like that.

Hoping someone has an idea. Or even so step to take to trouble shoot where the issue is exactly.

I am using a rule on the LAN (2, one for v4 one for v6) to specify any traffic from a particular IP is forced over the Wireguard VPN Gateway. But I also have to NPt that /128 address as the VPN only has a single IPv6.

All outbound work fine, full 2way if the connection is initiated in the outbound direction, it is the Replies to Inbound traffic that get stuck on their way out (confusing I know heh)

Syn from Internet:
Internet Host -> VPN Public IP -> VPN ULA IP -(NPt)> OPNsense -> LAN Host   (Makes it to the Lan Host OK)

Syn Ack back to Internet Host:
LAN Host -> OPNsense X (Is seen on the OPNsens LAN, never makes it out onto the VPN interface with ot without NPt applied)

After re applying the patch due to removal when posting previous output. And rebooting again. It does seem to be back to working.

No idea why it didn't the first time.

Code Select Expand

Napsterbater@car1:~ % sudo opnsense-patch
Napsterbater@car1:~ %

Code Select Expand

Napsterbater@car1:~ % sudo opnsense-patch 61500f6790
Found local copy of 61500f6790, skipping fetch.
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--------------------------
|From 61500f6790969ba1c426c27322ba8879dd96bd5a Mon Sep 17 00:00:00 2001
|From: Franco Fichtner <franco@opnsense.org>
|Date: Mon, 21 Mar 2022 09:24:09 +0100
|Subject: [PATCH] interfaces: suspicious code is suspicious
|
|I'm not sure why interface_bring_down() is needed when both
|IPv4 and IPV6 are empty.  It sort of means "handle this the
|hard way when doing tunnel configurations" althoug the code
|disagrees about the historic comment and the code that was
|introduced... "set to none" vs. "ipaddr <> none" and later
|"empty(ipaddr)" to match the comment.  In the grand scheme of
|things this does not matter at all...
|
|So in 22.1.3 we removed the inline configuration of GIF and GRE
|which causes interface configuration to strip the addresses
|added by device configuration instead of refixing it on the
|fly (executing code twice all the time).  The code flow was
|always correct but in practice tripping over itself so now try
|a more sensible approach by stripping addresses when we have
|assignments going on individually for IPv4 and IPv6.
|
|PR: https://forum.opnsense.org/index.php?topic=27553.0
|---
| src/etc/inc/interfaces.inc | 14 ++++++--------
| 1 file changed, 6 insertions(+), 8 deletions(-)
|
|diff --git a/src/etc/inc/interfaces.inc b/src/etc/inc/interfaces.inc
|index 4ab49d680a..79876b1ba3 100644
|--- a/src/etc/inc/interfaces.inc
|+++ b/src/etc/inc/interfaces.inc
--------------------------
Patching file etc/inc/interfaces.inc using Plan A...
Reversed (or previously applied) patch detected!  Assuming -R.Hunk #1 succeeded at 2200 with fuzz 1 (offset 33 lines).
done
All patches have been applied successfully.  Have a nice day.

"Reversed (or previously applied) patch detected!  Assuming -R.Hunk #1 succeeded at 2200 with fuzz 1 (offset 33 lines).
done"
So it was installed?

Tell me what details do you need. What specific log outputs do you need. Because nothing I found in the web UI logs. Tell me anything useful.

All I know is the IP addresses are not being assigned to the interface. That's the gateway can't be created. This all started on 22.1.3
I have applied the patch, I've deleted the GIF interface I've deleted interface assignment. I've tried to recreate the gateway. Nothing works. System reboots don't work either.
I have a DHCP WAN with a Static Virtual IP that the GIF is attached to.

Mullvad VPN using Wireguard. It has a Single IPv4 and IPv6.

I am using PBR to redirect a single IPv4 and a single IPv6 on the LAN out the Mullvad VPN, I am using Outbound NAt on IPv4 and NPt with a /128 for IPv6.

For IPv4 I also have port forwarding. IPv4 work perfectly fine, inbound and outbound connections are perfect.

IPv6 though, outbound is fine, outbound initiated connections has full 2way traffic.

Inbound is half fine, I can see the SYN make it to my server, the server replies SYN ACK, the SYN ACK hits the LAN of OPNsense, but the packet never makes it out the Mullvad interface.

But again, Outbound initiated traffic get through and NPt ed to the Mullvad Interface IPv6.


Where should I start looking, what can I provide to help track down the problem.

Edit: I did find this, which kinda fits what I am seeing, but there was no resolution.
https://forum.opnsense.org/index.php?topic=3076.msg9553#msg9553

Even with "opnsense-patch 61500f6790" my HE GIF Tunnel is completely broken.

Seems an address is not getting assigned per the INTERFACES -> OVERVIEW screen.

I also have found since updating to 22.1 that RA would not start.
After much messing and many reboots, I removed the DNS servers entries I had in all the interfaces on RA and rebooted and it started working.
I then put them back again (to the DNS servers I wanted in there) and rebooted again.

Now it SEEMS to be back to normal.... in that RA starts on boot up and the problem has gone.... I think....

Chris

I just upgraded 2 system from 21.7.7 through to 22.1.1_1.

The RA service was stopped and refused to start, I went though and clicked save on each interfaces config page with no changes in the RA service and it came back up.

Something is wrong, I have 2 system generating crash reports related to Acme.

Use http://test-ipv6.com/, i you get 10/10 there, no need to change anything you Ipv6 will work fine.

https://ipv6-test.com/ takes points off for no ping response and rDNS neither of which are needed or a working IPv6 connection.

Ping is only really required if you are going to be talking with teredo clients, which teredo is deprecated anyways.

What https://ipv6-test.com/ doesn't seem to test or is PMTUD issues, where as http://test-ipv6.com/ does.

And rDNS, just isn't needed, epically on a home system.

The rule allows TCP/UDP port 53, the connection blocked was on port 443 I.e. HTTPs or DoH

Actually nevermind, its hard to tell with that picture.