Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Rob_G
New Contributor

Allow FortiClients to communicate to each other??

Looking to allow remote FortiClients to talk to each other. An example is, I'm remote on FortiClient and I need to RDP to another FortiClient via RDP.

 

I've created a rule to allow SSL_VPN_TUNNEL addresses and SSL_VPN_USERS to talk to SSL_VPN_TUNNEL addresses using the ssl.root.tunnel interface as the source and destination. Even moved this policy to be first in line. No Windows firewall or FC firewall enabled. Connection is showing as passed in the logs. Anyone have any thoughts on this?

 

Thanks in advance,

 

Rob

15 REPLIES 15
Toshi_Esumi
SuperUser
SuperUser

It worked for me and suggested the same to others for last a couple of days, and didn't hear back from them so assumed it worked for them too. Can you share exact policy in CLI?

Rob_G

Sure.... see below....

 

    edit 6         set name "SSL VPN traffic to SSL VPN traffic"         set uuid 32cd8256-694f-51ea-a654-xxxxxxxxxxxxxx         set srcintf "ssl.root"         set dstintf "ssl.root"         set srcaddr "goodwill-FC-VPN-x.x.x.x_21"         set dstaddr "goodwill-FC-VPN-x.x.x.x_21"         set action accept         set schedule "always"         set service "ALL"         set utm-status enable         set ssl-ssh-profile "certificate-inspection"         set webfilter-profile "monitor-all"         set logtraffic all         set groups "SSL VPN General Users" "SSL VPN CMS Users"         set comments "Used for Remote Support"     next

Toshi_Esumi

If it shows up int sniffing and flow debugging: coming in ssl.root and going out ssl.root, it must be the destination machine. So set up a two machines with SSL VPN up and run wireshark on the destination side while pining from the source to the destination.

Rob_G

OK... so here's a couple of tests sniffing packets from the ssl.root interface...

 

#1. PASS - I have a Cisco ASA in parallel with the FGT-400E that the FortliClients terminate on. I can see traffic flow from Cisco AC to FC-VPN.

 

#2. FAIL - I then connect a FC-VPN client to FC-VPN client that hits the accept rule and this happens.

 

Both are to the same destination machine of 172.20.0 6 that is successful from the Cisco AC but not successful from the FortiHairpining.

Rob_G

OK... so here's a couple of tests sniffing packets from the ssl.root interface...

 

#1. PASS - I have a Cisco ASA in parallel with the FGT-400E that the FortliClients terminate on. I can see traffic flow from Cisco AC to FC-VPN from the internal int to the ssl.root int of the SSL VPN clients.

 

 [link]https://photos.app.goo.gl/TETgsfecY8pVm8Wn8[/link]

 

#2. FAIL - I then connect a FC-VPN client to FC-VPN client that hits the accept rule and this happens.

 

[link]https://photos.app.goo.gl/xuaHHebmFJK8MpKj9[/link]

 

 Both sniffs are to the same destination machine of 172.20.0.6 that is successful from the Cisco AC but not successful from the FortiClient hairpining on the ssl.root interface.

 

Toshi_Esumi

Then run "flow debug" to see why it's dropped. I would use ping packets for a matter of simplicity. You should see if it's hitting the policy 6 or not as well.

Rob_G

Yeah... this was the damnedest thing and I'm still not sure if I understand it but it's working.

 

In order to resolve this I needed to modify my ssl tunnel address range used for the client pool. My range was from x.x.x.1 to x.x.x.100. When I modified it to x.x.x.10 to x.x.x.100, access started working. I'm thinking that this range overlapped with some psuedo-ip on the ssl.root interface. Once changed, everything started working.

 

Thanks for the suggestions. Cheers!

Toshi_Esumi

That's one of many reasons we almost never use "range" but "subnet" wherever we configure something under "config firewall address". Very easy to overlook overlaps beyond subnet boundaries.

Yanis_Sauve
New Contributor

Hello guys,

 

Fortigate 600D, FW 6.2.2 build 1010, Windows 10, using latest Forticlient, 6.2.2 0877, and have determined no FW is involved.

 

I have clients on SSL VPN that cannot communicate between each other, just like probably everyone else higher up this thread.

 

I've tried addind a policy from ssl.root to ssl.root, SSL VPN range to SSL VPN range, all services. Still no communication. All those clients can communicate with the remote networks fine. For example CIPCs (Cisco softphones) can place calls and receive them from people not connected to the SSL VPN. I've also reduced my Client IP range from .1-.254 to .4-.254, as .1-.3 seemed to be problematic for connectivity from the remote network.

 

When a call between Forticlients is attempted, signaling works, as in the phone rings, but when taken off-hook, the line opens, but no sound on the line.

 

I'm at a loss right now.  Anybody would have suggestions?

 

Thanks

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors