Thanks for this important reminder. I have found the following info in the release note, which should have been highlighted. When the RVL 200 is upgraded from firmware version 1.1.7 to 188.8.131.52, the SSLVPN feature needs to be enabled manually.
... View more
SOLUTION FOUND! Again, my intent was to use the RVL200 as a standalone SSL VPN box for remote access into my network, not as a firewall and DHCP server. As it turns out, your remote SSL VPN connections (virtual passage interfaces) "WILL NOT" be assigned internal DNS or WINS information unless DHCP is enabled on the RVL200. But if one has another DHCP server inside the network (such as a Windows DHCP server), then turning on DHCP on the RVL200 will cause DHCP conflicts. But not enabling it on the RVL200 causes the remote SSL VPN tunnel (virtual passage interface on the client) to not work properly because it doesn't have any internal DNS/WINS servers assigned. Although there was no official fix for this, there is a workaround that I came up with that seems to solve my dilema. The workaround is to "ENABLE" DHCP on the RVL200, but to reduce the DHCP range to just 1 IP address (for example 192.168.x.254). I then went into reservations and created a reservation for a fake MAC address (for this example BAD000000000) and made sure that the one any only IP address in that range is reserved for that fake MAC address. Since there's only one IP address in the DHCP pool and that address has been reserved, the RVL200's DHCP server will never assign IP addresses to the internal network, therefore will never conflict with the Windows DHCP server. But because DHCP has now been enabled on the RVL200, the virtual passage (SSL VPN connection) WILL be assigned the internal DSN and WINS IP addresses for internal resolution. Hope this helps.
... View more