Hello,
I am now solving the following configuration and I would like to ask you for advice:
I have two internet connections at the branch: wan1 and wan2. An IPsec tunnels to the HQ is built on each line and both tunnels are members of SD-WAN. So all the traffic goes through the headquarters and it works ok.
Now the customer requires to be able to connect to the branch office directly via SSL VPN and have access to a network other than the production LAN. However, this is not possible because the DR points to the SD-WAN. Of course, the solution is to set up a static route directly to WAN1 / WAN2, but since the client must connect from anywhere (that's what the meaning of VPN is), this solution is not possible.
How to solve this? Connection via HQ is not possible for many reasons (network overlap, security reasons, etc.) Thank you. Jirka
I would say it's not possible unless you split the tunnel at the branch.
toshiesumi wrote:Thanks Toshi, but.."split a tunnel at a branch"..you mean modify P2 so that the source address was the branch range (e.g. 172.17.5.0/24) and not 0.0.0.0/0? JirkaI would say it's not possible unless you split the tunnel at the branch.
Split tunnel means Branch's Internet doesn't go to HQ. That's why it's impossible with the conditions given.
I understand, so that's unacceptable.
I have now tried to add WAN1 to the SD-WAN and the SSL VPN works (of course I had to adjust the SD-WAN rules). However, due to the fact that I have the Policy "SD-WAN-> LAN - Accept all" I am worried that this may a security risk when WAN1 is a member of SD-WAN.
Jirka
SSL VPN's interface is "ssl.root", not wan1. So you should have a policy ssl.root->LAN. It might work if wan1 is using the same SD-WAN default route with those HQ tunnels.
I meant Policy from IPsec tunnels (SD-WAN members) to LAN - everything is allowed there, because there is an AD controller etc. on HQ. And as I wrote - part of SD-WAN is also wan1. So I wonder if this is a security issue (but I guess so)
Configuration:
config system interface
edit "wan1"
set vdom "root"
set ip xxx.xx.xxx.xxx 255.255.255.248
set allowaccess ping https ssh snmp
set type physical
set alias "Primary"
set lldp-reception disable
set lldp-transmission disable
set monitor-bandwidth enable
set role wan
set snmp-index 1
set preserve-session-route enable
next
edit "wan2"
set vdom "root"
set ip xxx.xxx.xxx.xxx 255.255.255.252
set allowaccess ping https ssh
set type physical
set outbandwidth 8000
set alias "Secondary"
set lldp-reception disable
set lldp-transmission disable
set monitor-bandwidth enable
set role wan
set snmp-index 2
next
edit "HQ-primary"
set vdom "root"
set ip 10.1.5.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.1.5.1 255.255.255.252
set snmp-index 17
set interface "wan1"
next
edit "HQ-secondary"
set vdom "root"
set ip 10.2.5.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 10.2.5.1 255.255.255.255
set monitor-bandwidth enable
set snmp-index 16
set interface "wan2"
next
end
config router static
edit 1
set dst HQ-VPN-Primary
set gateway xxx.xxx.xxx.xxx
set device "wan1"
next
edit 6
set dst HQ-VPN-Secondary
set gateway xxx.xxx.xxx.xxx
set device "wan2"
next
edit 8
set gateway xxx.xxx.xxx.xxx
set device "wan1"
set dstaddr "MNGMT_from_WAN"
next
edit 9
set gateway xxx.xxx.xxx.xxx
set device "wan2"
set dstaddr "MNGMT_from_WAN"
next
edit 10
set distance 1
set sdwan enable
next
end
config firewall policy
edit 20
set srcintf "LAN"
set dstintf "virtual-wan-link"
set srcaddr "Branch-lan"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
edit 21
set srcintf "virtual-wan-link"
set dstintf "LAN"
set srcaddr "all"
set dstaddr "Branch-LAN"
set action accept
set schedule "always"
set service "ALL"
set logtraffic all
next
end
config system sdwan
set status enable
config zone
edit "virtual-wan-link"
next
end
config members
edit 2
set interface "HQ-primary"
set gateway 10.1.5.1
next
edit 3
set interface "HQ-Secondary"
set gateway 10.2.5.1
next
edit 4
set interface "wan1"
set gateway xxx.xxx.xxx.xxx
next
end
You should limit the source for the inbound policy only to HQ subnets.
Or much more specific. Not so much traffic is initiated from the server end.
hm I have this constelation here:
we have branches that are connected to HQ via redundant IPSEC VPN. So HQ can access branch Networks the way we need it and vice versa.
I can put up a dial up ipsec to HQ and access HQ Networks via it (and if I created the policies alo the branch networks). This is using split tunneling as I don't want my internet traffic to go through HQ of coourse :)
So I use split tunneling to just push the routes to HQ Subnets that I need.
If I would like to acces branch networks the FGT at branch would need a route back to the HQ Vpn subnet of course.
Also there is a dial up IPSec at each branch that I can use to directly connect to the branch and access the branch subnets.
is it that what you need (just with SSL instead of IPSec)?
The olny caveat is that I have to use an alternate IPSec client because I want to be able to connect to both parallel and this is not supported by FortiClient.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
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 |
---|---|
1737 | |
1107 | |
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.