Client/Server SSL VPN - Access from Company LAN to Client machine possible?

USG_User

We are using SecuExtender for a SSL VPN connection from Home to our Company LAN via USG110. Works fine since weeks and the users have access to our Company LAN, Server Shares and Email inboxes.

But is it possible to get access also in the opposite way from Comapny LAN to the VPN client machine, when the VPN tunnel is established? Or do we need a site-to-site VPN for that reason?

I'm aware that normally an additional route is necessary from LAN to VPN tunnel, but the USG should know this route since it is the VPN server itself. Further I'm not able to set an additional route since the VPN clients have reserved IP addresses from the Company LAN, means from the same subnet. Or have I arrange an additional route from Company LAN to special tunnel IP subnet?

Jeremylin

If VPN clients have reserved IP addresses from the Company LAN.
Create the security policy rule: Company LAN to SSL_VPN, Allow.  to let company lan can access PC(ssl vpn client)
Note: To avoid the IP overlap, please segment IP range carefully

USG_User

Thanks Jeremylin, this was already tested. This additional security policy let me ping the VPN machines successfully. But still don't get access to client shares or administrator shares (C$), irrespective whether I try to connect accessing by name (DNS) or IP. Of course, some VPN clients are private notebooks from our home workers, but other machines are company machines where I should get access with my company administrator privileges.

itxnc

Do you have these settings checked?

USG_User

The second checkbox isn't activated since we don't want to force the entire VPN Client traffic (like internet traffic) through the tunnel. Further this would influence the client traffic only (initiated by the VPN client). But the client has full access to all company LAN ressources, this works so far properly.

We are searching for a way to get access to VPN client machines when initiated from Company LAN machines.

itxnc

USG_User said:

We are searching for a way to get access to VPN client machines when initiated from Company LAN machines.

You need a firewall rule allowing access from LANx (your company LAN) to the SSLVPN zone. You may also need to setup a route for this, but not 100% sure. Remember the SSLVPN uses a middleman IP/subnet (often 192.168.200.x)

USG_User

itxnc said:

You need a firewall rule allowing access from LANx (your company LAN) to the SSLVPN zone. You may also need to setup a route for this, but not 100% sure. Remember the SSLVPN uses a middleman IP/subnet (often 192.168.200.x)

I'm aware of it. And as already said, an additional firewall rule (access of LAN to SSL VPN) is in place which let me successfully ping the VPN clients from LAN.

But I'm also unsure with the additional route.

First, normally the USG is knowing all of its connected zones and therefore additional routes are not necessary. We have also no additional routes in place for traffic between our two LAN segments or to/from DMZ zone. Only some firewall rules.

Second, when connecting, the VPN clients get (reserved) IP addresses from our LAN segment. Where the IP packets should be routed to, when the destination host is in the same subnet? For example:

LAN IP range 192.168.21.X   (X - from 50 to 100)

SSL VPN Clients 192.168.21.X   (X - from 150 to 180)

But of course I'm nevertheless able to set an additional Policy Route with "Incoming Interface: LAN1 / Source Address: LAN1 Subnet / Destination Address: SSL VPN IP Range"

But it doesn't work. I'm always trying to connect to an administrative share at a VPN client, e.g. \\192.168.21.152\C$ without success.

CHS

Your SSL VPN client IP address and server address are belonging to same subnet.(192.168.21.X)
Both of IP address communication is belonging to broadcast, so traffic will not forward into SSL VPN tunnel.
You may assign a non-LAN IP subnet to your SSL VPN client, then it should without problem.
e.g. 100.100.100.1~100.100.100.100

USG_User

Thanks CHS, but when trying to access a known IP address from the SSL VPN range in order to connect to a client share, this is unicast but not broadcast. In in case my security policy enables all traffic services from LAN to SSL VPN, also all Microsoft (IP) services should be passed, isn't it? I'm aware that netbios will normally not routed and that's why the network environment is not showing the remote (VPN) clients. But direct connections should work nevertheless like in the opposite way from (VPN) client to our servers at Company LAN, because this works properly.

itxnc

But @CHS is right - when  you use the SSLVPN Extension network (192.168.200.1 is the default), your scenario works fine. Just tested it on a USG40. Both with full tunnel checked and unchecked. In full tunnel mode - you don't need the LAN1->SSL_VPN Security Policy. In split tunnel mode, you do. No route needed.


So I SSL VPN in and the remote client gets 192.168.200.10 as their VPN IP. I can ping it and open C$ shares with \\192.168.200.10\C$ - no need for any route setting. 


We did the SSL_VPN segment of LAN1 for the SSL_DHCP_POOL way back and found it more hassle than it was worth. The Network Extension worked great and everything just 'worked' as expected. Just like here. 

In domain environments, we set DNS to the domain controllers...

USG_User

Thanks @itxnc , it seems this is the one and only difference between our settings. While you are using IP addresses from the preselected/proposed 192.168.200.x subnet for your SSL VPN clients, we are using reserved IP addresses directly from our office LAN segment 192.168.21.x. Nevertheless the "network extension local ip" of the USG is still set to 192.168.200.1.

The tunnel works fine with us for all client accesses to company LAN. Only the opposite way, when an Admin would like to get access to an VPN Client machine, doesn't work. I think I should give it a try and should change the SSL VPN subnet to 192.168.200.x. You said this is possible without any route settings to access our 192.168.21.x subnet. I take for granted that, despite of the different IP address range, the clients nevertheless reach our LAN DNS server. I don't want to add the Zywall itself as DNS but our DC DNS instead.