This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Client IP address config for SSL VPN

Hello bulletin board users.

This is my first post, so please bear with me. [:)]

I have worked with a number of gateway security products (both Firewall and SSL VPN solutions - in some cases Firewalls SSL VPN included) during the past 18 years and simply because I enjoy these solutions I have set up a UTM9 test system at home so that I can add another product to my knowledge portfolio.

Today I thought I'd try the SSL VPN function on my UTM installation. I have worked with stand-alone SSL VPN solutions (installed inside a gateway Firewall) and have also worked with the SonicWALL Firewall range which includes an SSL VPN module. As with these other products I see that it is necessary to assign a Virtual IP address pool to the UTM SSL-VPN configuration, but with these other solutions I am used to the SSL-VPN client being issued an address from the same internal network range, so the remote client is "seen" by the LAN resources as if it is just another LAN client machine. However, I noticed that the pre-defined "VPN Pool (SSL)" is a completely different subnet. 

Is there a reason for this?

I was able to successfully connect a machine from the WAN side of my UTM to the user portal, download and install the SSL-VPN client. Once I had done this I was then able to successfully establish an SSL-VPN session. I was able to ping the LAN IP address of my UTM, but couldn't ping any other IP address on the LAN side. I suspected this may be because the target machine didn't know about the 10.242.2.x address which had been assigned to the virtual adapter on the client machine. So I though I'd try assigning a different Virtual IP pool to the SSL-VPN settings section on my UTM. I have configured the DHCP server on my UTM to assign addresses x.x.x.100-150 and though I could use another small range of addresses x.x.x.200-210 from the same LAN subnet for SSL-VPN connections. I created a network range definiton, but when I tried to assign this as the Virtual IP pool and tried to apply the change I saw the error:-

"SSL IP pool networks cannot be larger than /16."

This isn't the case here, so I can only assume that the system doesn't like the fact that I have tried to use a Range definition. 

So, instead I opted for a subnet object representing the LAN side of my UTM (10.100.11.0/24). I tried a new SSL-VPN client connection and this time I was assigned the address 10.100.11.6. I've discovered that with this client IP address I am no longer even able to ping the LAN address of my UTM which left me scratching my head. If I try an ping another host on my 10.100.11.x subnet (10.100.11.100) and run a tcpdump on the LAN interface I can see the echo request, but all that follows are a series of ARP requests which never appear to resolve:-

16:37:18.681954 IP 10.100.11.6 > 10.100.11.100: ICMP echo request, id 1, seq 868, length 40
16:37:18.682302 ARP, Request who-has 10.100.11.6 tell 10.100.11.100, length 46
16:37:19.449759 ARP, Request who-has 10.100.11.6 tell 10.100.11.100, length 46
16:37:20.448967 ARP, Request who-has 10.100.11.6 tell 10.100.11.100, length 46
16:37:23.659668 IP 10.100.11.6 > 10.100.11.100: ICMP echo request, id 1, seq 869, length 40

I have completely disabled the client Firewall on 10.100.11.100, just to make sure it isn't the reason why these ICMP echo requests are never fulfilled.

When I switch back to using the default "VPN Pool (SSL)" definition, I am then able to ping 10.100.11.100 from my SSL-VPN client machine and this is backed-up by the tcpdump output:-

16:44:24.120765 IP 10.242.2.6 > 10.100.11.100: ICMP echo request, id 1, seq 1141, length 40
16:44:24.120965 IP 10.100.11.100 > 10.242.2.6: ICMP echo reply, id 1, seq 1141, length 40

I can only assume the reason why it didn't work when I first configured SSL-VPN to use this Virtual IP pool range was because the software firewall on the target machine was blocking the request. I have since re-enabled the software Firewall, but have explicitly allowed ICMP from the Virtual IP pool range and I can still ping it from my SSL-VPN client machine.

So it is the case that with the SSL-VPN function the address range issued by the Virtual IP pool must be different from the subnet used by the remote network you are trying to connect to?

Any thoughts or insights into this, so that I may better understand the SSL-VPN functionality on this solution would be appreciated.

Many thanks in advance.
-Phil.


This thread was automatically locked due to age.
  • Hi, Phil, and welcome to the User BB!

    "SSL IP pool networks cannot be larger than /16." - Use CIDR notation, not the Range definitions as they're new and occasionally generate errors when used in unexpected places.

    Don't change any of the VPN Pool definitions.  Just put Internal (Network)" into the 'Local networks' field and select 'Automatic firewall rules' - WebAdmin will generate all of the rules and routes necessary for the remote user to access your internal devices.  Complete the 'Advanced' section also.

    Rather than use a masq rule to change the packets to come from "Internal (Address)," it's cleaner to adjust the local firewalls - personally, I prefer to turn off the software firewalls and replace any current anti-virus with the Sophos Endpoint.

    You might be interested in The Zeroeth Rule in Rulz and in DNS Best Practice.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thank you for your response, Bob.

    As mentioned I am quite new to this product (though I have worked with many similar ones over the years) so I am trying to gain an understanding of how Sophos UTM behaves compared to the others.

    Can you provide or point me in the direction of any examples of how different remote access profiles could be implemented. With other solutions, the assignment of the Virtual IP range would be part of the 'profile' entry with different groups of users being assigned different Virtual IP ranges and granular remote access could be acheived by defining rules specific to those source IPs. With this product the Virtual IP Pool is assigned globally in the Settings tab, so no matter how many different profiles you define, the remote users will all have client IP addresses from the same pool.

    Looking at the auto Firewall rule created from my test profile, I can see that the user group is used as the source criteria. So I guess my question to this is does it make any difference if you employ multiple profiles (group1, group2, etc...) or assign all groups to a single profile and then have different Firewall rules to control access - e.g. users in group1 are allowed access to the entire network, but users in group2 aren't allowed to access a specific target IP address?

    Thanks again.
    -Phil.
  • Let me restate your problem in my own words, Phil, so you can tell me if I've understood.  You have several different groups of people to whom you want to give access to different resources.

    Say you want to let Teachers access the school's Management server as well as the class plans and assignments on the Homework server.  Students can access the Homework server.  Both servers are in a DMZ on a UTM interface named "DMZ."

    Create User Groups named "Teachers" and "Students," each based on Backend Membership in a corresponding Security Group in Active Directory.

    Create a single SSL VPN Profile that allows "Teachers" and "Students" to reach "DMZ" and do not select auto firewall rules.

    Create a firewall rule for each group.  'Teachers (User Group Network) -> Any -> Management, Homework : Allow' and similarly for the Students.

    Note the use of the "(User Group Network)" objects which are created when you define the User Groups.

    Clear as mud, now? [;)]

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA