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
ede_pfau
SuperUser
SuperUser

1- routing

2- policy

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

Hello ede_pfau, and thank you for your support. Can you explain me a little bit more how to achieve this please?

 

Thank you in advance,

ede_pfau

(I knew it. Sorry.)

 

What I wanted to say is that the setup is doable and relatively simple.

First, routing. The client has to have a route to the second network, or traffic will not go across the SSLVPN to reach the FGT.

On the FGT, you will need a route to the network behind the SSLVPN (i.e. your clients) pointing to the 'ssl.root' interface, and a route to the network behind the IPsec tunnel. Imagine visiting each hop on the way from the client to the IPsec network and back: client - FGT - tunnel - IPsec network. At each hop a route to the next hop and back to the previous hop is needed. Sometimes a static explicit route, sometime a default route (to make life easier).

 

Second, if all participants know how and where to send the traffic, then you additionally need a policy to allow it. After all, the FGT is a firewall, a control device. For writing the policy, you need address objects of the source and destination networks, the services you allow, some UTM...

 

In short, both the SSLVPN and the IPsec VPN are represented as virtual ports on the FGT. You route and allow traffic between these ports just like between any pair of physical ports.

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

Thank you for your fast reply.

 

Here is what i have configure :

 

- Static route Dest 10.133.3.0/24 Device ssl.root

- Policy Src=ssl.root Dest=10.133.3.0/24 Action=Accept

 

I'm running 5.2.4, and i do not have any policy with SSL as Action as it is not showing anymore (removed sinve ver5.2 i mean)

 

I'm trying a traceroute and it is blocking first hop (the ip of my SSL connection)

 

The SSL pool is 192.168.7.222-192.168.7.225

 

Kind Regards,

rwpatterson
Valued Contributor III

evince wrote:
- Static route Dest 10.133.3.0/24 Device ssl.root

The SSL pool is 192.168.7.222-192.168.7.225

 

The static route should point to the IP addresses in the SSL IP pool.

 

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
ede_pfau

...right, and there should be a static route to 10.133.3.0/24 pointing to the IPsec tunnel interface.

Please post the entire policy - interfaces, addresses.

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

Hello and many thanks :)

 

As it is a tunnel mode IPSec and not an Interface mode, i can not point to the IPSec tunnel interface.

 

   edit 155         set srcintf "Lens"         set dstintf "wan1"         set srcaddr "Lens_Subnet" (192.168.7.0/24)         set dstaddr "Cloud_Systemat" (10.133.3.0/24)         set action ipsec         set schedule "always"         set service "ALL"         set natip 172.31.19.0 255.255.255.0         set comments "natted to 172.31.19.0/24"         set inbound enable         set outbound enable         set natoutbound enable         set vpntunnel "Lens_To_Cloud"     next

ede_pfau

This mode is called "policy-based" vs. "interface-based" IPsec VPN. Both generate tunnels.

Best to re-create the VPN in interface mode. There is no direct way to reconfigure it. I don't see any other way to get the routing done.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
rwpatterson
Valued Contributor III

ede_pfau wrote:

This mode is called "policy-based" vs. "interface-based" IPsec VPN. Both generate tunnels.

Best to re-create the VPN in interface mode. There is no direct way to reconfigure it. I don't see any other way to get the routing done.

Yes, you have to break it down and rebuild it. Sorry, no magic wand here.

Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com

Bob - self proclaimed posting junkie!See my Fortigate related scripts at: http://fortigate.camerabob.com
Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors