Skip to main content
evince
New Member
February 2, 2016
Solved

Allow traffic from ssl-vpn to enter ipsec tunnel

  • February 2, 2016
  • 2 replies
  • 23328 views

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,

    Best answer by 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.

    2 replies

    ede_pfau
    SuperUser
    SuperUser
    February 2, 2016

    1- routing

    2- policy

    evince
    evinceAuthor
    New Member
    February 2, 2016

    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
    SuperUser
    SuperUser
    February 2, 2016

    (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.

    AlbertFader
    New Member
    November 30, 2022

    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