IPv6 https-proxy issue
Hi All,
I'm rolling out IPv6 internally through my M470, and I get these spurious logs.
2024-04-22 10:46:14 https-proxy 0x2c1f480-64896 681: 2a00:xxxx:yyyy::50:53741 -> 2603:1020:705:8::400:443 [!B fc] {N}: Side channel SSL failed (Domain: N/A) - proceed with rule check Debug
2024-04-22 10:46:14 pxy 0x2c1f480-64896 connect failed Connection timed out -1: :::0 -> :::0 [!A] {N} | 681: 2a00:xxxx:yyyy::50:53741 -> 2603:1020:705:8::400:443 [!B c] {N}[L!BPeo] Debug
The 2a00:xxxx:yyyy::50 is the IPv6 on the WAN interface, not the IPv6 on the LAN interface.
I actually have OPNSense behind the Watchguard LAN doing NPTv6 to translate ULA to GUA, but I do not think this is anything to do with the issue above.
I am routing a /60 down from an upstream OPNSense router to the Watchguard appliance.
Anyone any ideas what this might be? It doesnt appear to be affecting anything, but is annoying me.
Thanks
Alan
Comments
I'm seeing the same thing on my M390 with one of the VLAN addresses for the Firebox:
2024-04-22 09:56:30 https-proxy 0x38a85980-23848 114: 2600:4040:xxxx:yyyy:::54483 -> 2001:4998:58:207::6000:443 [!B fc] {N}: Side channel SSL failed (Domain: N/A) - proceed with rule check
All of the logs are saying that B channel (the side of the connection from the firewall to the distant webserver) are failing. I would check that side of the connection. If this is failing for multiple sites, it might be possible that IPv6 is not set up correctly on this/these firewalls.
-James Carson
WatchGuard Customer Support
That’s what I don’t understand. IPv6 works perfect all the way downstream. That IPv6 is just a hop through the firewall, so I fail to see what….from the WAN side of the firebox….is going through the https proxy.
You can’t really get the IPv6 config wrong….it has an IPv6 on the WAN with a routed subnet of /61 via that IP.
Hello,
I have exactly the same problem. I have been using IPv6 for several months and there have been no problems so far.
However, I also get this error message on the following website "--removed--".
pxy 0x6789a60-30408998 connect failed Connection timed out -1: :::0 -> :::0 [!A] {N} | 3205: 2a02:810d:8000:7b:189e:a972:12df:c4d5:42677 -> 2a01:4dc0:0:4f00::c272:2011:443 [!B c] {N}[L!BPeo] Debug
https-proxy 0x6789a60-30408998 3205: 2a02:810d:8000:7b:189e:a972:12df:c4d5:42677 -> 2a01:4dc0:0:4f00::c272:2011:443 [!B fc] {N: Side channel SSL failed (Domain: N/A) - proceed with rule check Debug
If I turn off the HTTPS proxy, I can access the website via IPv6 without any problems.
I have already added the site to the exceptions of the HTTPS proxy, but it still doesn't work.
Only if I completely bypass the HTTPS proxy can I access the website via IPv6
The log message here is saying that there appears to be a problem with the B channel -- this is the side from the firebox out to the internet.
I'd suggest opening a support case if you need this traffic proxied -- one of our support reps can help assist with troubleshooting this with you.
-James Carson
WatchGuard Customer Support
With respect @james.carson, this is now 3 reports of exactly the same thing being presented here. To me, it would seem counterintuitive for all 3 of us to raise support requests on the same issue, when I think this is probably an issue somewhere in the HTTPS proxy.
Do you not have an option to raise this internally as a potential issue, and point support to this forum post?
Hi @Alan_Plummer
In order to get a bug started (assuming it is a new issue) or to match your issue with an existing bug, I'd really need you to open a support case. The specific log lines from the proxy aren't enough to reproduce or fix an issue.
If you haven't done so, I'd suggest creating a support case.
-James Carson
WatchGuard Customer Support
Hello,
i have started a support case.
This is the case number: 02069737
Hello,
after some investigations by WatchGuard, they were able to reproduce the case.
This is WatchGuard’s response to this case:
The site www.vwgroupsupply.com resolves to 2a01:4dc0:0:4f00::c272:2011 on IPv6 but the Webserver does not respond there.
When using Packet Filter, the Browser falls back to the resolved IPv4 address
Now when using the HTTPS Proxy this is a little more tricky:
The internal channel Client PC -> Firebox Proxy gets established
The external channel Firebox -> Webserver runs into timeout since the server is not responding
Due to this internal channel the Client Browser cannot failback to IPv4 and the site times out.
We do have a feature enhancement request open for this but there is probably nothing which can be done against this though
FBX-19484 Browser Fallback from IPv6 to IPv4 not working when using Proxies.