Description
This article describes how to enable routing between SSLVPN clients. This would be required for Peer-to-Peer communication like Microsoft Skype Phone Calls.
Solution
1) Create a SSLVPN Address Range
4) Create a Firewall policy from SSL to SSL without NAT, which contains the Subnet as destination
Result:
Client A has Tunnel IP 10.212.134.1
Client B has Tunnel IP 10.212.134.2
Ping from Client A to Client B works fine:
ping 10.212.134.2
PING 10.212.134.2 (10.212.134.2) 56(84) bytes of data.
64 bytes from 10.212.134.2: icmp_seq=1 ttl=127 time=25.1 ms
64 bytes from 10.212.134.2: icmp_seq=2 ttl=127 time=25.2 ms
64 bytes from 10.212.134.2: icmp_seq=3 ttl=127 time=25.9 ms
64 bytes from 10.212.134.2: icmp_seq=4 ttl=127 time=24.3 ms
Also the clients have received the correct routes:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.212.134.0 host-ftnt 255.255.255.0 UG 0 0 0 ppp0
192.168.249.0 host-ftnt 255.255.255.0 UG 0 0 0 ppp0
192.168.250.0 host-ftnt 255.255.255.0 UG 0 0 0 ppp0
This article describes how to enable routing between SSLVPN clients. This would be required for Peer-to-Peer communication like Microsoft Skype Phone Calls.
Solution
1) Create a SSLVPN Address Range
#config firewall address2) Create a routeable 'Dummy' Subnet, which matches the SSLVPN Range
#edit "SSLVPN_TUNNEL_ADDR1"
#set type iprange
#set associated-interface "ssl.root"
#set start-ip 10.212.134.1
#set end-ip 10.212.134.254
#next
#end
#config firewall addressOptional: Enable Split-Tunneling on the SSLVPN Portal if required
#edit "SSLVPN-Subnet"
#set subnet 10.212.134.0 255.255.255.0
#next
#end
#config vpn ssl web portalNote: If the 'split-tunneling-routing-address' is not specified, FortiGate will create the routes based on the authorized SSLVPN Policies.
#edit "full-access"
#set tunnel-mode enable
#set split-tunneling enable <<<<<
#set ip-pools "SSLVPN_TUNNEL_ADDR1"
#set dns-server1 1.2.3.4
#set dns-suffix domain.local
#next
#end
4) Create a Firewall policy from SSL to SSL without NAT, which contains the Subnet as destination
#config firewall policy
#edit 1
#set srcintf "ssl.root"
#set dstintf "ssl.root"
#set srcaddr "SSLVPN_TUNNEL_ADDR1" <<<< Tunnel IP Range
#set dstaddr "SSLVPN-Subnet" <<<< Created Subnet Object
#set action accept
#set schedule "always"
#set service "ALL"
#set groups "Backup" <<<< Usergroup which is authorized to use this policy
#set nat disabled <<<< No NAT required
#next
#end
Result:
Client A has Tunnel IP 10.212.134.1
Client B has Tunnel IP 10.212.134.2
Ping from Client A to Client B works fine:
ping 10.212.134.2
PING 10.212.134.2 (10.212.134.2) 56(84) bytes of data.
64 bytes from 10.212.134.2: icmp_seq=1 ttl=127 time=25.1 ms
64 bytes from 10.212.134.2: icmp_seq=2 ttl=127 time=25.2 ms
64 bytes from 10.212.134.2: icmp_seq=3 ttl=127 time=25.9 ms
64 bytes from 10.212.134.2: icmp_seq=4 ttl=127 time=24.3 ms
Also the clients have received the correct routes:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.212.134.0 host-ftnt 255.255.255.0 UG 0 0 0 ppp0
192.168.249.0 host-ftnt 255.255.255.0 UG 0 0 0 ppp0
192.168.250.0 host-ftnt 255.255.255.0 UG 0 0 0 ppp0
Labels: