Guest User!

You are not Sophos Staff.

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

Cannot ping the other side of the VPN from SOPHOS Box on the server side of the VPN

Hello all,

This is a very interesting issue. 

Several weeks ago, I was having a hard time setting up a VPN site-to-site using UTM 9. You can see my odyssey here

Long story short, I found out that you cannot ping from the server side of the vpn to the client side of the VPN from the UTM 9 box. It works from the server side of the VPN 

Well...at the time I found out the problem - with much appreciated help from this forum, and a friend that is a SOPHOS partner - I thought: nobody will want to ping the other side of the vpn from the UTM box. Well...it turned out I was wrong. 

Little diagram:

Branch Office >>>> VPN >>>>> Headquarters
Server Side of the VPN            Client side of the VPN
192.168.150.0                        192.168.0.0

I need to configure SOPHOS UTM on the branch office, to authenticate against a Active Directory server that resides on the headquarters. I tried configuring it under Users and Definitions/Authentication Servers and got a timeout.  Then, I had the "brilliant" idea to ping the AD(that resides on the headquarter) from the branch office UTM using the webadmin ping tool. No love! I cannot establish any sort of communication with computers behind the headquarters UTM. However, I can ping fine from any computer that is behind the branch office UTM.

I know I can create a NAT on the headquarter UTM pointing to my AD server. However, I want to avoid this option at any cost. 

What I checked out: 

