New Member

Question

Routing Problem with incomming SSL VPN connection to other VPN

Forum|Forum|3 years ago
June 5, 2023
14 replies
6016 views

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

FortiGate

Toshi_Esumi

SuperUser

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

Staff

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

RolandBaumgaertner72Author

New Member

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

SuperUser

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

RolandBaumgaertner72Author

New Member

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

RolandBaumgaertner72Author

New Member

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

RolandBaumgaertner72Author

New Member

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!

A

Anonymous_User

Contributor III

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

SuperUser

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

Sign up

Login with SSO

Login to the community

Login with SSO