When configuring an SSLVPN in tunnel mode why do we have to specify source IP information in the VPN > SSL > SETTINGS screen under Tunnel Mode Client Settings as well as in VPN > SSL > PORTALS in the Source IP Pools field when checking Enable Tunnel Mode?
If I don't get an answer I will lab it up and find out but I'm hoping to save some time. I suspect it has to do with Authentication/Portal Mapping but I would like some confirmation on that.
Does the settings config assign the IP ranges that WILL be used when a tunnel mode client connects and the Portal setting is used separately to define configuration sent to the Forticlient for remote policy definition?
Are they purely redundant configuration fields?
Does one setting just give you more granular control over assigned IPs to specific users/groups? ie Does the IP pool in the portal config trump the IP Ranges value in the settings config? (This would seem silly to me since you have to define a portal even if it is just to the All Other Users/Groups portal mapping field.)
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
I don't know if they are redundant, but I believe you need the settings if you wanted to achieve a different src pool for tunnel-mode and portal clients. And yes, so what ever is under the main cfg is trumped by the port definitions.
e.g my webportal
config vpn ssl web portal edit "socgroup012" set tunnel-mode enable set ipv6-tunnel-mode enable set web-mode enable set ip-pools "SSLVPN_012GROUP" set split-tunneling disable set ipv6-pools "SSLVPN_IPv6_012GROUP" next end
and here's my main cfg;
config vpn ssl settings set sslv3 disable set servercert "Fortinet_Factory" set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1" set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1" set port 8767 set source-interface "wifi" set source-address "all" set source-address6 "all" set default-portal "default" config authentication-rule edit 1 set groups "SSL1" set portal "socgroup012" next end end
So I believe if you look at it; " yes it redundant".
What I do know, if you remove the main tunnel mode cfg src pool address, the user will still work and be assigned a client address via the defined pool src_ip_pool for the specific portal.
PCNSE
NSE
StrongSwan
I don't know if they are redundant, but I believe you need the settings if you wanted to achieve a different src pool for tunnel-mode and portal clients. And yes, so what ever is under the main cfg is trumped by the port definitions.
e.g my webportal
config vpn ssl web portal edit "socgroup012" set tunnel-mode enable set ipv6-tunnel-mode enable set web-mode enable set ip-pools "SSLVPN_012GROUP" set split-tunneling disable set ipv6-pools "SSLVPN_IPv6_012GROUP" next end
and here's my main cfg;
config vpn ssl settings set sslv3 disable set servercert "Fortinet_Factory" set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1" set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1" set port 8767 set source-interface "wifi" set source-address "all" set source-address6 "all" set default-portal "default" config authentication-rule edit 1 set groups "SSL1" set portal "socgroup012" next end end
So I believe if you look at it; " yes it redundant".
What I do know, if you remove the main tunnel mode cfg src pool address, the user will still work and be assigned a client address via the defined pool src_ip_pool for the specific portal.
PCNSE
NSE
StrongSwan
That is excellent information! Enough for me to move forward with my documentation. The audience for the docs I'm writing wouldn't understand a more detailed explanation anyway. :)
Of course my curiosity is peaked so if I can find a few minutes in the day I think I will lab up a couple of scenarios. I would really like an answer from the developer's as to what the thought was here or was it a missed holdover from old code. Perhaps a query to my SE is in order.
Thank you!!
I know this is kind of an old thread, but I was wondering the same thing.
My lab test confirms that the ip pool in the portal settings has precedence over the global vpn ssl Settings, when using tunnel mode. But if I use the web portal to access the internal network, it will use the web portal external ip address as the source IP.
So still not clear to me, when actually the ip pool is used in the global vpn settings.
But what makes me really wonder, why is there no route visible to the ssl.root interface? Shouldn't there be a connected entry in the routing table? get router info routing-table detail doesn't show me the expected entry.
Got it:
FG01 (root) # get router info kernel
tab=254 vf=0 scope=0 type=1 proto=14 prio=10 0.0.0.0/0.0.0.0/0->10.23.23.210/32 pref=0.0.0.0 gwy=0.0.0.0 dev=16(ssl.root)
tab=254 vf=0 scope=0 type=1 proto=14 prio=10 0.0.0.0/0.0.0.0/0->10.23.23.208/31 pref=0.0.0.0 gwy=0.0.0.0 dev=16(ssl.root)
...
Only the route to the portal VPN pool is visible, there is no route for the global vpn setting.
Did you install route ( static ) for the vpn pool with the gateway as ssl.root ?
e.g
show router static
PCNSE
NSE
StrongSwan
No I didn't:
FG01 (root) # show router static
config router static
edit 2
set gateway 192.168.1.1
set distance 255
set device "port2"
next
edit 3
set dst 10.1.4.0 255.255.255.0
set device "Tunnel4"
next
end
FG01 (root) # get router info routing-table all
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default
S* 0.0.0.0/0 [5/0] via 192.168.1.1, port2
C 1.1.1.1/32 is directly connected, Loopback1
S 10.1.1.0/24 [15/0] is directly connected, Hub Tunnel_1
S 10.1.4.0/24 [10/0] is directly connected, Tunnel4
C 172.16.50.0/30 is directly connected, FG1_1-root0
C 172.16.50.1/32 is directly connected, FG1_1-root0
C 172.16.50.4/30 is directly connected, FG1_2-root0
C 172.16.50.5/32 is directly connected, FG1_2-root0
C 172.16.50.8/30 is directly connected, FG1_3-root0
C 172.16.50.9/32 is directly connected, FG1_3-root0
C 172.16.50.12/30 is directly connected, FG1_4-root0
C 172.16.50.13/32 is directly connected, FG1_4-root0
C 192.168.1.0/24 is directly connected, port2
you need something like the following;
config router static edit 20 set dst 10.10.14.0 255.255.255.0 set device "ssl.root" next
10.10.14.0 would be your sslvpn pool address netwrk
PCNSE
NSE
StrongSwan
The original question was, why are there two different IP Pools configurable in the SSLVPN settings: One in the global vpn settings and the other one in the sslvpn portal settings. When is this global sslpvn ip-pool actually used?
Meanwhile I found out that in the GUI the ip pool setting is a required field for the portal settings. So it will never user the value configured in the global vpn ssl setting.
In the CLI (#config vpn ssl web portal) the ip-pool setting is optional. And if it is not set, then it will use the global vpn ssl setting (by default: SSLVPN_TUNNEL_ADDR1).
GUI:
CLI: (set ip-pools is not mandatory)
config vpn ssl web portal
edit "full-access"
set tunnel-mode enable
set web-mode enable
set save-password enable
set split-tunneling disable
set heading "Full-Access"
set page-layout double-column
set theme crimson
next
end
My 2nd question was, why I couldn't see a route to this ip-pool and sslvpn interface, even when a sslvpn client is connected. The answer:
It will create the appropriate routes automatically, but the routes are only visible in the Forward Information DB (#get router info kernel).
The original question was, why are there two different IP Pools configurable in the SSLVPN settings: One in the global vpn settings and the other one in the sslvpn portal settings. When is this global sslpvn ip-pool actually used?
The ip pool cfg in the specific pool ovveride any global that should answer the 1st part.
My 2nd question was, why I couldn't see a route to this ip-pool and sslvpn interface, even when a sslvpn client is connected. The answer:
Than you need a route in the route table for the pool regardless, without this the packets will drop from uRPF
PCNSE
NSE
StrongSwan
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1733 | |
1106 | |
752 | |
447 | |
240 |
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.
Copyright 2024 Fortinet, Inc. All Rights Reserved.