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.