IPv6 address pushed through FortiGate FG100/FG200 instead of assigned IPv4 address

[ptrader]

Hi All,

According to FortiGate support, I am the only person in the whole world who has had this problem.

Configuration: FortiClient 7.0.2/.3 on MAC (Monterey) -> FG100/200 (6.4.8) IPsec VPN -> Cloudflare -> Secure Website

IPv6 is not configured on the FortiGates.

Depending on the Internet provider (xFinity) and Verizon (hotspot), The user receives a block on Cloudflare because it see the xFintiy IPv6 address instead of the FG100/200 Internet IPv4 address.  Cloudflare only allows the FG100/200 IPv4 address access to the website.  If the user swaps to their hotspot, then the user can access the website.

It doesn't matter what user is used to sign into the IPSec VPN.

Fortinet support believe the issue is FortiClient, but since we don't have EMS, they won't provide support.

I believe the issue is on the FortiGate side as the IPv4 IP address assigned to the IPSec connection should be the address that is pushed through the FortiGate and seen by Cloudflare.  (Yes.  The Cloudflare error page shows the IPv6 IP of the user.  And No. Split tunneling is not active. If it was, the user would not be able to access the website as their local IP (xFinity and hotspot) are not allowed through Cloudflare.)

Any ideas you may have would be helpful.

[Anonymous]

Hello ptrader, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

Thanks, 

 Fortinet Community Team 

[Debbie_FTNT]

Hey ptrader,

correct me if I'm wrong:

- you have an IPsec VPN setup with FortiClient as dial-up client to FGT as VPN server

- you have NO split-tunneling set up

- your user establishes an IPSec VPN tunnel to the FortiGate

--> At this point, ALL traffic from the client should go through FortiGate?

- through that VPN tunnel, the user accesses Cloudflare/a secure website

- somehow, Cloudflare see's the user's ISP IP, not the anything NATed by the FortiGate/any IPs assigned via mode-config

-> if that ISP IP is IPv6, Cloudflare blocks them

To me it sounds as if for some reason the traffic to Cloudflare/website fails to traverse the tunnel and instead goes out the user's local ISP setup.

What does the client's routing table look like when the VPN is established?

Do you see traffic for the website hit the FortiGate (coming from the IPSec tunnel) when the issue occurs?

[ptrader]

Hi Debbie_FTNT,

Your assumption of the traffic not traversing the tunnel would be correct if both paths failed.  But the connection is made to the FortiGate.  You can see the IPv4 on the FortiClient connection page and see the connection in IPSec Tunnels/Status for the tunnel.

An additional piece of information.  The user tried to do a renew of the IP on their Mac.  The tunnel worked for the rest of the day, but the next morning, it failed again and they were back on their hotspot.

What I can't figure is why it would work for one connection and not the second one.  I have not had anyone running Windows (8.1, 10, 11) with this issue.  And I am on xFinity also.

[Debbie_FTNT]

Hey ptrader,

just because the VPN is up doesn't mean the traffic is traversing it, hence my question as to the routing on the client side, and verifying if FortiGate policies actually see the traffic to the webserver in question if the issue occurs.

But if you are certain the traffic is traversing the tunnel and  hitting the FortiGate, then the question is if FortiGate is handling the traffic correctly (matching correct policy, NAT, etc), and what the traffic looks like when leaving the FortiGate.

You can take a packet capture on the FortiGate outgoing interface (set the server in question as filter) to see if FortiGate is sending the traffic with correct source IPs or not.

Let me know if you have questions on how to determine the matching policy on FortiGate or how to take a packet capture :)

[ptrader]

Hi Debbie_FTNT,

A little more information.  Just spent some time with the user to do some testing.

The FortiGate shows the hotspot has an IPv4 address of 172.58.XX.XX for VPN tunnel 52.  Xauth shows it to be the user.

When they switch to the Xfinity WiFi, the FortiGate shows the WiFi as 69.136.XX.XX for the same tunnel.  To me that shows the tunnel is being put together with an IPv4 being handed to the FortiGate by the FortiClient.

Now to stir the soup.  If the user resets their Mac to 'link-local only' (disabling the broadcast of IPv6 externally), the Xfinity WiFi tunnel now works and did not get blocked by the Cloudflare security.

At this point, the only guess I have is the FortiClient is not securing the tunnel completely and allowing IPv6 traffic to leak out, or the FortiGate/FortiClient handshake is not establishing the disable split-tunnel when IPv6 is used to connect to the Internet and traffic not forward to the FortiGate is placed on the users default route and out their Internet connection.

The user is going to confirm if this change continues to work tomorrow to confirm if it is a viable workaround.

I will keep you posted.

[ptrader]

Hi Debbie_FTNT,

The user has been running with the macOS configuration of 'link-local only' for almost a week.  There has not been any issue with the FortiClient/FortiGate passing an incorrect IPv6.

At this point, this has been the only workaround that has worked.

If you have additional suggestions, I am all eyes.  Below is a copy of the block in case there are any questions.

[ptrader · Accepted solution]

To update everyone.  The only solution that has been proposed is to change the macOS to "link-local only" for the IPv6.  This works.

I have not heard any other recommendations.