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]

If syn is going out to Azure VPN, routing on the FGT side is working. However, it might be a routing issue on Azure side, like it has a route for 48.48.48.9 back to the VPN but doesn't have for 54.1.1.14.
Is 54.1.1.14 the IP you configured for SSLVPN_TUNNEL_ADDR1 ip range? I know you might have changed for posting but it's unusual to change any private range IP to one of public ones.

Toshi

[martinsd]

Hey,

@RolandBaumgaertner72, can you please add "4 0 l" to the packet capture commands, and provide the output? Can you please provide the output of the relevant "diag flow" command (https://docs.fortinet.com/document/fortigate/6.2.14/cookbook/54688/debugging-the-packet-flow)?

BR,

Diogo Martins

[RolandBaumgaertner72]

Hi:

first of all thanks for your replies.

Changing the diag thats the result:

FG_Alcala_Master # diag snif packet any "host 54.1.1.14 and 10.226.32.4" 4 0 l
interfaces=[any]
filters=[host 54.1.1.14 and 10.226.32.4]
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
2023-06-05 18:04:10.868343 ssl.root in 54.1.1.14.55575 -> 10.226.32.4.3389: syn 3361542696
2023-06-05 18:04:18.874047 ssl.root in 54.1.1.14.55575 -> 10.226.32.4.3389: syn

I dont know, the network of the SSL VPN range was not configured by me. I dont think that the Azure side has something to do (we cant control this site) since we did the testing with the other SSL VPN network and it worked fine.

The other test was like connecting the SSL to the LAN of FG1 and than Outgoing Interface in the Policy was the MPLS internal network. So it got to the central FW and the routing matched.

Here on the central FW I dont understand. I try to route from SSL interface directly to the VPN Azure Interface and I dont get the replies.

OK? What can we do?

Thanks

[Toshi_Esumi]

So 54.1.1.14 is the real IP configured in SSLVPN_TUNNEL_ADDR1 then. If you run "show firewall address SSLVPN_TUNNEL_ADDR1", you can see it even if you didn't configure SSL VPN yourself.
But the first problem is the RDP(TCP 3389) SYN packets are coming in from ssl.root but not going out to the Azure VPN interface. You probably need to do the flow debugging @martinsd is asking to see why it doesn't go out. Maybe ssl.root->AzureVPN policy has a problem or doesn't exist. The flow debug would show you why.

I didn't realize your sniffing for the working access was done at one of remote FGTs. Not on the central FW the Azure VPN is terminated at. What do you see if you do the same sniff with '4 0 l' option at the central FW? You should see both incoming from the FG-xxx2 and outgoing to the Azure VPN, as well as returning packets.

Toshi

[RolandBaumgaertner72]

We need the SSL VPN on the central FW with the direct VPN to Azure to avoid problems (as a backup solution we could configure a SSL from another FG).

The sniffing is done on the central, I change the SSL VPN range to the standard one:

 
FG_XXX # diag snif packet any "host 10.212.134.200 and 10.226.32.4" 4 0 l
interfaces=[any]
filters=[host 10.212.134.200 and 10.226.32.4]
2023-06-05 21:58:17.997484 ssl.root in 10.212.134.200.50556 -> 10.226.32.4.3389: syn 6683078
2023-06-05 21:58:19.001378 ssl.root in 10.212.134.200.50556 -> 10.226.32.4.3389: syn 6683078
2023-06-05 21:58:21.010432 ssl.root in 10.212.134.200.50556 -> 10.226.32.4.3389: syn 6683078
2023-06-05 21:58:25.011288 ssl.root in 10.212.134.200.50556 -> 10.226.32.4.3389: syn 6683078
2023-06-05 21:58:33.018999 ssl.root in 10.212.134.200.50556 -> 10.226.32.4.3389: syn 6683078

I dont see the traffic in the policy we created this morning

 

Thanks

[RolandBaumgaertner72]

pinging the host from the SSL connection (ping is not allowed, only RDP) I see the sessions in the right policy

 

[Toshi_Esumi]

I meant to sniff the same for the working one sourced from another FGT location.

But if you NAT it it would use the interface IP of the Azure VPN as the source IP. That's why the outgoing packets don't show up with your sniff filter "host 10.212.134.200 and 10.226.32.4". Do you have an IP configured on the phase1-interface interface?

Toshi

[Toshi_Esumi]

In other words, there should be policies to allow other sources accessing to "Azure" including the remote location's VPN. Check those if those are NATed as well. If so, likely Azure side has route only back to that Azure VPN interface IP on this FGT. If not, Azure side must have routes configured only to those specific sources.
Once you confirmed those SYNs from SSL VPN clients go into the Azure VPN with flow debugging, you need to figure out routing on the Azure side. Most unlikely the default route is coming back through the tunnel so you have to figure it out including if you should have NAT for ssl.root->Azure or not.

Toshi

[RolandBaumgaertner72]

Hi,

thanks for your feedback.

Unfortunately I dont get so easy information from the other VPN side, it can takes weeks just to get in contact with them. 

I dont think I have something wrong on our side and that it is someting in the Azure VPN that just allows the X.X.X.X/16 we establish in the P2 of the VPN configuration. 

When I connect via SSL to the other FG, the conection passes the MPLS network to the central firewall and from there via VPN to Azure without a problem and I think this has to be our work around to have a SSL conection to this host.

Maybe a solution could be that the SSL VPN range is the same as my LAN IP range?

Thanks