Very weird issue with a clients ONE NZ Fibre connection with Certificates

Forums › One New Zealand (including Vodafone, WxC, Farmside) › Very weird issue with a clients ONE NZ Fibre connection with Certificates

1 | 2

mobiusnz

454 posts

Ultimate Geek

#3337046 29-Jan-2025 18:03

The cert is a rapidssl issues cert valid until July 31st. They have about 50 users who will use the SSTP vpn and I've only had two have this issue. One on OneNZ and one on 2Degrees so that rules out some weird provider issue now.

I'm just scratching my head. I think if it continues I'll go out with an ordinary router and see if it behaves. The original guy has an Orbi too but he says he's had it for a long time but this problem was a new one but he might have it setup wrong aswell where he's ending up with a double NAT which might be the cause.

Matt Beechey Mobius Network Solutions

saf

153 posts

Master Geek

ID Verified

Trusted

Vetta Group

Subscriber

#3337047 29-Jan-2025 18:14

Does the FQDN have a AAAA IPv6 DNS record, and are the problematic clients connecting via IPv6 to an improperly configured endpoint perhaps? (vs working on IPv4)

My views are as unique as a unicorn riding a unicycle. They do not reflect the opinions of my employer, my cat, or the sentient coffee machine in the break room.

RunningMan

8913 posts

Uber Geek

#3337112 29-Jan-2025 19:26

mobiusnz:[snip]. I was at the users home to tweak their routers LAN subnet as it was the same as the office -

Is it a manifestation of a bigger related issue to this? Does the RRAS have visibility of another private IPv4 subnet that's using the same private address space as the affected users?

mobiusnz

454 posts

Ultimate Geek

#3337195 30-Jan-2025 09:15

RunningMan:

mobiusnz:[snip]. I was at the users home to tweak their routers LAN subnet as it was the same as the office -

Is it a manifestation of a bigger related issue to this? Does the RRAS have visibility of another private IPv4 subnet that's using the same private address space as the affected users?

Yesterdays issue was that the VPN she was connecting to had the identical address space as her home network hence why once connected to the VPN she couldn't print to her network printer. It was after changing to a completely different IP subnet the error arrived.

Matt Beechey Mobius Network Solutions

mobiusnz

454 posts

Ultimate Geek

#3337196 30-Jan-2025 09:16

saf:

Does the FQDN have a AAAA IPv6 DNS record, and are the problematic clients connecting via IPv6 to an improperly configured endpoint perhaps? (vs working on IPv4)

You had me thinking for a minute it could be IPv6 related - But no, there isn't an IPv6 dns entry at all.

Matt Beechey Mobius Network Solutions

mobiusnz

454 posts

Ultimate Geek

#3337691 31-Jan-2025 13:13

Well - User 1's problem issue went away. I'll go out on a limb and say its when his provider issued a new IP??

I have checked and recorded User 2's current IP as even though its dynamic, dynamic IP's from providers with Fibre are far more resilient these days.

I've searched through the Fortinet and can find no record of it recording something odd and rejecting the connection or blocking the IP.

I'm stumped as to whats triggering it unless the Orbi's are doing something particularly thick??

Matt Beechey Mobius Network Solutions

r0bbie

242 posts

Master Geek

#3337696 31-Jan-2025 13:24

mobiusnz:

Well - User 1's problem issue went away. I'll go out on a limb and say its when his provider issued a new IP??

I have checked and recorded User 2's current IP as even though its dynamic, dynamic IP's from providers with Fibre are far more resilient these days.

I've searched through the Fortinet and can find no record of it recording something odd and rejecting the connection or blocking the IP.

I'm stumped as to whats triggering it unless the Orbi's are doing something particularly thick??

The fortinet ips engine wont leave a log - check the policy under SSL inspection are you using deep inspection ? (If you are, change to cert inspection instead and proxy-based)

Samsung

Shop now on Samsung phones, tablets, TVs and more (affiliate link).

mobiusnz

454 posts

Ultimate Geek

#3337698 31-Jan-2025 13:38

r0bbie:

The fortinet ips engine wont leave a log - check the policy under SSL inspection are you using deep inspection ? (If you are, change to cert inspection instead and proxy-based)

Cheers - The inbound 443 rule forwarding SSTP traffic has SSL inspection set to no-inspection as does the Internet traffic "rule" for traffic from internal to the outgoing interface. Anywhere else I might be missing? I am FAR from familiar with the Fortinet gear. When I look under security profiles, SSL/SSH inspection the no-inspection rule is the only one with References so that again points to SSL Inspection not being used?

If the fortinet is involved its blocking the IP address not the PC, session etc as if she connects to another VPN first and routers all traffic via that her SSL connection works which points to it being IP address based blocking.

I'm really scratching my head on this one. Really the only things outside my normal experience are the Fortinet appliance and the fact both users have Orbi's but I really can't see it being the Orbi??

Matt Beechey Mobius Network Solutions

r0bbie

242 posts

Master Geek

#3337703 31-Jan-2025 13:44

mobiusnz:

r0bbie:

The fortinet ips engine wont leave a log - check the policy under SSL inspection are you using deep inspection ? (If you are, change to cert inspection instead and proxy-based)

Cheers - The inbound 443 rule forwarding SSTP traffic has SSL inspection set to no-inspection as does the Internet traffic "rule" for traffic from internal to the outgoing interface. Anywhere else I might be missing? I am FAR from familiar with the Fortinet gear. When I look under security profiles, SSL/SSH inspection the no-inspection rule is the only one with References so that again points to SSL Inspection not being used?

If the fortinet is involved its blocking the IP address not the PC, session etc as if she connects to another VPN first and routers all traffic via that her SSL connection works which points to it being IP address based blocking.

I'm really scratching my head on this one. Really the only things outside my normal experience are the Fortinet appliance and the fact both users have Orbi's but I really can't see it being the Orbi??

If its set to no-inspection I dont think its that then

Is the SSTP traffic using quic? (but you would see that error in the application control log) thats the only thing I have seen that would make that error via a fortigate

r0bbie

242 posts

Master Geek

#3337705 31-Jan-2025 13:49

another thing to try on one user - disable PostQuantumKeyAgreement in chrome

In Google Chrome:

Disable ML-KEM support OR disable PostQuantumKeyAgreementEnabled.
Disabling ML-KEM is possible on a per-browser basis by going to chrome://flags and disabling Use ML-KEM in TLS 1.3 (#use-ml-kem).
Disabling PostQuantumKeyAgreementEnabled is possible via Chrome Enterprise Policy or Windows Group. Policy: PostQuantumKeyAgreementEnabled.
- Note: The PostQuantumKeyAgreementEnabled Enterprise Policy is specified by Google to be a temporary measure, so it will only be available 'through the end of 2024' (Update Google Play Services to fix issues with on-device passwords for more information).
- While this is not a long-term solution, this is a valid workaround for addressing website access issues for Chrome users today who are using Flow-based TLS Deep Inspection on the FortiGate.

mobiusnz

454 posts

Ultimate Geek

#3337706 31-Jan-2025 13:49

DjShadow:

Is there any issue with the SSL Cert itself? I do remember troubleshooting an issue with FortiClient last year where it was throwing an error with some websites and discovered if there was anything wrong with the cert (even just being expired) it would throw it’s toys

If I'm right QUIC requires UDP 443?? There is no UDP 443 forwarding so QUIC is not in use. I don't think Microsoft RRAS and SSTP support Quic.

Matt Beechey Mobius Network Solutions

1 | 2