Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Jirka1
Contributor III

SSL VPN at Branch witch SD-WAN

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

9 REPLIES 9
Toshi_Esumi
Esteemed Contributor III

I would say it's not possible unless you split the tunnel at the branch.

Jirka1

toshiesumi wrote:

I would say it's not possible unless you split the tunnel at the branch.

 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? Jirka

Toshi_Esumi
Esteemed Contributor III

Split tunnel means Branch's Internet doesn't go to HQ. That's why it's impossible with the conditions given.

Jirka1

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

Toshi_Esumi
Esteemed Contributor III

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.

Jirka1

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

Toshi_Esumi
Esteemed Contributor III

You should limit the source for the inbound policy only to HQ subnets.

Toshi_Esumi
Esteemed Contributor III

Or much more specific. Not so much traffic is initiated from the server end.

sw2090
Honored Contributor

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

-- "It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Labels
Top Kudoed Authors