No Packages Blocked on the firewall
No blocks on the webfilter(it doesn't make sense but, I checked anyways)
No Packages Blocked on the IPS
All these options are enabled at NetWork Protection/Firewall/ICMP for both UTM boxes.

Global ICMP settings

Allow ICMP on Gateway
Allow ICMP through Gateway

Ping settings

Gateway is Ping visible
Ping from Gateway
Gateway forwards Pings


This thread was automatically locked due to age.
  • Hi,

    Adding the firewall's Internal Address to the VPN networks might help, but first, could you post the (full log) packetfilter log entries for the blocked pings?

    Barry
  • Hey Barry,

    I don't think it is a matter of blocked packages as the firewall log does not show ANYTHING. I assume the traffic is passing, as I enabled the "Automatic Firewall Rules" on both sides of the VPN.

    -Eduardo
  • Hmm... try turning off Strict Routing on the VPN settings.

    Barry
  • Isn't strict VPN for Ipsec vpns? I am using SSL.
  • This sounds like a routing problem.  Check to be sure that none of the Host/Network definitions you've created is bound to a specific interface - all definitions you create must have 'Interface: >'.

    Cheers- Bob
  • Hey Mr Bob,

    I already checked that. As a matter of fact, I checked all the recommendations you made here. I think I have all the bases covered here, thanks to you. [:)]

    If it is a routing issue, then I think that the machines behind UTM9 wouldn't work either.
  • I suppose it could be the Spoof Protection that's blocking; that should show in the IPS log or the PacketFilter log though.

    Barry
  • First of all, I changed the topic of this thread as this problem is not specific to the ICMP protocol. 

    IPS is off on both locations for the sake of troubleshooting. I still don't see any blocked package on both UTMs related to the networks/ips I am using.

    Enclosed, a pic I took pinging both sides. The server which ping is responding is the Client side of the VPN. I have the same problem if I try to ping from a SSH shell. 


    I tried a different method of testing this time, I tried telneting from the server side of the VPN to the client side. The server I am trying to reach is 192.168.0.250.

    /home/login > telnet 192.168.0.250 80
    Trying 192.168.0.250...
    telnet: connect to address 192.168.0.250: Connection timed out


    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on tun0, link-type RAW (Raw IP), capture size 96 bytes
    23:07:18.437702 IP 10.242.2.1.35657 > 192.168.0.250.http: S 2785552347:2785552347(0) win 14600 
    23:07:19.433901 IP 10.242.2.1.35657 > 192.168.0.250.http: S 2785552347:2785552347(0) win 14600 
    23:07:21.437900 IP 10.242.2.1.35657 > 192.168.0.250.http: S 2785552347:2785552347(0) win 14600 
    23:07:25.445902 IP 10.242.2.1.35657 > 192.168.0.250.http: S 2785552347:2785552347(0) win 14600 
    23:07:27.351166 IP 192.168.0.58.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]
    23:07:30.349905 IP 10.242.2.1 > 192.168.0.58: ICMP host 192.168.150.245 unreachable, length 114
    23:07:33.461903 IP 10.242.2.1.35657 > 192.168.0.250.http: S 2785552347:2785552347(0) win 14600 
    23:07:37.357087 IP 192.168.0.58.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]
    23:07:40.353901 IP 10.242.2.1 > 192.168.0.58: ICMP host 192.168.150.245 unreachable, length 114
    23:07:47.357598 IP 192.168.0.58.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]
    23:07:49.509905 IP 10.242.2.1.35657 > 192.168.0.250.http: S 2785552347:2785552347(0) win 14600 
    23:07:50.353904 IP 10.242.2.1 > 192.168.0.58: ICMP host 192.168.150.245 unreachable, length 114
    23:08:27.352428 IP 192.168.0.58.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]
    23:08:30.349906 IP 10.242.2.1 > 192.168.0.58: ICMP host 192.168.150.245 unreachable, length 114
    23:08:37.358556 IP 192.168.0.58.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]
    23:08:40.357909 IP 10.242.2.1 > 192.168.0.58: ICMP host 192.168.150.245 unreachable, length 114
  • I think I made some progress. 

    When I ping, it does not show anything on the firewall log. When I use telnet to connect to an open port, it actually shows packets being blocked on the firewall log.  I am telneting from the server side of the vpn to a box that is behind the client side of the vpn. This is what the firewall log shows on the client side of the VPN.

    01:46:00  DROP padrão  TCP  10.242.2.1  :  35853 →  192.168.0.250  :  80
    [SYN]  len=60  ttl=63  tos=0x10  srcmac=70:71:bc:66:ab:be
    01:46:00  DROP padrão  TCP  10.242.2.1  :  35853 →  192.168.0.250  :  80
    [SYN]  len=60  ttl=63  tos=0x10  srcmac=70:71:bc:66:ab:be
    01:46:03  DROP padrão  TCP  10.242.2.1  :  35853 →  192.168.0.250  :  80
    [SYN]  len=60  ttl=63  tos=0x10  srcmac=70:71:bc:66:ab:be


    I created a rule, on the client side of the VPN, to allow any packages from the SSL VPN Pool - networks 10.242.2.0 - going to 192.168.0.0. The packages are not being blocked anymore, however, telnet times out. 


    I collected a trace with tcpdump while I was telneting - remember, I am telneting from server side of the VPN and collecting tcpdump on the client side of it - and I can see that the three way handshake never happens. Only ACKS are sent.  SRVAD01.novaprestech.int is the server I am trying to reach. 

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on tun1, link-type RAW (Raw IP), capture size 96 bytes
    01:55:23.189459 IP 10.242.2.1.35917 > srvad01.novaprestech.int.http: S 1223329437:1223329437(0) win 14600 
    01:55:24.184149 IP 10.242.2.1.35917 > srvad01.novaprestech.int.http: S 1223329437:1223329437(0) win 14600 
    01:55:26.188903 IP 10.242.2.1.35917 > srvad01.novaprestech.int.http: S 1223329437:1223329437(0) win 14600 
    01:55:27.323317 IP suporte01.novaprestech.int.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]
    01:55:30.192636 IP 10.242.2.1.35917 > srvad01.novaprestech.int.http: S 1223329437:1223329437(0) win 14600 
    01:55:30.381382 IP 10.242.2.1 > suporte01.novaprestech.int: ICMP host 192.168.150.245 unreachable, length 114
    01:55:38.208440 IP 10.242.2.1.35917 > srvad01.novaprestech.int.http: S 1223329437:1223329437(0) win 14600 
    01:55:38.328931 IP suporte01.novaprestech.int.49154 > 192.168.150.245.snmp:  GetRequest(63)  25.3.2.1.5.1 [|snmp]