This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Need help getting SSL VPN Remote Access to PCs on LAN - blocked by Bitdefender Firewall - Solved

PROBLEM:
I would appreciate some help from the community.  I am able to successfully connect an IoS OpenVPN client using the downloaded profile, and am able access the WAN properly through VPN (shows my ip address is within the new VPN network - WAN port as expected).  However, I am unable to ping or get access to LAN devices.  It seems like I am missing something quite simple - I've read through dozens of posts and tried various things but can't seem to get the two subnets to talk to each other.

CONFIGURATION:
My SSL VPN setup that was determined to be working and can be cloned if desired.   Source of network error was Bitdefender Dynamic Firewall on PC, see SOLUTION at bottom:

Sophos XG Mode: Internet Gateway Mode (Route Mode)
Firmware Version: SFOS 17.5.0 GA
Hardware: Qotom Q355G4, i5-5300U, 8GB RAM, 128GB SSD, 4 Intel NICs (Qotom NICs are finally properly order by the way)

Local LAN config: 172.16.16.16 (SophosXG), DHCP lease 172.16.16.17-172.16.16.254 /24(255.255.255.0)

SSL VPN config:

Protocol: UDP
Port: 8443
Lease mode: IPv4 only
IPv4 range 10.81.234.5-10.81.234.55 /24(255.255.255.0)
Policy members: craig (specific user)
Use as default gateway: On (all VPN client traffic including WAN/Internet sent through VPN)
Permitted network resources (IPv4): Local_Subnet (IP host Type:Network, IP address:172.16.16.0, Subnet:/24 (255.255.255.0))

Firewall rules:

Rule Name: VPN to LAN
Description: allow unrestricted traffic between VPN and LAN
Source: VPN & LAN, Any host
Destination: VPN & LAN, Any host
What: Any Service
Action: Accept
Match known users: Off
Rewrite source address: On
Use outbound address: MASQ
Primary Gateway: None

Rule Name(s): LAN/VPN to WAN Rule(s)  (possibly multiple rules - add VPN to all LAN to WAN traffic rules as desired if enabling "Use as default gateway" above)
Source: LAN & VPN, Any host
Destination: WAN, Any host
What: Any Service
Action: Accept
Match known users: Off
Rewrite source address: On
Use outbound address: MASQ
Primary Gateway: WAN link load balance
Web Policy: Default Policy (or other as desired)

STATUS: Solved, see solution post - Bitdefender on PC was blocking.  Needed to make updates to Bitdefender to change default Dynamic Firewall settings which interfere with Sophos XG SSL VPN Remote Access.  

SOLUTION: For those of you with Bitdefender Firewall running on their PCs, I had to do the following to allow external Ping requests to work consistently:
1. Firewall Settings, Network Adapters, set Ethernet NIC to "Home/Office"
2. Firewall Settings, Settings, Edit stealth settings, disable Stealth Mode for Ethernet NIC
3. Firewall Settings, Settings, Edit default rules, change default application behavior to "Allowed" for Ethernet NIC



This thread was automatically locked due to age.
Parents
  • You might have the wrong MTU setting for the VPN connection.  For some reason, you will be able to connect to the VPN but you will have minimal to no access to the LAN or WAN.  In your case, if you don't have the XG set as the "Default Gateway" under "Tunnel Access" for your VPN Policy, you will still have WAN access because you will bypass the XG VPN and use the IOS device to access the internet directly.

    Check the MTU of the OpenVPN client.  You can find this in the log file of the OpenVPN app on your IOS device.  It may give you something like:

    mss-fix-ctrl 1250

    Take that number and add 40 to it and then add the following line to your OpenVPN config file:

    tun-mtu 1290

  • Unfortunately, that didn't seem to work for me.  By default the tun-mtu was set to 1500, but after forcing to 1290, I'm still getting the same symptoms.  Do you have other suggestions?

    OpenVPN log file before change:

    2018-12-15 11:14:09 Frame=512/2048/512 mssfix-ctrl=1250
    2018-12-15 11:13:03 Tunnel Options:V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-client

    OpenVPN log file after change:

    2018-18-15 15:18:26 Frame=512/2048/512 mssfix-ctrl=1250
    2018-18-15 15:18:26 Tunnel Options:V4,dev-type tun,link-mtu 1360,tun-mtu 1290,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-client

Reply
  • Unfortunately, that didn't seem to work for me.  By default the tun-mtu was set to 1500, but after forcing to 1290, I'm still getting the same symptoms.  Do you have other suggestions?

    OpenVPN log file before change:

    2018-12-15 11:14:09 Frame=512/2048/512 mssfix-ctrl=1250
    2018-12-15 11:13:03 Tunnel Options:V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-client

    OpenVPN log file after change:

    2018-18-15 15:18:26 Frame=512/2048/512 mssfix-ctrl=1250
    2018-18-15 15:18:26 Tunnel Options:V4,dev-type tun,link-mtu 1360,tun-mtu 1290,proto UDPv4,comp-lzo,cipher AES-128-CBC,auth SHA256,keysize 128,key-method 2,tls-client

