Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 17 replies
  • Answers 2 answers
  • Subscribers 27 subscribers
  • Views 3575 views
  • Users 0 members are here
Options
Suggested
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 CLIENT CANT ABLE TO PING OR ACCESS REMOTE NETWORK

RENJITH NAIR

Dear All

My selft RENJITH  , System supports at  contracting Recently we implemented sophos XG125 (SFOS 18.0.3 MR-3) on our hotel. I configured sophos connect client in order to access the hotel internal network and our PMS network from our head office. I can  connect the sophos connect client without any issue but after connecting i cant able to ping or access my hotel internal network from my head office.

The hotel internal network on LAN Zone VLAN4.100 192.168.1.0/24 on Port#4

Hotel PMS network on SERVER Zone 10.0.0.1/255.255.255.224 on Port#3

I have attached the screen shots please verify and please support me to solve the issue

10.90.90.65/255.255.255.192 managment ip on Port#4 LAN ZONE

All vlans under Port#4

192.168.1.0/24 Coperate VLAN4.100 ON port#4 LAN Zone

192.168.1.202 Host device in coperate vlan (fingertech device)

10.0.0.1/255.255.255.224 SERVER ZONE Interface ip

10.0.0.2/255.255.255.224 PMS FIDELIO SERVER

I need to connect managment, coperate vlan and server zone

Thank You

RENJITH.K




This thread was automatically locked due to age.
Parents
  • 0

    So: VPN to LAN and VPN to WAN works? 

    Only VPN to Server does not work? 

    The indication seems like, the XG is doing its job, but nobody is replying to the Packets. 

    Would recommend to try to NAT the traffic to Server and see, if this resolve your issue. Create a NAT Rule, Source Network your VPN IP Network (10.81.234.0/24) and going to your Server Network. Then choose Translate Source IP to "MASQ". 

  • 0 in reply to LuCar Toni

    VPN TO WAN  is working

    VPN to Server Zone and Lan zone not working.

    I changed the network id of Sophos connect client 10.81.234.0/24 to 192.168.100.0/24 to avoid the overlapping from ssl vpn range . But the problem remain same no change.

    The indication seems like, the XG is doing its job, but nobody is replying to the Packets.  Yes i can connect the remote network also am getting dhcp ip form sophos connect client dhcp lease range . But i can ping to any of network inside remote site.

    But i can able to ping remote site sophos xg firewall wan ip Port#1 (192.168.2.101/24) from my branch by using sophos connect client

    no error showing but getting timeout for server zone interface ip and Fidelio internal server (10.0.0.2 icmp showing allowed) I dont understand to where these packet is going

    Bellow image Ping from Sophos connect client to remote Sophos WAN IP

    I can access Mobily ISP modem

    Tunnel i full tunnel any network

  • 0 in reply to RENJITH NAIR

    Hello Renjith,

    Thank you for contacting the Sophos Community!

    As Luca mentioned, try NATting the traffic as it comes into the XG from the Sophos Connect Client. 

    Take a look at this Recommended Read

    Also, I would recommend to install Wireshark in one of the Computers that you are trying to Ping, to check for incoming packets, and also disable the destination's computer Firewall.

    Regards,

  • 0 in reply to emmosophos

    Hello Emmanuel

    Thank you for your instructions

    As per Lucar i created linked nat rule as bellow

    The issue seems same....Can you check the rules in screen shot need any specific changes, I did the same configuration with XG V17 it was working perfect but i faced the issues in xg v18. 

    Also my local firewalls i disabled in my server, even i cant ping my fingertech device inside remote network 

    I will try to install Wireshark on my source network side, i will let you know the output

  • 0 in reply to RENJITH NAIR

    Hello Renjith,

    So the original Source should be the subnet of the Sophos Connect Client.

    The outbound interface should be the Port where the end device is located.

    Regards,

  • 0 in reply to emmosophos

    I make the change as per your instruction, But the output is same icmp time out . if you dont mind i can give you teamviewer or anydesk can you check once ?

  • 0 in reply to RENJITH NAIR

    Hello Renjith,

    Thank you for the follow-up!

    If you require a remote session, please open a case with Support or give a call so you can have a remote session.

    As per the screenshots though I can't see the rules being hit, or maybe you just took the screenshot before testing?

    Regards,

  • 0 in reply to emmosophos

    Hi Emmanuel The above screen shot for icmp packet from the source computer where i installed the sophos connect client Then i make ping to my remote gate way ip and remote internal network. The remote gateway is 192.168.2.0 and Remote internal network is 10.0.0.0

    From remote network showing no response

  • 0 in reply to RENJITH NAIR

    Hello,

    Thank you for the screenshots!

    You should try installing Wireshark on the 10.0.0.2 computer!

    Most likely you will see the Ping gets there but it is not replying to them.

    Regards,

  • 0 in reply to emmosophos

    Bellow captures from 10.90.90.87 PC on LAN#1 PORT  I used this host for testing instead of 10.0.0.2 since all the internal network having same issue 

    I initiate ping command to 192.168.100.5 Sophos connect adapter situated in office

     

    console> tcdump 'dst host 192.168.100.5'
    % Error: Unknown Parameter 'tcdump'
    console> tcpdump 'dst host 192.168.100.5'
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 byt
    es
    10:12:32.092384 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1661, length 40
    10:12:32.092427 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1661, length 40
    10:12:34.053739 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1231, length 40
    10:12:34.053920 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1231, length 40
    10:12:37.092387 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1662, length 40
    10:12:37.092428 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1662, length 40
    10:12:39.053091 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1232, length 40
    10:12:39.053227 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1232, length 40
    10:12:42.091116 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1663, length 40
    10:12:42.091222 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1663, length 40
    10:12:44.054479 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1233, length 40
    10:12:44.054659 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1233, length 40
    10:12:47.093680 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1664, length 40
    10:12:47.093958 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1664, length 40
    10:12:49.053826 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1234, length 40
    10:12:49.054169 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1234, length 40
    ??^C
    16 packets captured
    19 packets received by filter
    0 packets dropped by kernel

    console> tcpdump 'proto icmp'
    tcpdump: can't parse filter expression: syntax error
    console> tcpdump 'proto ICMP'
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 byt
    es
    10:05:05.562638 ipsec0, IN: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1573, length 40
    10:05:05.562734 Port4, OUT: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1573, length 40
    10:05:05.563087 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1573, length 40
    10:05:05.563133 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1573, length 40
    10:05:06.045736 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1198, length 40
    10:05:06.045952 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1198, length 40
    10:05:10.564248 ipsec0, IN: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1574, length 40
    10:05:10.564319 Port4, OUT: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1574, length 40
    10:05:10.564673 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1574, length 40
    10:05:10.564714 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1574, length 40
    10:05:11.047080 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1199, length 40
    10:05:11.047267 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1199, length 40
    10:05:15.562949 ipsec0, IN: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1575, length 40
    10:05:15.563024 Port4, OUT: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1575, length 40
    10:05:15.563381 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id 1
    , seq 1575, length 40
    10:05:15.563505 Port1, OUT: IP 10.90.90.87 > 192.168.100.5: ICMP echo reply, id
    1, seq 1575, length 40
    10:05:16.046567 Port4, IN: IP 10.90.90.87 > 192.168.100.5: ICMP echo request, id
    1, seq 1200, length 40
    10:05:16.046708 Port1, OUT: IP 192.168.2.101 > 192.168.100.5: ICMP echo request,
    id 1, seq 1200, length 40
    ??^C
    18 packets captured
    18 packets received by filter
    0 packets dropped by kernel
    console>

    console> tcpdump 'src host 192.168.100.5'
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 byt
    es
    10:08:11.108037 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 689134653:689134805, ack 680967969, win 256, length 152: HTTP
    10:08:11.108065 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 152:627, ack 1, win 256, length 475: HTTP
    10:08:11.450015 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 627:668, ack 1, win 256, length 41: HTTP
    10:08:11.494011 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 668:709, ack 1, win 256, length 41: HTTP
    10:08:11.673048 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 709:780, ack 1, win 256, length 71: HTTP
    10:08:12.074037 ipsec0, IN: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1609, length 40
    10:08:12.074182 Port4, OUT: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1609, length 40
    10:08:12.201034 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 780:851, ack 1, win 256, length 71: HTTP
    10:08:12.734082 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 851:922, ack 1, win 256, length 71: HTTP
    10:08:13.120070 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 922:963, ack 1, win 256, length 41: HTTP
    10:08:13.164050 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 963:1004, ack 1, win 256, length 41: HTTP
    10:08:13.267053 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1004:1075, ack 1, win 256, length 71: HTTP
    10:08:13.648101 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1075:1116, ack 1, win 256, length 41: HTTP
    10:08:13.690099 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1116:1157, ack 1, win 256, length 41: HTTP
    10:08:13.735110 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1157:1198, ack 1, win 256, length 41: HTTP
    10:08:13.780114 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1198:1239, ack 1, win 256, length 41: HTTP
    10:08:13.796089 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1239:1310, ack 1, win 256, length 71: HTTP
    10:08:14.222108 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1310:1351, ack 1, win 256, length 41: HTTP
    10:08:14.266112 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1351:1392, ack 1, win 256, length 41: HTTP
    10:08:14.324101 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1392:1463, ack 1, win 256, length 71: HTTP
    10:08:14.857129 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1463:1534, ack 1, win 256, length 71: HTTP
    10:08:15.379155 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1534:1605, ack 1, win 256, length 71: HTTP
    10:08:15.919659 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1605:1676, ack 1, win 256, length 71: HTTP
    10:08:16.102704 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1676:1964, ack 1, win 256, length 288: HTTP
    10:08:16.102741 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 1964:2309, ack 1, win 256, length 345: HTTP
    10:08:16.424794 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2309:2350, ack 1, win 256, length 41: HTTP
    10:08:16.468686 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2350:2391, ack 1, win 256, length 41: HTTP
    10:08:16.598695 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2391:2432, ack 1, win 256, length 41: HTTP
    10:08:16.642667 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2432:2473, ack 1, win 256, length 41: HTTP
    10:08:16.986695 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2473:2544, ack 1, win 256, length 71: HTTP
    10:08:17.073677 ipsec0, IN: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1610, length 40
    10:08:17.073962 Port4, OUT: IP 192.168.100.5 > 10.90.90.87: ICMP echo request, i
    d 1, seq 1610, length 40
    10:08:17.515706 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2544:2615, ack 1, win 256, length 71: HTTP
    10:08:17.962745 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2615:2656, ack 1, win 256, length 41: HTTP
    10:08:18.045751 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2656:2727, ack 1, win 256, length 71: HTTP
    10:08:18.051698 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2727:2768, ack 1, win 256, length 41: HTTP
    10:08:18.574827 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2768:2839, ack 1, win 256, length 71: HTTP
    10:08:19.110783 ipsec0, IN: IP 192.168.100.5.51943 > 51.178.65.231.80: Flags [P.
    ], seq 2839:2910, ack 1, win 256, length 71: HTTP
    10:08:19.198755 ipsec0, IN: IP 192.168.100.5.54987 > 192.168.1.44.161: GetReque
    st(63) .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.
    1.2.1

    Bellow capture From Connect client adaptor 192.168.100.5 to remote destination 10.90.90.87

  • 0 in reply to RENJITH NAIR

    Hello Renjith,

    Thank you for the tcpdumps.

    I do see the packets Request and Reply.

    I would recommend you to open a case with support to get this check so they can check live with you!

    I see the packets from 192.168.100.5 are going out Port4 but this should go out Port1.

    If you start the capture from the SSL VPN client 192.168.100.5 and listen in Wireshark on the computer 10.90.90.87, you don't see anything in there, right?

    Regards,

Reply
  • 0 in reply to RENJITH NAIR

    Hello Renjith,

    Thank you for the tcpdumps.

    I do see the packets Request and Reply.

    I would recommend you to open a case with support to get this check so they can check live with you!

    I see the packets from 192.168.100.5 are going out Port4 but this should go out Port1.

    If you start the capture from the SSL VPN client 192.168.100.5 and listen in Wireshark on the computer 10.90.90.87, you don't see anything in there, right?

    Regards,

Children