Routing Problem with incomming SSL VPN connection to other VPN
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 22.214.171.124 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 126.96.36.199" interfaces=[any] filters=[host 10.226.32.4 and 188.8.131.52] 4.121268 184.108.40.206.7821 -> 10.226.32.4.3389: syn 4178171637 5.108913 220.127.116.11.7821 -> 10.226.32.4.3389: syn 4178171637 7.120296 18.104.22.168.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 22.214.171.124 and 10.226.32.4" interfaces=[any] filters=[host 126.96.36.199 and 10.226.32.4] 6.487260 188.8.131.52.16654 -> 10.226.32.4.3389: syn 2844567962 6.529417 10.226.32.4.3389 -> 184.108.40.206.16654: syn 1251862008 ack 2844567963 6.596936 220.127.116.11.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?
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 18.104.22.168 back to the VPN but doesn't have for 22.214.171.124. Is 126.96.36.199 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.
FG_Alcala_Master # diag snif packet any "host 188.8.131.52 and 10.226.32.4" 4 0 l interfaces=[any] filters=[host 184.108.40.206 and 10.226.32.4] 2023-06-05 18:04:03.856593 ssl.root in 220.127.116.11.55575 -> 10.226.32.4.3389: syn 3361542696 2023-06-05 18:04:04.858561 ssl.root in 18.104.22.168.55575 -> 10.226.32.4.3389: syn 3361542696 2023-06-05 18:04:06.858482 ssl.root in 22.214.171.124.55575 -> 10.226.32.4.3389: syn 3361542696 2023-06-05 18:04:10.868343 ssl.root in 126.96.36.199.55575 -> 10.226.32.4.3389: syn 3361542696 2023-06-05 18:04:18.874047 ssl.root in 188.8.131.52.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.
So 184.108.40.206 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.
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
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?
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.
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?
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.