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

    Client VPN to Azure

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 2 Posters 176 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.
    • M
      Maximillian
      last edited by

      Home network. I have station that runs an MS Access app that connects to MS SQL Server on Azure. The station connects via VPN before opening the MS Access database, and is only connected via VPN when using the app. This works fine with an off the shelf router, which I was using a Synology 6600AX. The MS Access database/app is locked (gov usage) so I am unable to adjust anything there.

      I swapped out the Synology with an server running CE pfSense 2.7.2-RELEASE (amd64). Everything is great, except the MS Access is no longer able to connect to SQL Server on Azure. VPN connects just fine, but routing doesn't work. I don't know the IP address of the server so I can directly ping or trace to it (again, locked app). I've tried setting rule up in Firewall > NAT > Outbound for to handle the specific machine by IP to the Azure network, and also separate attempt to allow entire local network (ideal) to the Azure. Also attempted rules in Filrewall > Rules > Lan.. nothing works.

      Since off the shelf routers allow functionality, and it stops with pfSense, it's obviously firewall/routing issues on my pfSense intall.

      Pretty much vanilla install of pfSense, with home net being 192.168.1.0 and VPN net being 172.x.x.0.

      Any assistance on this would be greatly appreciated. Ideally, I need the ability for 2-3 stations running VPN individually and to run this MS Access app. Site-to-Site isn't an option.

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

        Do you know what type of VPN it is?

        You might try adding an outbound NAT rule with static ports set. Almost nothing needs that these days but.....

        The other possibility is that other soho style routers often include various helper/proxy apps that fix broken connections so you never know. Until you swap out the router. That's usually VoIP though.

        M 1 Reply Last reply Reply Quote 0
        • M
          Maximillian @stephenw10
          last edited by

          @stephenw10 The VPN to Azure is SSTP. I had to manually add certs to the client machines.

          For the moment, I had to revert back to the Synology so my wife could get up and working again. Though I'm going to continue working on this as I have a separate pipe into my home and I'll keep working on that pipe with the pfSense.

          I actually attempted this in December, but do to time constraints quickly switched it back to the Synology. But of course I would prefer to use pfSense.

          A previous attempt was I added outbound NAT rule with the source being my local net, and the destination being the VPN net. I used an alias with all the ports: 1433, 11000-11999 (as per the Azure boundary). That didn't seem to work, but I'm open to that I set the rule incorrectly.

          Unfortunately, the response I got from the gov tech guys was "that is out of our scope", which translates too - "I have to do something and I don't want to, so I'll push it off".

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

            Did you set static source ports on the outbound rule?

            I would probably test a rule that just matches the one internal IP trying to connect and all ports to be sure.

            Then check what states it's opening when it fails. Or succeeds!

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