SSL VPN working until mapped drives are accessed

I have two XG 135  (SFOS 17.5.7 MR-7) running in HA.  I have a remote office using a REDS device and one user connecting via SSL VPN.  Until about a week ago all has been working fine but the the single user connecting via SSL VPN is having an issue where she is unable to connect to network resources.  The VPN connection establishes and remains connected despite losing access to the file server.  I have tried updating firmware, uninstall/install vpn client with no success.  I have done some rudimentary testing and found that once the VPN is connected i can run a continuous ping to the file server indefinitely using both IP and host name.  The moment I open file explorer and navigate the mapped drives, the pings begin timing out.  From that point, I will have access to the network drives and can navigate folders for approximately 2 minutes before I lose access to network drives as well.  Can someone point me in the right direction, I'm at a loss.

Thanks,

Chad

  • Seems odd. Took a quick look into the OpenVPN Community, but could not find any similar issue. 

    Could the Client have a issue with the route? 

    Can you install Telnet on this Client and use Telnet? 

    https://www.technipages.com/windows-10-enable-telnet

    Then try to reproduce this issue with telnet and the common SMB Ports.

    https://en.wikipedia.org/wiki/Server_Message_Block

     

    Is on this SMB Share another service running? Simply to check, if its related to SMB or other services.

    Maybe this client has a weak SMB share and XG is finding IPS Traffic? Did you check the IPS log? 

  • In reply to LuCar Toni:

    Initially thinking a possibly route issue too but not certain how to troubleshoot that or what would have changed.

    I have installed the Sophos VPN client at home this morning and having the same issue as the original VPN user.  

    I have previously looked and looked again this morning at the IPS logs and didn't find anything in there relating to this topic. 

    I have yet to test SMB as I ruled it out because the 30 users onsite and 3 in a remote office aren't experiencing an issue accessing shares.

    However, I originally overlooked and just found pertinent info in the Firewall log.  I am getting Invalid Traffic\Denied\src port 445(SMB) "Could not associate packet to any connection"

    Hopefully this will help.

  • In reply to Chad Logsdon:

    Invalid Traffic should not be an issue. It simply means, there could be old connections or duplicated packets. 

    Another point, i forgot to mention, i would say, maybe the client or server drops the connections completely. 

    Perform a tcpdump on shell and check, what is happening with all those packets. 

    Maybe the server is not responding anymore to those packets at all. (Server Protection feature running on those Servers etc.).

    https://community.sophos.com/products/community-chat/f/knowledge-base-article-suggestions/105811/how-to-tcpdump-on-xg

  • In reply to LuCar Toni:

    Thanks for the help and your patience, I'm learning as I stumble along.  I performed the tcpdump using 'host 192.168.6.2' which is the remote client.  When the VPN client is connected but unable to ping the internal network (192.168.2.5) or browse the network shares, the traffic comes in but nothing out.  From inside the network and try to ping the remote client, I can see the inbound traffic but nothing out.  I pasted some non-working and working examples below.

     
      14:35:53.931342 tun0, IN: IP 192.168.6.2.49309 > 192.168.2.5.53: 8802+[|domain] 
    14:35:53.931517 tun0, IN: IP 192.168.6.2.63245 > 192.168.2.111.53: 7439+ SRV? mydomain.com. (32)                                                              
    14:35:53.931646 tun0, IN: IP 192.168.6.2.49309 > 192.168.2.111.53: 8802+[|domain]                                                                               
    14:35:57.160701 tun0, IN: IP 192.168.6.2.64047 > 192.168.2.5.445: Flags Sleep, seq 1963362584, win 64240, options [mss 1338,nop,wscale 8,nop,nop,sackOK], length 0
    14:35:58.160833 tun0, IN: IP 192.168.6.2.64047 > 192.168.2.5.445: Flags Sleep, seq 1963362584, win 64240, options [mss 1338,nop,wscale 8,nop,nop,sackOK], length 0
    14:36:00.160487 tun0, IN: IP 192.168.6.2.64047 > 192.168.2.5.445: Flags Sleep, seq 1963362584, win 64240, options [mss 1338,nop,wscale 8,nop,nop,sackOK], length 0
    14:36:00.471111 tun0, IN: IP 192.168.6.2 > 192.168.2.111: ICMP echo request, id 1, seq 181, length 40                                                           
    14:36:04.160794 tun0, IN: IP 192.168.6.2.64047 > 192.168.2.5.445: Flags Sleep, seq 1963362584, win 64240, options [mss 1338,nop,wscale 8,nop,nop,sackOK], length 0
    14:36:05.474509 tun0, IN: IP 192.168.6.2 > 192.168.2.111: ICMP echo request, id 1, seq 182, length 40                                                           
    14:36:10.473267 tun0, IN: IP 192.168.6.2 > 192.168.2.111: ICMP echo request, id 1, seq 183, length 40 
    Here are examples to prove traffic is/will route through the tunnel and firewall
      14:28:48.641762 tun0, IN: IP 192.168.6.2.63939 > 192.168.2.111.445: Flags Sleep, seq 1759036114, win 64240, options [mss 1338,nop,wscale 8,nop,nop,sackOK], length  0                                                                              
    14:28:48.642141 Port1, OUT: IP 192.168.6.2.63939 > 192.168.2.111.445: Flags Sleep, seq 1759036114, win 64240, options [mss 1338,nop,wscale 8,nop,nop,sackOK], length 0                                                                            
    14:28:49.587397 tun0, IN: IP 192.168.6.2 > 192.168.2.5: ICMP echo request, id 1, seq 164, length 40                                                             
    14:28:49.587452 Port1, OUT: IP 192.168.6.2 > 192.168.2.5: ICMP echo request, id 1, seq 164, length 40                                                           
    14:28:49.587520 Port1, IN: IP 192.168.2.5 > 192.168.6.2: ICMP echo reply, id 1, seq 164, length 40                                                              
    14:28:49.592239 tun0, OUT: IP 192.168.2.5 > 192.168.6.2: ICMP echo reply, id 1, seq 164, length 40   
  • In reply to Chad Logsdon:

    In such case, please try to perform a drop packet capture. https://community.sophos.com/kb/en-us/127111

  • In reply to LuCar Toni:

    Here is a quick drop packet dump.  While this capture was running, the VPN was connected, Ping was timing out and mapped drives were inaccessible.  
    One strange entry below found in BOLD is an old server name but I can't find where it's coming from.

    console> drop-packet-capture 'src host 192.168.6.2'                             
    2019-07-23 23:05:53 0101021 IP  192.168.6.2. > 192.168.2.5. :proto ICMP: echo re
    quest seq 64                                                                    
    0x0000:  4500 003c 316d 0000 7f01 80fc c0a8 0602  E..<1m..........              
    0x0010:  c0a8 0205 0800 4d1b 0001 0040 6162 6364  ......M....@abcd              
    0x0020:  6566 6768 696a 6b6c 6d6e 6f70 7172 7374  efghijklmnopqrst              
    0x0030:  7576 7761 6263 6465 6667 6869            uvwabcdefghi                  
    Date=2019-07-23 Time=23:05:53 log_id=0101021 log_type=Firewall log_component=Fir
    ewall_Rule log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_
    dev=tun0 out_dev=Port1 inzone_id=5 outzone_id=1 source_mac= dest_mac= l3_protoco
    l=IP source_ip=192.168.6.2 dest_ip=192.168.2.5 l4_protocol=ICMP icmp_type=8 icmp
    _code=0 fw_rule_id=0 policytype=2 live_userid=0 userid=0 user_gp=0 ips_id=11 ssl
    vpn_id=1 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dnat_do
    ne=0 proxy_flags=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 category
    _id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node=0 in
    mark=0x0 nfqueue=103 scanflags=88 gateway_offset=0 max_session_bytes=0 drop_fix=
    0 ctflags=134217736 connid=2197914040 masterid=0 status=394 state=0 sent_pkts=N/
    A recv_pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A 
    tran_dst_ip=N/A tran_dst_port=N/A                                               
                                                                                    
    2019-07-23 23:05:53 0101021 IP 192.168.6.2.63762 > 192.168.2.5.53 : proto UDP: p
    acket len: 47 checksum : 46935                                                  
    0x0000:  4500 0043 316e 0000 7f11 80e4 c0a8 0602  E..C1n..........              
    0x0010:  c0a8 0205 f912 0035 002f b757 fd3f 0100  .......5./.W.?..              
    0x0020:  0001 0000 0000 0000 0942 6c61 636b 6269  .........OLDSERVER              
    0x0030:  7264 0b6c 6f63 616c 646f 6d61 696e 0000  NAME.localdomain..              
    0x0040:  0100 01                                  ...                           
    Date=2019-07-23 Time=23:05:53 log_id=0101021 log_type=Firewall log_component=Fir
    ewall_Rule log_subtype=Denied log_status=N/A log_priority=Alert duration=N/A in_
    dev=tun0 out_dev=Port1 inzone_id=5 outzone_id=1 source_mac= dest_mac= l3_protoco
    l=IP source_ip=192.168.6.2 dest_ip=192.168.2.5 l4_protocol=UDP source_port=63762
     dest_port=53 fw_rule_id=0 policytype=0 live_userid=0 userid=0 user_gp=0 ips_id=
    0 sslvpn_id=1 web_filter_id=0 hotspot_id=0 hotspotuser_id=0 hb_src=0 hb_dst=0 dn
    at_done=0 proxy_flags=0 icap_id=0 app_filter_id=0 app_category_id=0 app_id=0 cat
    egory_id=0 bandwidth_id=0 up_classid=0 dn_classid=0 source_nat_id=0 cluster_node
    =0 inmark=0x0 nfqueue=0 scanflags=0 gateway_offset=0 max_session_bytes=0 drop_fi
    x=0 ctflags=0 connid=1841417664 masterid=0 status=256 state=0 sent_pkts=N/A recv
    _pkts=N/A sent_bytes=N/A recv_bytes=N/A tran_src_ip=N/A tran_src_port=N/A tran_d
    st_ip=N/A tran_dst_port=N/A