Navigation

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

    Unusual behaviour on secondary networks

    Installation and Upgrades
    3
    11
    1540
    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.
    • D
      draccusfly last edited by

      Hi, I am pretty new to pfsense to still learning all the pitfalls etc.

      We have deployed pfsense as our primary firewall with 4 NICS, 1 for external, 1 for internal and 2 for DMZ or segregated subnets.  The 2 segregated subnets are used for VPN connections to our customer sites using different LAN IP ranges to our internal LAN.  Internal users RDP onto 2 machines on these subnets in order to open VPN tunnels to our customers sites.  This uses to work fine on our old firewall, however now as soon as the VPN tunnel is established the local RDP session gets closed down and you can no longer access the machine until the tunnel has been closed.
      Not even sure where to start to look to trouble shoot this one, so any pointers would be greatly appreciated..

      regards
      Drac

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

        Where are you running the VPNs? In the pfSense box or in the RDP server machines?
        It sounds like the VPN is changing the default route such that the RDP traffic is captured and sent down the VPN instead of across the local network.

        Steve

        Edit: typo

        1 Reply Last reply Reply Quote 0
        • D
          draccusfly last edited by

          The VPNs are being run on the Windows boxes.  As we have a large number of clients that our support reps connect to it's more convenient to use this method than create the VPN's on the pfSense box. This all worked fine on our previous firewall so it must be something in the configuration of pfsense?

          Drac

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

            The most logical answer is stephen's – Quite often default connection type for a vpn is to prevent split tunnel, and for default gateway to be changed to the vpn connection.

            I would validate your vpn setup, what vpn are you using?  If allows split tunnel then you might need to add the network your coming from to rdp to the box an allowed network, etc.

            1 Reply Last reply Reply Quote 0
            • D
              draccusfly last edited by

              Looking through the VPN > networking > advanced properties there is an option of "Use gateway on remote network" option.  But this has always been ticked, unticking allows users to stay connected to the RDP session when the tunnel is established though, next test is to see if they can actually connect to customer machines.

              Drac

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

                It's hard to see how pfSense could differ from any other firewall/router in this setup. I guess your old firewall could have been handing out routing information pointing to local subnets that took priority over the VPN gateway.  :-\

                Steve

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

                  Was the previous setup multi segment?  Or were you rdping to boxes on the same segment.. Did the address space change?  Its possible the vpn was allowing split tunnel with your previous network space and now that your own pfsense you change the address space?

                  Impossible to really speculate with such little info to work with.

                  But I agree with stephen - the firewall/router involved has really little to do with what would cause you to loose remote access to a machine that kicks off a vpn connection that is set to use that vpn as gateway.

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

                    Yep, that seems likely. The VPN connections were setup to route all traffic with some exceptions for local address space. That address space had now changed rendering the exceptions useless. Speculation only at this point of course.

                    Steve

                    1 Reply Last reply Reply Quote 0
                    • D
                      draccusfly last edited by

                      Thanks guys, I appreciate the help on this.  Just to give you a better idea of setup:
                      WAN
                      Subnet A 192.168.10.0/22 - this is the local LAN
                      Subnet B 192.168.150.0/24 - DMZ1 - VPN machine 1 connected to this subnet
                      Subnet C 10.10.0.0/24 DMZ2 - VPN machine 2 connected to this subnet

                      Machines on subnet A RDP to machines on subnets B and C in order to start the VPN tunnel to our customers site.  Machines on subnets B and C should not be able to reach machines on subnet A, however with the pfsense firewall they do.  I am pretty sure on our old firewall this wasn't the case, but I have no way of being 100%sure of this now.  What is happening now is that when the tunnel establishes on subnet B or C the connection to subnet A gets dropped, unless I remove the tick from "use the VPN gateway" option from the properties of the VPN tunnel.  This option has always been ticked previously without any issues.  So my thinking is that the issue lies somewhere in the pfSense boxes routing?

                      Address space hasn't changed, the only change to our internal system is the firewall..

                      I hope this helps to give you a better idea of my setup..?

                      Drac

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

                        Hmm, OK. Has the remote subnet at the customers end changed? You could be seeing some sort of address conflict there that might explain the changed behaviour.
                        It's hard to explain why it has changed but not hard to understand what's happening, it's exactly what I'd expect to happen. When you make the VPN connection it pushes a new default route to the client and all traffic is then routed through the tunnel. In those cases you usually still have access to the local subnet but your RDP clients are not on the local subnet.
                        Is it causing a problem when you untick "use the VPN gateway"? Doing so would likely mean the RDP machines have access only to the remote network in the same subnet as the VPN server and not any remote routed subnets. You could probably push routes to allow that though.

                        By default pfSense will block traffic from an additional interface, such as DMZ1, to the LAN interface. This is only getting through because there are firewall rules in place that allow it. What rules do you have on DMZ1 and 2?

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • D
                          draccusfly last edited by

                          I have a couple of inbound NAT rules pointing to other systems on the subnet.  But other than that there is nothing else.  It appears that removing this tick from the VPN connection properties has fixed the issue.  I have had no other negative feedback from our support agents so I have to assume that this change has fixed the issue.

                          Still getting to grips with the system.. :)

                          Drac

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post

                          Products

                          • Platform Overview
                          • TNSR
                          • pfSense
                          • Appliances

                          Services

                          • Training
                          • Professional Services

                          Support

                          • Subscription Plans
                          • Contact Support
                          • Product Lifecycle
                          • Documentation

                          News

                          • Media Coverage
                          • Press
                          • Events

                          Resources

                          • Blog
                          • FAQ
                          • Find a Partner
                          • Resource Library
                          • Security Information

                          Company

                          • About Us
                          • Careers
                          • Partners
                          • Contact Us
                          • Legal
                          Our Mission

                          We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                          Subscribe to our Newsletter

                          Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                          © 2021 Rubicon Communications, LLC | Privacy Policy