Routing Problem with incomming SSL VPN connection to other VPN

[RolandBaumgaertner72]

Hi,

we have a FG with a VPN to Azure. We would like to connect via SSL VPN to port 1 and than through our main VPN to Azure to one server.

We think the SSL configuration is OK, we get 54.1.1.14 with SSL VPN and want to go to 10.226.32.4, the debug gets us:
FG_XXX # diag sniffer packet any "host 10.226.32.4 and 54.1.1.14"
interfaces=[any]
filters=[host 10.226.32.4 and 54.1.1.14]
4.121268 54.1.1.14.7821 -> 10.226.32.4.3389: syn 4178171637
5.108913 54.1.1.14.7821 -> 10.226.32.4.3389: syn 4178171637
7.120296 54.1.1.14.7821 -> 10.226.32.4.3389: syn 4178171637

It cant be a problem of the host. We habe a MPLS Network and doing the same from another FG which has NOT the VPN configured to Azure we get:

FG_XXX2 # diag sniffer packet any "host 48.48.48.9 and 10.226.32.4"
interfaces=[any]
filters=[host 48.48.48.9 and 10.226.32.4]
6.487260 48.48.48.9.16654 -> 10.226.32.4.3389: syn 2844567962
6.529417 10.226.32.4.3389 -> 48.48.48.9.16654: syn 1251862008 ack 2844567963
6.596936 48.48.48.9.16654 -> 10.226.32.4.3389: ack 1251862009

Is this a routing issue? How can we solve it and get via SSL VPN from our main FW to the Azure?

Thanks

[Toshi_Esumi]

Again, take a look at the policy allowing the Azure access for the users over MPLS, MPLS->Azure. Is it NATed? And check IP on "Azure" VPN interface. To NAT that policy, the IP on Azure int have to be within the /16. If not, you need to remove the NAT and allocate IP range for SSL VPN within the /16.
I guess I'm just repeating what @martinsd is asking.

Toshi

[martinsd]

@RolandBaumgaertner72, I will need your routing table (get router info routing-table all), I will need to check your IPSec Phase 2 selectors, and your IPSec interface config. You can send by PM if you do not want to expose your config.

[RolandBaumgaertner72]

Hi,

I found a work around. I dont know if I like it but it works. When I use for the SSL VPN the range 128.1.98.50-128.1.98.55 (which are in our LAN network of the central FW) I get the answers from the Azure and the RDP works. I had to desactivate NAT in the policy. So the other Azure side gets packages from 128.1.0.0/16 and it works.

Is there any inconvenient to use as SSL VPN an IP range from LAN? Of course this user cant connect to LAN but this is no need.

Thanks!

[Muhammad_Haiqal]

Hi @RolandBaumgaertner72 ,

Looking at this behavior, 128.1.0.0/16 is part of phase2 negotiation. When NAT enabled, the traffic will use outgoing interface(example: 10.10.10.254) . If this 10.10.10.254 is not part of phase2, the traffic will not send to the tunnel.

2023-06-05 18:04:03.856593 ssl.root in 54.1.1.14.55575 -> 10.226.32.4.3389: syn 3361542696
2023-06-05 18:04:04.858561 ssl.root in 54.1.1.14.55575 -> 10.226.32.4.3389: syn 3361542696
2023-06-05 18:04:06.858482 ssl.root in 54.1.1.14.55575 -> 10.226.32.4.3389: syn 3361542696

For the output above, Fortigate received the traffic but not send out to the tunnel. Most probably due to that phase2 negotiation.

[Toshi_Esumi]

Not a work around but that's what you needed to do if 128.1.0.0/16 is configured as a part of network selector in Phase2. No other IPs would work.

If you cut out a chunk of IPs from a LAN subnet and use it for SSL VPN Client IP range, that's probably ok as long as all traffic over the SSL VPN is initiated by the clients. But you need to be careful to keep it outside of LAN DHCP range and other features that might conflict with the arrangement. Otherwise it would become a trip hazard for future admins. So generally not recommended unless you split the LAN subnet like a /24 -> 2 x /25s then assign them to the LAN and SSL VPN separately.

Toshi