Children
  • So, I seem to be zeroed in on the problem further but I need help with a subnet connectivity issue:

    In re-verifying the recommended troubleshooting steps for SSL VPN Remote Access at https://community.sophos.com/kb/en-us/127189, the following step appears to be my problem:

    Verify the resources accessibility

    Login to the command line interface (CLI) and select  4. Device Console. Verify that the internal allowed resource is accessible from the Sophos XG Firewall itself. As an example, you can ping an internal resource from the Sophos XG Firewall's console. If the allowed resources are not accessible from the Sophos XG Firewall, then they would not be accessible from the WAN side.

    When I go to the console, I can't ping a local PC on my LAN despite being able to ping the Sophos XG gateway itself in the same subnet:

    console> ping 172.16.16.16                                                      
    PING 172.16.16.16 (172.16.16.16): 56 data bytes                                 
    64 bytes from 172.16.16.16: seq=0 ttl=64 time=0.054 ms                          
    64 bytes from 172.16.16.16: seq=1 ttl=64 time=0.032 ms                          
    ??^C                                                                            
    --- 172.16.16.16 ping statistics ---                                            
    2 packets transmitted, 2 packets received, 0% packet loss                       
    round-trip min/avg/max = 0.032/0.043/0.054 ms                                   
    console> ping 172.16.16.102                                                     
    PING 172.16.16.102 (172.16.16.102): 56 data bytes                               
    ??^C                                                                            
    --- 172.16.16.102 ping statistics ---                                           
    14 packets transmitted, 0 packets received, 100% packet loss                    
    console> 
        

    Oddly, when I ping in the reverse direction from the PC at 172.16.16.102, I can ping both devices:

    C:\>ping 172.16.16.16

    Pinging 172.16.16.16 with 32 bytes of data:
    Reply from 172.16.16.16: bytes=32 time<1ms TTL=64
    Reply from 172.16.16.16: bytes=32 time<1ms TTL=64

    Ping statistics for 172.16.16.16:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

    C:\>ping 172.16.16.102

    Pinging 172.16.16.102 with 32 bytes of data:
    Reply from 172.16.16.102: bytes=32 time<1ms TTL=128
    Reply from 172.16.16.102: bytes=32 time<1ms TTL=128

    Ping statistics for 172.16.16.102:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

    So, there appears to be an underlying problem with my routing tables between the LAN and the Sophos XG that I can't figure out how to address. Can someone suggest a fix to get the Sophos XG to see PCs/devices on my LAN from the console (which should also help my VPN also to see them)?

     
  • Try to perform a Tcpdump on the XG to verify the traffic.

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

    You should see the correct interface outgoing. If XG uses the correct IP and interface, This should be an network/Client issue, not XG issue. 

    __________________________________________________________________________________________________________________

  • Ok, I'm seeing the following tcpdumps when pinging from to the LAN PC.   The SSL VPN is still not working, but after disabling Bitdefender on the LAN PC, at least Sophos XG applicance can finally ping the LAN PC.

    Case 1 - ping LAN PC (172.16.16.102) from SSL VPN Remote Access Client (10.81.234.7) - still not working, 100% packet loss

    13:09:24.725884 tun0, IN: IP 10.81.234.7 > 172.16.16.102: ICMP echo request, id 30840, seq 30840, length 64                                                     
    13:09:24.725942 Port1, OUT: IP 10.81.234.7 > 172.16.16.102: ICMP echo request, id 30840, seq 30840, length 64     

    Case 2 - ping LAN PC (172.16.16.102) from Sophos XG Appliance (172.16.16.16) - working no packet loss (after disabling Bitdefender Firewall on LAN PC)

    13:15:52.541910 Port1, OUT: IP 172.16.16.16 > 172.16.16.102: ICMP echo request, id 40751, seq 0, length 64                                                      
    13:15:52.542343 Port1, IN: IP 172.16.16.102 > 172.16.16.16: ICMP echo reply, id 40751, seq 0, length 64                                                         

    It looks like the response from 172.16.16.102 (the LAN PC) in case 1 is blocked or never received back at the Sophos XG Appliance.  Do you guys see anything wrong with the addressing in the first tcpdump?  I'm wondering if I need to further play with NAT translation or network masking and subnet IDs to get the 10.81.234.X subnet to talk to the 172.16.16.X subnet.

  • Ok, finally solved thanks to the recommendation to use tcpdump (thanks LuCar Toni!).  It turns out that my final issue was indeed the Bitdefender Firewall running on the PC was blocking my SSL VPN remote access ping traffic.  After turning Bitdefender off and re-enabling the NAT masquerading (which I had accidentially turned off while trying all sort of different combinations), the SSL VPN remote access is now fully working and pings and other traffic are fully flowing.

    Ping from SSL VPN after re-enabling NAT translation -- this looks much better:

    13:37:54.808791 tun0, IN: IP 10.81.234.7 > 172.16.16.102: ICMP echo request, id 30840, seq 30840, length 64                                                     
    13:37:54.808853 Port1, OUT: IP 172.16.16.16 > 172.16.16.102: ICMP echo request, id 30840, seq 30840, length 64                                                  
    13:37:54.809288 Port1, IN: IP 172.16.16.102 > 172.16.16.16: ICMP echo reply, id 30840, seq 30840, length 64                                                     
    13:37:54.809312 tun0, OUT: IP 172.16.16.102 > 10.81.234.7: ICMP echo reply, id 30840, seq 30840, length 64                                                      

    So, the real root cause of all my torment was the Bitdefender Firewall on my PC was blocking my traffic.  All of my various attempts to fix at the Sophos XG firewall level were days of wasted energy -- it was likely working properly all along.  Thanks for the helpful hints to push me in the right direction to find the culprit using tcpdump.

    For those of you with Bitdefender Firewall running on their PCs, I had to do the following to allow external Ping requests to work consistently:
    1. Firewall Settings, Network Adapters, set Ethernet NIC to "Home/Office"
    2. Firewall Settings, Settings, Edit stealth settings, disable Stealth Mode for Ethernet NIC
    3. Firewall Settings, Settings, Edit default rules, change default application behavior to "Allowed" for Ethernet NIC