Hi there.
I know that the SSLVPN daemon is listening to the IP addresses of the interface I select. Now, as I do have many secondary IP addresses on this interface, I would like to restrict the SSLVPN daemon only to listen to the ones I want to.
Do you know how to achieve this? I’m running FOS 7.0.12 and in the CLI I didn’t find anything that could help.
TIA
I believe the common way people implement this is to have the sslvpn listen on an internal loopback interface and then setup a VIP to map the traffic to that looback interface.
Ultraviolet Networks - Use case explorer - Terminating SSLVPN to a loopback interface
You assign the Ip to a separate interface instead of the interface it’s on now. Why the multiple secondary IPs? Shouldn’t be necessary to have those on FortiGate. VIPs and IP Pools should mean you don’t require the ip address actually bound to the NIC as a secondary. Only place I’ve ever used secondary IPs is in Azure/AWS, specifically because I wanted to use the secondary Ip for vpn tunnels…
you could use local-in policy to allow the sslvpn port only on the IPs you want to and deny for the others
I don’t think this is “the common way”, but it’s a good idea indeed!
Thanks!
Well, no. If I assign the IP to a separate interface (which wouldn’t be my external interface, where SSLVPN daemon is listening on), then I would loose the functionality on that specific IP address.
The multiple secondary IP addresses are needed, because on each of those there is a different FQDN registered, which is used by different clients to perform IPSec VPN tunnel connection. The secondary IP addresses are part of a PIA range (provider-independent address), so none of them is configured as the primary IP address because there we use the public /30 subnet provided by the actual ISP.
VIPs and IP pools won’t help in my situation: the former require you to map an internal IP address (not the one on the Fortigate itself), the latter is used for outgoing NAT purposes mainly.
That’s correct - didn’t think about it. Thanks.
Can confirm that’s how I’ve done it multiple times. Let’s you get really granular with traffic control
What kind of granularity are you referring to? Some examples?
(I think I might try this configuration out sometime)
Using standard firewall policies to control what can access the VPN interface as opposed to local-in. The thing I like the most is the geographic filtering but you can also add security profiles or even external lists to filter known malicious IPs
One of the benefits of doing it this way is it lets you control access the the VIP using normal security policy instead of local-in-policy.
That’s a plus, yes. No CLI (local-in-policies). But what more would it give me in terms of granularity for an SSLVPN access?