Hot!Allow FortiClients to communicate to each other??

Author
Rob_G
New Member
  • Total Posts : 5
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/01/13 12:00:01
  • Location: Milwaukee, WI.
  • Status: offline
2020/03/18 13:53:30 (permalink)
0

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
#1
Toshi Esumi
Expert Member
  • Total Posts : 2093
  • Scores: 194
  • Reward points: 0
  • Joined: 2014/11/06 09:56:42
  • Status: online
Re: Allow FortiClients to communicate to each other?? 2020/03/18 14:32:21 (permalink)
0
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?
#2
Rob_G
New Member
  • Total Posts : 5
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/01/13 12:00:01
  • Location: Milwaukee, WI.
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/18 14:35:12 (permalink)
0
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
#3
Toshi Esumi
Expert Member
  • Total Posts : 2093
  • Scores: 194
  • Reward points: 0
  • Joined: 2014/11/06 09:56:42
  • Status: online
Re: Allow FortiClients to communicate to each other?? 2020/03/18 14:46:52 (permalink)
0
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.
#4
Rob_G
New Member
  • Total Posts : 5
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/01/13 12:00:01
  • Location: Milwaukee, WI.
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/18 15:14:40 (permalink)
0
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.
 
 https://photos.app.goo.gl/TETgsfecY8pVm8Wn8
 
#2. FAIL - I then connect a FC-VPN client to FC-VPN client that hits the accept rule and this happens.
 
https://photos.app.goo.gl/xuaHHebmFJK8MpKj9
 
 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.
 
#5
Toshi Esumi
Expert Member
  • Total Posts : 2093
  • Scores: 194
  • Reward points: 0
  • Joined: 2014/11/06 09:56:42
  • Status: online
Re: Allow FortiClients to communicate to each other?? 2020/03/18 15:20:04 (permalink)
0
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.
#6
Rob_G
New Member
  • Total Posts : 5
  • Scores: 0
  • Reward points: 0
  • Joined: 2016/01/13 12:00:01
  • Location: Milwaukee, WI.
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/19 15:09:06 (permalink)
0
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!
#7
Toshi Esumi
Expert Member
  • Total Posts : 2093
  • Scores: 194
  • Reward points: 0
  • Joined: 2014/11/06 09:56:42
  • Status: online
Re: Allow FortiClients to communicate to each other?? 2020/03/19 15:16:33 (permalink)
0
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.
#8
Yanis_Sauve
New Member
  • Total Posts : 7
  • Scores: 0
  • Reward points: 0
  • Joined: 2015/02/23 08:34:21
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/24 11:52:43 (permalink)
0
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
post edited by Yanis_Sauve - 2020/03/24 11:56:11
#9
seadave
Expert Member
  • Total Posts : 346
  • Scores: 50
  • Reward points: 0
  • Joined: 2004/11/03 18:02:09
  • Location: Seattle, WA
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/24 15:31:18 (permalink)
0
Our rule looks as attached.  Seems to work for our Shoretel/Mitel softphones.

config firewall policy
    edit 207
        set name "SSLVPN - Mitel"
        set srcintf "ssl.root"
        set dstintf "ssl.root"
        set srcaddr "SSLVPN_TUNNEL_ADDR1"
        set dstaddr "SSLVPN_TUNNEL_ADDR1"
        set action accept
        set schedule "always"
        set service "ALL_ICMP" "ALL_TCP" "ALL_UDP"
        set logtraffic all
        set groups "SSL_VPN_FULL"
    next
end
 
This rule obviously could be restricted but what we have now to make this work for folks.

Attached Image(s)

#10
Yanis_Sauve
New Member
  • Total Posts : 7
  • Scores: 0
  • Reward points: 0
  • Joined: 2015/02/23 08:34:21
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/24 15:41:24 (permalink)
0
My rule is exactly the same:
edit 88
set name "VPN->VPN"
set uuid 883799fa-6dd9-51ea-53d2-a9f70a93b2f1
set srcintf "ssl.VDOM-CSDLJ"
set dstintf "ssl.VDOM-CSDLJ"
set srcaddr "VPN-Clients-172.17.6"
set dstaddr "VPN-Clients-172.17.6"
set action accept
set schedule "always"
set service "ALL"
set groups "AAA-GRP-VPN"
next
 
VPN-Clients-172.17.6 is defined as range 172.17.6.4-254
 
But poilcy 88 is never hit by anything.  And I just can't get anything from flow trace.
 
#11
seadave
Expert Member
  • Total Posts : 346
  • Scores: 50
  • Reward points: 0
  • Joined: 2004/11/03 18:02:09
  • Location: Seattle, WA
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/24 15:53:08 (permalink)
0
Only think different I see is you are using a specific vdom but that shouldn't matter.  You might open a ticket with the TAC.  They are good at getting into diag debug flow and figuring these things out.  One other thing is that we are showing ALL_ICMP, ALL_UDP, etc.  Those might differ from the ALL you are using.

Attached Image(s)

#12
Yanis_Sauve
New Member
  • Total Posts : 7
  • Scores: 0
  • Reward points: 0
  • Joined: 2015/02/23 08:34:21
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/03/25 06:03:36 (permalink)
0
Well, some news.
 
I changed my clients ip range from 4-254 to 10-254 and this seems to have fixed it.
 
Everything works correctly now, and my policy is being hit.
 
Thanks for the help guys.
#13
kulas
Bronze Member
  • Total Posts : 39
  • Scores: 2
  • Reward points: 0
  • Joined: 2017/09/28 19:28:08
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/05/03 23:32:54 (permalink)
0
I have the same concern.. I tried to use SUBNET instead of IP RANGE for my clients. I do also have firewall policy in placed ssl.root-to-ssl.root but no traffic hit. I do also debug flow and packet sniffer but no avail.
 
Regards,
Kulas
#14
Nik
New Member
  • Total Posts : 1
  • Scores: 0
  • Reward points: 0
  • Joined: 2020/05/04 23:50:15
  • Status: offline
Re: Allow FortiClients to communicate to each other?? 2020/05/20 06:12:39 (permalink)
0
I do have this problem also. I have configured the policy correctly but still there is no access to each other. One thing what I did observe was that for every vlan created on the fortigate there is a connected route under the Routing monitor. But interesting the route to the sslvpn is not present. When I do a route lookup for example, destination 10.10.1.4 (sslvpn IP address) from the LAN gateway 172.16.16.1, the hit I got was via the default route 0.0.0.0/0 via internet gateway! BUT this leads to nowhere since there is no public IP address for the destination and it will just end on the cyberspace somewhere. 
 
So what do you guys think if I create a static route from LAN to the sslvpn subnet, will then this help!
 
Has anyone succeeded with this and how?  
#15
Jump to:
© 2020 APG vNext Commercial Version 5.5