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

Sophos Connect blocks SNMP

After establishing the connection between XG Firewall version 17.5.1 MR1 through Sophos Connect, communication from the server installed behind the router to port udp/161 on the remote computer is impossible. Changing the VPN client to another one, for example to the Cyberoam VPN SSL or SecurePoint SLL VPN causes the immediate return of communication via udp. For all three tests this remote computer received IP from the same subnet and snmpwalk from the same server was used. Could this be a Sophos Connect error?



This thread was automatically locked due to age.
Parents
  • Hello Michal,

     

    Without additional information it is hard to pinpoint the exact cause of the problem you are having with Sophos Connect Client. What is the policy configuration? It is a tunnel all policy or a split tunnel policy? If it is a split tunnel policy check if the destination network includes the network where the server is located. There is nothing in Sophos Connect that will specifically block communication via UDP/161. 

     

    Please let me know

     

    Ramesh

  • Thank you for your response. This is tunnel policy with full access to all private addresses behind the router.

    {
    "name": "IT",
    "managed": false,
    "version": 1,
    "gateway": "a.b.c.d",
    "vip": "0.0.0.0",
    "auto_connect": {
    "name": "10.77.77.254",
    "required": false,
    "enabled": true
    },
    "proposals": "aes256-sha2_256-modp1024",
    "dpd_delay": 60,
    "rekey_time": 15300,
    "start_action": "none",
    "local_auth": {
    "psk": {
    "id": "0.0.0.0"
    },
    "xauth": {
    "can_save": true
    },
    "otp": false
    },
    "remote_auth": {
    "psk": {
    "id": "%any",
    "secret": "efgh"
    },
    "otp": false
    },
    "child": {
    "rekey_time": 3060,
    "remote_ts": [
    "10.0.0.0/8",
    "172.16.0.0/12",
    "192.168.0.0/17",
    "52.5.76.173/32"
    ]
    }
    }

     

    However, it looks like the problem lies somewhere else. After establishing VPN tunnel through Sophos Connect, I get unexpectedly such a gate: 169.254.128.128.


    IPv4 Route Table
    ===========================================================================
    Active Routes:
    Network Destination Netmask Gateway Interface Metric
    0.0.0.0 0.0.0.0 192.168.178.1 192.168.178.222 25
    10.0.0.0 255.0.0.0 169.254.128.128 10.0.101.200 45
    10.0.101.200 255.255.255.255 On-link 10.0.101.200 291
    52.5.76.173 255.255.255.255 169.254.128.128 10.0.101.200 45
    127.0.0.0 255.0.0.0 On-link 127.0.0.1 331
    127.0.0.1 255.255.255.255 On-link 127.0.0.1 331
    127.255.255.255 255.255.255.255 On-link 127.0.0.1 331
    172.16.0.0 255.240.0.0 169.254.128.128 10.0.101.200 45
    192.168.0.0 255.255.128.0 169.254.128.128 10.0.101.200 45
    192.168.137.0 255.255.255.0 On-link 192.168.137.1 311
    192.168.137.1 255.255.255.255 On-link 192.168.137.1 311
    192.168.137.255 255.255.255.255 On-link 192.168.137.1 311
    192.168.178.0 255.255.255.0 On-link 192.168.178.222 281
    192.168.178.222 255.255.255.255 On-link 192.168.178.222 281
    192.168.178.255 255.255.255.255 On-link 192.168.178.222 281
    224.0.0.0 240.0.0.0 On-link 127.0.0.1 331
    224.0.0.0 240.0.0.0 On-link 192.168.178.222 281
    224.0.0.0 240.0.0.0 On-link 192.168.137.1 311
    224.0.0.0 240.0.0.0 On-link 10.0.101.200 291
    255.255.255.255 255.255.255.255 On-link 127.0.0.1 331
    255.255.255.255 255.255.255.255 On-link 192.168.178.222 281
    255.255.255.255 255.255.255.255 On-link 192.168.137.1 311
    255.255.255.255 255.255.255.255 On-link 10.0.101.200 291
    ===========================================================================

     

    Meanwhile, all interfaces on the router have either a fixed IP address or are disabled. I do not have any virtual interfaces or bridges configured. So from where did the VPN server pick up such address? From which router interface?

     

     

  • Hello Michal,

    It is possible you have a very restrictive firewall rule that could be blocking traffic to UDP/161. Please check the logs on the firewall and/or capture packets on the firewall destined for the SNMP server. That will help to narrow down the problem you are having.

    Ramesh

  • Thank you again. We have two WAN gates, the main and the reserve one. Both have a fixed IP address.

     

     

    Before asking questions on the group, I checked the firewall's settings and logs several times and all the snmp traffic is passed both ways. The problem is the strange gate that appeared on the client. In the case of normal SSL connection, the gateway address is the VPN server address on the router, that's why the communication works. But in the case of Sophos Connect the gateway is the address going nowhere and the packets do not return to the router anymore.
    I would like to determine where this address comes from. Is it possible to look through ssh in the configuration files of the Sophos Connect server on the router?

  • You wrote: "You will find the defined gateway from this attribute "gateway": in the policy"

    The gateway address in policy is exactly same as the address of our main WAN gateway. In the configuration I have pasted, I replaced it with a.b.c.d.

  • Michal,

     

    The address you have specified  169.254.128.128 is not a routable address. So the first question is when you enable the connection in Sophos Connect, is the connection getting established? Based on the route table you have attached to the post it does look like it is established. Can you then do a ping test and confirm you are able to get bidirectional traffic going thru the tunnel. But then the IP  as seen in the route table is non-routable. So something is missing here which I cannot figure out without additional details. Let me know the answers to above and then we can go to the next step

    Ramesh

  • Hello Michal,

     

    There is one other thing that I think is the problem is due to. Probably in your case you are not getting a Virtual IP and as a result a non-routable IP address is getting assigned to the remote networks. That is the problem. If you open the Open VPN logs, you can search the logs for Virtual and see if there are errors there. 

    Ramesh

  • Yes, the tunnel is set up correctly and I am getting correct IP address 10.0.101.200. This address is from the 10.0.101.0/24 subnet configured in the Sophos Connect settings on the router.

    Yes, I can communicate with LAN addresses behind the router:
    c: \> pathping -n 10.77.77.254
    Tracing route is 10.77.77.254 over a maximum of 30 hops
       0 10.0.101.200
       1 10.0.101.100
       2 10.77.77.254
    Computing statistics for 50 seconds ...
    ? C

    The router sees the remote host on the tun0 interface and can ping it. However, for devices that are in the LAN behind the router, the host is unavailable.

     

     

     

    I know that this is a non-routable APIPA address, but communication with the router and other devices behind it works.
    On the screens I hav pasted you can see all the addresses both on the router and on the remote host. Below I will also add the routing table copied from the router.

     

  • Hello Michal,

     

    Can you please check the firewall rule and check if traffic is allowed from VPN to LAN and then you can do a packet capture on the firewall to see if the firewall is dropping or allowing this packet on the LAN.

     

    Ramesh

  • I have created the very first rule "allow all to 10.0.101.0/24 subnet":

     

    Summary
    sc
    Allow
    Rule
    Accept any service going to "VPN" zone, when in any zone, and coming from any network, then apply log connections

    Source & schedule
    Any
    Source networks and devices : Any
    During scheduled time : All the time

    Destination & services
    VPN
    Destination networks : VLAN 101 ssl vpn
    Services : Any

    Advanced
    Synchronized security
    Source : Minimum heartbeat is No restriction, Clients with no heartbeat allowed
    Destination : Minimum heartbeat is No restriction, Request to destination with no heartbeat allowed

    Masquerading is OFF

     

    1. This is a packet capture screen with ICMP test from machine 10.77.77.8 behind the router to remote host 10.0.101.200:

     

     

    First packet:

    Ethernet header
    Source MAC address:bc:16:65:df:e8:c9
    Destination MAC address: 00:02:b6:43:4b:9b
    Ethernet type IPv4 (0x800)
     
    IPv4 Header
    Source IP address:10.77.77.8
    Destination IP address:10.0.101.200
    Protocol: ICMP
    Header:20 Bytes
    Type of service: 0
    Total length: 60 Bytes
    Identification:1356
    Fragment offset:0
    Time to live: 126
    Checksum: 28760
     
    ICMP Header:
    Type: 8
    Code: 0
    Echo ID: 5
    Echo sequence: 26141
    Gateway: 0
    Fragmentation MTU: 0
    Checksum: 59193

     

    Second packet:

     

    Ethernet header
    Source MAC address:bc:16:65:df:e8:c9
    Destination MAC address: 00:02:b6:43:4b:9b
    Ethernet type IPv4 (0x800)
     
    IPv4 Header
    Source IP address:10.77.77.8
    Destination IP address:10.0.101.200
    Protocol: ICMP
    Header:20 Bytes
    Type of service: 0
    Total length: 60 Bytes
    Identification:1356
    Fragment offset:0
    Time to live: 127
    Checksum: 28504
     
    ICMP Header:
    Type: 8
    Code: 0
    Echo ID: 5
    Echo sequence: 26141
    Gateway: 0
    Fragmentation MTU: 0
    Checksum: 59193

     

    2. Another test - ping address 10.0.101.200 directly from the router:

     

    First packet:

    Ethernet header
    Source MAC address:
    Destination MAC address:
    Ethernet type IPv4 (0x800)
     
    IPv4 Header
    Source IP address:10.0.101.100
    Destination IP address:10.0.101.200
    Protocol: ICMP
    Header:20 Bytes
    Type of service: 0
    Total length: 84 Bytes
    Identification:52891
    Fragment offset:16384
    Time to live: 64
    Checksum: 36065
     
    ICMP Header:
    Type: 8
    Code: 0
    Echo ID: 56847
    Echo sequence: 1
    Gateway: 0
    Fragmentation MTU: 0
    Checksum: 20276

     

    Second packet:

    Ethernet header
    Source MAC address:
    Destination MAC address:
    Ethernet type IPv4 (0x800)
     
    IPv4 Header
    Source IP address:10.0.101.100
    Destination IP address:10.0.101.200
    Protocol: ICMP
    Header:20 Bytes
    Type of service: 0
    Total length: 84 Bytes
    Identification:52808
    Fragment offset:16384
    Time to live: 64
    Checksum: 36148
     
    ICMP Header:
    Type: 8
    Code: 0
    Echo ID: 56847
    Echo sequence: 0
    Gateway: 0
    Fragmentation MTU: 0
    Checksum: 53396
  • Maybe a more interesting test will be the other way around, from the remote host 10.0.101.200 to devices in the LAN behind the router.

  • Hello Michal,

     

    I setup a VPN tunnel from my Sophos Connect Client to XG. I start a PING from my Sophos Connect Client (Virtual IP: 10.0.3.77) to a LAN host 10.1.1.11. I setup a packet capture with a host 10.0.3.77

     

     

    You should see 4 packets as you seen in my capture. Incoming IPsec packet from 10.0.3.77 to 10.1.1.11. This packet is now forwarded on Port A to destination host 10.1.1.11. The host response is received on Port A, which is then forwarded to 10.0.3.77 on the VPN tunnel.

     

    In your capture I only see the received packet from the IPsec tunnel that is forwarded out. There is nothing coming back. So please check the default route on the host to make sure the packet is correctly forwarded back to the XG firewall.

    Please let me know.

    Ramesh

     

Reply
  • Hello Michal,

     

    I setup a VPN tunnel from my Sophos Connect Client to XG. I start a PING from my Sophos Connect Client (Virtual IP: 10.0.3.77) to a LAN host 10.1.1.11. I setup a packet capture with a host 10.0.3.77

     

     

    You should see 4 packets as you seen in my capture. Incoming IPsec packet from 10.0.3.77 to 10.1.1.11. This packet is now forwarded on Port A to destination host 10.1.1.11. The host response is received on Port A, which is then forwarded to 10.0.3.77 on the VPN tunnel.

     

    In your capture I only see the received packet from the IPsec tunnel that is forwarded out. There is nothing coming back. So please check the default route on the host to make sure the packet is correctly forwarded back to the XG firewall.

    Please let me know.

    Ramesh

     

Children