Windows 10 user, cant access google domains

Question

We have a problem occur with a win10 user whom connects via OpenVPN SSL to our SG230 (fw 9.405-5). This was reported for the first time over the weekend, and does not happen to other users. Remote users should only go through the VPN for remote access, there is no filtering of the web traffic when remote users connect to the VPN. 
 When connected to the VPN, the user can no longer access and google domains. Connection just times out. The user can ping google.com, but websites don't connect. We have tested other computers and they are not having this problem. The user has reset the home modem, router, computer and flushed the DNS. This happens on both wired and wireless connections. When the user disconnects from the VPN there is no issue with google domains, everything works. All other internet access works, just not google domains. 
 Can you offer some suggestions of other things to test to try and find and resolve the issue. 
 
 Here is the connection log from the user: 
 Mon Oct 03 08:34:20 2016 DEPRECATED OPTION: --tls-remote, please update your configuration Mon Oct 03 08:34:20 2016 OpenVPN 2.3.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Jun 25 2016 Mon Oct 03 08:34:20 2016 library versions: OpenSSL 1.0.1t 3 May 2016, LZO 2.09 Mon Oct 03 08:34:20 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25341 Mon Oct 03 08:34:20 2016 Need hold release from management interface, waiting... Mon Oct 03 08:34:20 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25341 Mon Oct 03 08:34:20 2016 MANAGEMENT: CMD 'state on' Mon Oct 03 08:34:20 2016 MANAGEMENT: CMD 'log all on' Mon Oct 03 08:34:20 2016 MANAGEMENT: CMD 'hold off' Mon Oct 03 08:34:20 2016 MANAGEMENT: CMD 'hold release' Mon Oct 03 08:34:25 2016 MANAGEMENT: CMD 'username "Auth" "name"' Mon Oct 03 08:34:25 2016 MANAGEMENT: CMD 'password [...]' Mon Oct 03 08:34:25 2016 Socket Buffers: R=[65536->65536] S=[65536->65536] Mon Oct 03 08:34:25 2016 MANAGEMENT: >STATE:1475508865,RESOLVE,,,,,, Mon Oct 03 08:34:25 2016 Attempting to establish TCP connection with [AF_INET]***.***.***.***:4443 [nonblock] Mon Oct 03 08:34:25 2016 MANAGEMENT: >STATE:1475508865,TCP_CONNECT,,,,,, Mon Oct 03 08:34:26 2016 TCP connection established with [AF_INET]***.***.***.***:4443 Mon Oct 03 08:34:26 2016 TCPv4_CLIENT link local: [undef] Mon Oct 03 08:34:26 2016 TCPv4_CLIENT link remote: [AF_INET]***.***.***.***:4443 Mon Oct 03 08:34:26 2016 MANAGEMENT: >STATE:1475508866,WAIT,,,,,, Mon Oct 03 08:34:26 2016 MANAGEMENT: >STATE:1475508866,AUTH,,,,,, Mon Oct 03 08:34:26 2016 TLS: Initial packet from [AF_INET]***.***.***.***:4443, sid=6a47f923 20576217 Mon Oct 03 08:34:26 2016 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this Mon Oct 03 08:34:27 2016 VERIFY OK: depth=1, C=ca, Mon Oct 03 08:34:27 2016 VERIFY X509NAME OK: C=ca, Mon Oct 03 08:34:27 2016 VERIFY OK: depth=0, C=ca, Mon Oct 03 08:34:29 2016 Data Channel Encrypt: Cipher 'AES-128-CBC' initialized with 128 bit key Mon Oct 03 08:34:29 2016 Data Channel Encrypt: Using 128 bit message hash 'MD5' for HMAC authentication Mon Oct 03 08:34:29 2016 Data Channel Decrypt: Cipher 'AES-128-CBC' initialized with 128 bit key Mon Oct 03 08:34:29 2016 Data Channel Decrypt: Using 128 bit message hash 'MD5' for HMAC authentication Mon Oct 03 08:34:29 2016 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA Mon Oct 03 08:34:29 2016 [***] Peer Connection Initiated with [AF_INET]***.***.***.***:4443 Mon Oct 03 08:34:30 2016 MANAGEMENT: >STATE:1475508870,GET_CONFIG,,,,,, Mon Oct 03 08:34:31 2016 SENT CONTROL [***]: 'PUSH_REQUEST' (status=1) Mon Oct 03 08:34:31 2016 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.200.1,route-gateway 192.168.200.1,topology subnet,ping 10,ping-restart 120,route 192.1.1.0 255.255.255.0,route 192.168.10.0 255.255.255.0,route 192.168.1.0 255.255.255.0,dhcp-option DNS 192.168.10.200,dhcp-option DNS 192.168.1.231,dhcp-option WINS 192.168.10.200,dhcp-option DOMAIN ***.***,ifconfig 192.168.200.8 255.255.255.0' Mon Oct 03 08:34:31 2016 OPTIONS IMPORT: timers and/or timeouts modified Mon Oct 03 08:34:31 2016 OPTIONS IMPORT: --ifconfig/up options modified Mon Oct 03 08:34:31 2016 OPTIONS IMPORT: route options modified Mon Oct 03 08:34:31 2016 OPTIONS IMPORT: route-related options modified Mon Oct 03 08:34:31 2016 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Mon Oct 03 08:34:31 2016 ROUTE_GATEWAY 192.168.5.1/255.255.255.0 I=4 HWADDR=ec:f4:bb:6a:e5:fb Mon Oct 03 08:34:31 2016 open_tun, tt->ipv6=0 Mon Oct 03 08:34:31 2016 TAP-WIN32 device [Ethernet 2] opened: \.\Global\{6F3EB1A9-FAFC-4A76-A9BE-58E3FD69BC51}.tap Mon Oct 03 08:34:31 2016 TAP-Windows Driver Version 9.21 Mon Oct 03 08:34:31 2016 Set TAP-Windows TUN subnet mode network/local/netmask = 192.168.200.0/192.168.200.8/255.255.255.0 [SUCCEEDED] Mon Oct 03 08:34:31 2016 Notified TAP-Windows driver to set a DHCP IP/netmask of 192.168.200.8/255.255.255.0 on interface {6F3EB1A9-FAFC-4A76-A9BE-58E3FD69BC51} [DHCP-serv: 192.168.200.254, lease-time: 31536000] Mon Oct 03 08:34:31 2016 Successful ARP Flush on interface {6F3EB1A9-FAFC-4A76-A9BE-58E3FD69BC51} Mon Oct 03 08:34:31 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Mon Oct 03 08:34:31 2016 MANAGEMENT: >STATE:1475508871,ASSIGN_IP,,192.168.200.8,,,, Mon Oct 03 08:34:35 2016 TEST ROUTES: 4/4 succeeded len=4 ret=1 a=1 u/d=up Mon Oct 03 08:34:35 2016 MANAGEMENT: >STATE:1475508875,ADD_ROUTES,,,,,, Mon Oct 03 08:34:35 2016 C:\WINDOWS\system32oute.exe ADD ***.***.***.*** MASK 255.255.255.255 192.168.5.1 Mon Oct 03 08:34:35 2016 Warning: route gateway is ambiguous: 192.168.5.1 (2 matches) Mon Oct 03 08:34:35 2016 Route addition via service failed Mon Oct 03 08:34:35 2016 C:\WINDOWS\system32oute.exe ADD 192.1.1.0 MASK 255.255.255.0 192.168.200.1 Mon Oct 03 08:34:35 2016 Route addition via service succeeded Mon Oct 03 08:34:35 2016 C:\WINDOWS\system32oute.exe ADD 192.168.10.0 MASK 255.255.255.0 192.168.200.1 Mon Oct 03 08:34:35 2016 Route addition via service succeeded Mon Oct 03 08:34:35 2016 C:\WINDOWS\system32oute.exe ADD 192.168.1.0 MASK 255.255.255.0 192.168.200.1 Mon Oct 03 08:34:35 2016 Route addition via service succeeded Mon Oct 03 08:34:35 2016 Initialization Sequence Completed Mon Oct 03 08:34:35 2016 MANAGEMENT: >STATE:1475508875,CONNECTED,SUCCESS,192.168.200.8,***.***.***.***,4443,192.168.5.222,60265 
 
 when trying to access a google page

Emile Belcourt · Accepted Answer

Hi Matt, 
 When you're connected to SSL VPN the user makes DNS requests to the UTM first as per the settings in Remote Access > Advanced. If this is the only user then what I'm about to say will make sense, you will need to enter the VPN Pool for SSL into the allowed networks for Network Services > DNS else their DNS packets will just be dropped and can be confirmed via the firewall logs. 
 If that isn't the case then they might have a broken VPN profile (which is a long shot) and re-installing the software and re-downloading their connection profile would be my next course of action. 
 Lastly, turn off Automatic Firewall Rules for the SSL VPN Profile and create an SNAT rule under Network Protection > NAT > NAT Rules which is for the following: 
 
 Source: SSL VPN Pool 
 Service: Any 
 Destination: Match the configuration of the SSL VPN profile 
 Source Translation: Internal Interface IP of the UTM 
 Automatic Firewall Rule: Enabled 
 
 Basically this makes all communications from the SSL VPN pool look like they're coming from the UTM (even to the UTM in some cases) and will resolve most sticky issues with SSL VPN. 
 I hope one of those common issues I've put a resolution for above helps :) 
 Emile