Unusual behaviour on secondary networks



  • 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


  • Netgate Administrator

    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



  • 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


  • LAYER 8 Global Moderator

    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.



  • 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


  • Netgate Administrator

    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


  • LAYER 8 Global Moderator

    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.


  • Netgate Administrator

    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



  • 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


  • Netgate Administrator

    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



  • 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


Log in to reply