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

Allow traffic from ssl-vpn to enter ipsec tunnel

Hello all,

 

I'll try to explain my scenario.

 

My office (192.168.7.0/24) has an ipsec to a remote location (10.133.3.0/24). My office subnet is natted to 172.31.19.0/24.

 

So IPSec (tunnel mode, not interface) is set between 172.31.19.0/24 to 10.133.3.0/24.

 

I'd like to use SSL to connect to my office (it's working), but i'd like to reach remote subnet (10.133.3.0/24).

 

How to do this?

 

Thank you in advance,

 

Kind Regards,

1 Solution
ede_pfau

Yes, sure. Interface-based and policy-based is only about the internal implementation on the FGT. Where policy-based was historically the first form, later replaced by the interface paradigm. External VPN partners will not notice anything about this.

 

Just remember: interface-based VPN needs 3 steps at different places in the config

1. VPN definition, as phase1 and phase2

2. a policy from source IF to tunnel IF with action=ACCEPT

3. a route to the remote subnet pointing to the tunnel IF

 

In a way, routing was determined by the destination address field in policy-based VPN. You'll see that the 'new' (now standard) approach is way more flexible, easier to configure and thus less error-prone.


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
15 REPLIES 15
evince

Thank you for your great help. What about if the remote firewall is not a Fortigate? Can i use Interface based VPN?

 

Kind Regards,

ede_pfau

Yes, sure. Interface-based and policy-based is only about the internal implementation on the FGT. Where policy-based was historically the first form, later replaced by the interface paradigm. External VPN partners will not notice anything about this.

 

Just remember: interface-based VPN needs 3 steps at different places in the config

1. VPN definition, as phase1 and phase2

2. a policy from source IF to tunnel IF with action=ACCEPT

3. a route to the remote subnet pointing to the tunnel IF

 

In a way, routing was determined by the destination address field in policy-based VPN. You'll see that the 'new' (now standard) approach is way more flexible, easier to configure and thus less error-prone.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
evince

Hello Ede,

 

Many thanks for your help i'll break it a build it again :)

 

Have a nice day,

 

Kind Regards,

Loris
New Contributor

Hello Ede.

 

I'm facing the same problem here and want to make sure. Is there any chance if we still use same Policy Based IPSec VPN, to connect SSL VPN to IP Sec VPN ?

 

Somehow, we were migrating Fortigate from existing Device used FortiOS 4.3 to new Device used FortiOS 5.6.

And their existing configuration for  IP Sec VPN used Policy Based combined with SSL VPN.

 

Did we need to change the IPSec Configuration to Interface Based?

 

Regards,

Loris

ede_pfau

Well, I'd say if you pester Support long enough they will find someone who still knows about the hidden virtues of policy based VPN, and how to make this work. For us mere mortals, please convert the existing VPN to interface based. You can then just follow my post from, what?, 3 years ago...

 

Besides, from a security point of view, creating an IPsec tunnel from scratch enables you to use 'modern' encryption / hashing algorithms, and decent, long, random PSKs. For the unexperienced, there's even a VPN wizard which will almost do it for you automatically.

 


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
AlbertFader
New Contributor

Wow I really fought with this one. Here are the steps that worked for me once the IPSEC was up and running and the SSL of course was working to connect to the machines on the network hosting the SSL VPN.

 

1) Create a subnet for SSL Range (make routable)
2) Add the subnet to the local group for the desired IPSEC tunnel (this should update everything)
3) Create a policy to all SSL_ROOT access to the IPSEC tunnel (No NAT) from above group to remote group of IPSEC - easiset to use a non-split tunnet
4) Optionally create policy from SSL root to WAN for internet access

On the remote side of the IPSEC

1) Create a subnet for Remote SSL Range above
2) Add this to the Remote IP group for the IPSEC

Labels
Top Kudoed Authors