Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Way to deploy VPN without tunnel?

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 4 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • T Offline
      ttblum
      last edited by

      Hello,

      I need to deploy a client/server Windows application over the internet.  The client software connects to my server over a TCP port.  However, since the traffic isn't encrypted, it needs to be encapsulated and encrypted.

      I usually set up a VPN tunnel between my network to the router at each remote network.

      I now need to deploy this application at a number of offices where the router there doesn't support IPSec.  Circumstances don't allow me to replace the router at these offices.

      Is there some way to have a clientless VPN client that runs through a web browser?  Does the built-in IPSec functionality of Windows work with pfSense, and through a NAT device?

      Is there some sort of VPN device that could sit behind the main router, that the traffic could be routed through somehow?

      I've deployed OpenVPN clients on Windows as well, I'm just wondering if there are any alternatives.

      1 Reply Last reply Reply Quote 0
      • H Offline
        heper
        last edited by

        https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2

        1 Reply Last reply Reply Quote 0
        • stephenw10S Offline
          stephenw10 Netgate Administrator
          last edited by

          You might potentially use Stunnel for that:
          https://doc.pfsense.org/index.php/Stunnel_package

          Steve

          1 Reply Last reply Reply Quote 0
          • T Offline
            ttblum
            last edited by

            OK, thanks.

            Does stunnel always forward from 127.0.0.1, or is there a way to address private IPs on the other side?  This application has a private IP hardcoded into it to connect to.

            I'm considering using OpenVPN with SSL/TLS only, launching it with Task Scheduler.  I don't know if that's reliable, though.

            Is there any way to know how reliable OpenVPN-w-TaskScheduler or IKEv2-wEAP-MSCHAPv2 are in the real world?

            1 Reply Last reply Reply Quote 0
            • stephenw10S Offline
              stephenw10 Netgate Administrator
              last edited by

              If it's hard-coded with a private IP then you will need a tunnel of some sort to carry that traffic. That does also mean that if the tunnel is down it can't every successfully connect, there is no chance of accidentally establishing an unencrypted connection.

              Steve

              1 Reply Last reply Reply Quote 0
              • T Offline
                ttblum
                last edited by

                Ok.

                Maybe I'll go with running SSL/TLS OpenVPN as a Windows service

                1 Reply Last reply Reply Quote 0
                • johnpozJ Offline
                  johnpoz LAYER 8 Global Moderator
                  last edited by

                  Running a openvpn server behind pfsense brings possible asymmetrical routing issues to the table..

                  So normally in 1. pic client wants to talk across the vpn to your server.. He hits his default gateway the 192.168.1.1 on the left and router sends it down the vpn.. Answer comes back through the vpn to the client.

                  With a vpn endpoint inside the network without host routing you have an asymmetrical issue.  So client says hey I want to talk to server on 192.168.0.100 he his default router.. Router sends that traffic to your vpnserver at .10.. But answer will come back through the vpn and then just go to the client.  You have a hairpin and asymmetrical.

                  So you need to make that your host has a route on it that says when I want to talk to server over at 192.168.0.200 - send my traffic to 192.168.1.10 vs my default gateway.  This removes the hairpin and the asymmetrical issue.

                  vpnwithasym.png_thumb
                  vpnwithasym.png

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S Offline
                    stephenw10 Netgate Administrator
                    last edited by

                    Yeah, asymmetric routing bad! I wonder what percentage of all issues we see are that…hmm.  ::)

                    But that shouldn't be an issue if your running the VPN client on the same machine running your application and the server is on pfSense. Which is how I understand it. I may be wrong....

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • johnpozJ Offline
                      johnpoz LAYER 8 Global Moderator
                      last edited by

                      ^ true if the client was running the vpn through the router to the pfsense as a road warrior sort of connection then no you wouldn't have the asymmetrical issues.  That is not how I understood what he was suggesting on doing.

                      But then every client wanting to use the application would have to run vpn client.

                      An intelligent man is sometimes forced to be drunk to spend time with his fools
                      If you get confused: Listen to the Music Play
                      Please don't Chat/PM me for help, unless mod related
                      SG-4860 24.11 | Lab VMs 2.8, 24.11

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.