Communication seems to time out to boxes

I have a VIP account i started back using it since yesterday i have realized i would be able to connect to interact with a box for 20 seconds then 3 mins of no communication rinse and repeat.

Can someone help me out . the latest machine i got this on was Laboratory but it also happens on retired boxes like Node and Valentine

@Johann said:

I have a VIP account i started back using it since yesterday i have realized i would be able to connect to interact with a box for 20 seconds then 3 mins of no communication rinse and repeat.

Can someone help me out . the latest machine i got this on was Laboratory but it also happens on retired boxes like Node and Valentine

It is difficult to help because there are lots of things which could be at play here. It could range from issues on your network, issues on the internet, issues on the HTB environment or issues on the box.

I’d suggest starting with:

  • run traceroute / tracert (depends on your OS) to the box when communication drops. This will give you an idea of where the packets are going.
  • check the VPN to make sure it isn’t generating any error messages.
  • check no one has reset the box.

If you can eliminate any problems at your end, it might be worth raising a ticket with HTB (via jira) to see if they can resolve it - but this can take 48 hours.

Sat Apr 10 19:44:48 2021 OpenVPN 2.4.9 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Apr 21 2020
Sat Apr 10 19:44:48 2021 library versions: OpenSSL 1.1.1g 21 Apr 2020, LZO 2.10
Sat Apr 10 19:44:48 2021 Outgoing Control Channel Authentication: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Sat Apr 10 19:44:48 2021 Incoming Control Channel Authentication: Using 256 bit message hash ‘SHA256’ for HMAC authentication
Sat Apr 10 19:44:48 2021 TCP/UDP: Preserving recently used remote address: [AF_INET]185.77.152.67:1337
Sat Apr 10 19:44:48 2021 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 10 19:44:48 2021 UDP link local: (not bound)
Sat Apr 10 19:44:48 2021 UDP link remote: [AF_INET]185.77.152.67:1337
Sat Apr 10 19:44:48 2021 TLS: Initial packet from [AF_INET]185.77.152.67:1337, sid=d07f01eb d435f813
Sat Apr 10 19:44:48 2021 VERIFY OK: depth=1, C=UK, ST=City, L=London, O=HackTheBox, CN=HackTheBox CA, name=htb, emailAddress=info@hackthebox.eu
Sat Apr 10 19:44:48 2021 VERIFY KU OK
Sat Apr 10 19:44:48 2021 Validating certificate extended key usage
Sat Apr 10 19:44:48 2021 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Sat Apr 10 19:44:48 2021 VERIFY EKU OK
Sat Apr 10 19:44:48 2021 VERIFY OK: depth=0, C=UK, ST=City, L=London, O=HackTheBox, CN=htb, name=htb, emailAddress=info@hackthebox.eu
Sat Apr 10 19:44:48 2021 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sat Apr 10 19:44:48 2021 [htb] Peer Connection Initiated with [AF_INET]185.77.152.67:1337
Sat Apr 10 19:44:49 2021 SENT CONTROL [htb]: ‘PUSH_REQUEST’ (status=1)
Sat Apr 10 19:44:49 2021 PUSH: Received control message: ‘PUSH_REPLY,route 10.10.10.0 255.255.255.0,route-ipv6 dead:beef::/64,tun-ipv6,route-gateway 10.10.14.1,topology subnet,ping 10,ping-restart 120,ifconfig-ipv6 dead:beef:2::1005/64 dead:beef:2::1,ifconfig 10.10.14.7 255.255.254.0,peer-id 7,cipher AES-256-GCM’
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: timers and/or timeouts modified
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: --ifconfig/up options modified
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: route options modified
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: route-related options modified
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: peer-id set
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: adjusting link_mtu to 1625
Sat Apr 10 19:44:49 2021 OPTIONS IMPORT: data channel crypto options modified
Sat Apr 10 19:44:49 2021 Data Channel: using negotiated cipher ‘AES-256-GCM’
Sat Apr 10 19:44:49 2021 Outgoing Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key
Sat Apr 10 19:44:49 2021 Incoming Data Channel: Cipher ‘AES-256-GCM’ initialized with 256 bit key
Sat Apr 10 19:44:49 2021 ROUTE_GATEWAY 192.168.254.2/255.255.255.0 IFACE=eth0 HWADDR=00:0c:29:bb:4e:8a
Sat Apr 10 19:44:49 2021 GDG6: remote_host_ipv6=n/a
Sat Apr 10 19:44:49 2021 ROUTE6: default_gateway=UNDEF
Sat Apr 10 19:44:49 2021 TUN/TAP device tun3 opened
Sat Apr 10 19:44:49 2021 TUN/TAP TX queue length set to 100
Sat Apr 10 19:44:49 2021 /sbin/ip link set dev tun3 up mtu 1500
Sat Apr 10 19:44:49 2021 /sbin/ip addr add dev tun3 10.10.14.7/23 broadcast 10.10.15.255
Sat Apr 10 19:44:49 2021 /sbin/ip -6 addr add dead:beef:2::1005/64 dev tun3
Sat Apr 10 19:44:49 2021 /sbin/ip route add 10.10.10.0/24 via 10.10.14.1
RTNETLINK answers: File exists
Sat Apr 10 19:44:49 2021 ERROR: Linux route add command failed: external program exited with error status: 2
Sat Apr 10 19:44:49 2021 add_route_ipv6(dead:beef::/64 → dead:beef:2::1 metric -1) dev tun3
Sat Apr 10 19:44:49 2021 /sbin/ip -6 route add dead:beef::/64 dev tun3
RTNETLINK answers: File exists
Sat Apr 10 19:44:49 2021 ERROR: Linux route -6/-A inet6 add command failed: external program exited with error status: 2
Sat Apr 10 19:44:49 2021 WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Sat Apr 10 19:44:49 2021 Initialization Sequence Completed

kali@kali:~$ sudo traceroute 10.10.10.226
traceroute to 10.10.10.226 (10.10.10.226), 30 hops max, 60 byte packets
1 10.10.14.1 (10.10.14.1) 83.486 ms * *
2 10.10.10.226 (10.10.10.226) 83.218 ms 83.617 ms 83.584 ms
kali@kali:~$ sudo traceroute 10.10.10.226
traceroute to 10.10.10.226 (10.10.10.226), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
kali@kali:~$ e=70.1 ms

This keeps happening to me too, and seemingly at random. I’ve tried switching between MacOS, Linux & Windows hosts, home & office networks, VPN or Pwnbox connections.

Doesn’t matter, some boxes just keep timing out, while others behave fine. The issue isn’t me hitting the wrong endpoints or ports, because I’ve literally rooted some boxes and the problem persists.

It’s quite irritating, since support insists the issues are on our end, but in my experience it’s the same boxes that misbehave. When I switch over to another box the connection is fine.

I’m also a paying (VIP+) customer and honestly this is a bit of a turn-off, since I’m playing the lottery every day, with which boxes will work and which won’t.