4 Replies Latest reply on Jun 2, 2016 2:54 PM by robertpuh

    Dial-In VPN internet access question

    robertpuh

       

      Hello all,


      I have configured Dial-in VPN with support for IPSEC and SSL connections. I am using original dial in client. If I connect with IPSEC everything works as expected … access to internal network is ok and also access to internet is possible through local client internet connection (this is what I prefer). On the other hand, if I connect with SSL protocol, access to internal network works as expected, but client cannot reach internet. If I look into the logs it looks like client is trying to reach internet through company internet access (which I am not allowing of course). Is there any way to configure same behavior as with IPSEC protocol regarding client internet Access?

       

      Thanks for help, 

      Robert

       

        • 1. Re: Dial-In VPN internet access question
          thyvarin

          Hi,

           

          Can you clarify what you mean by "original dial in client"? Are you talking about McAfee/Stonesoft VPN client, or perhaps built-in VPN client in Windows (or something else)?

           

          With McAfee/Stonesoft VPN client (on Windows), when you enable NGFW VPN endpoint as both IPsec and SSL VPN Tunneling client endpoint, you can use same mobile VPN configuration for both, and split-tunneling is used for both IPsec and SSL client connections (unless of course you add ANY network VPN site to force all traffic from VPN client computer to use the tunnel when VPN is connected).

           

          Thanks,

          Tero

          • 2. Re: Dial-In VPN internet access question
            robertpuh

             

            Hi Tero,

             

            Thanks for your reply. By »original VPN client« I indeed meant McAfee/Stonesoft VPN client. Problem I have is, that split-tunneling (this means only corporate network is accessed through VPN and internet is accessed through local ISP wherever client is connected to net – right?) is working if I select IPsec connection in VPN client to corporate gateway. If I select SSL VPN than, when client is connected and trying to reach internet (any network that is not internal corporate) it goes through VPN Tunnel … I can see this in logs. I thought that this is »by design«, but now I see I am doing something wrong …

             

            Any additional thoughts appreciated …

             

            Thank you, 

            Robert

            • 3. Re: Dial-In VPN internet access question
              thyvarin

              Hi,

               

              Yes, split-tunneling means that only traffic to networks behind mobile VPN GW is sent to tunnel, while other traffic to e.g. Internet will be sent out "normally". And split-tunneling should be used also for SSL VPN Tunneling client connections. I tested this with VPN client 5.9.2 and default route was still pointing to local network router while routes networks through VPN show "On-link" as gateway which means that traffic to these networks will be sent to SSL tunnel. If this doesn't happen in your case, I would recommend that you open Service Request to NGFW support as we would need data to investigate this further. If you can upload screenshots showing "Sites" and "VPN Client" settings from your FW VPN properties as well as "IPsec Client" tab settings from the VPN profile used on your mobile VPN configuration, we can also comment on those if there's anything defined that would right away explain this.

               

              BR,

              Tero

              • 4. Re: Dial-In VPN internet access question
                robertpuh

                Hi,

                 

                I configured VPN without split tunneling at the moment. I can not experiment any more on this NGFW since it has been put into Production. Anyhow, I Will configure another one for another client in two weeks, and I Will start from the scratch and test if it Works as expected. After that I Will get back with info.

                 

                Thank you for now,

                Robert