Troubleshooting

MTU Blackholes

All networks have a Maximum Transmission Unit - the largest packet that it can carry. When data is sent over multiple hops, each hop may have a different MTU. Normally, routers send back an ICMP "fragmentation needed" message, but sometimes these messages are dropped (via firewall, misconfigurations or security policy). This can cause inconsistent errors such as larger scans hanging but smaller queries working just fine. To diagnose and fix, the following script can be ran to determine path MTU (PMTU).

#!/bin/bash
# ~/scripts/fix_mtu.sh 10.129.13.100
TARGET=$1
IFACE=${2:-tun0}

echo "[*] Discovering path MTU to $TARGET via $IFACE..."

for size in $(seq 1500 -10 100); do
    PMTU=$((size + 28))
    echo "  [*] Testing MTU: ${PMTU} bytes..."
    if ping -M do -s $size $TARGET -c 1 -W 1 &>/dev/null; then
        echo "[+] Found Path MTU: ${PMTU} bytes"
        echo "[*] Setting $IFACE MTU to ${PMTU}..."
        sudo ip link set dev $IFACE mtu $PMTU
        echo "[+] Done. Re-run after VPN reconnect."
        exit 0
    fi
done

echo "[-] Could not determine path MTU"

Clock Skew

When enumerating a windows domain controller and attempting to get a TGT, I received an error that stated clock skew too great. If a target server's system time is misconfigured, it can cause certain commands to fail.

# method #1 testing for clock difference
$ date && date -d "$(net time -S 10.129.10.10)" 
Tue Jun 16 08:45:19 PM EDT 2026
Wed Jun 17 07:45:24 AM EDT 2026

# method #2 testing using nmap to check smb time
$ date && date -d "$(nmap -Pn --script smb2-time -p445 10.129.10.10 -oN - | awk -F'date: ' '/\| *date:/ {print $2}' | sed 's/T/ /' | head -1)" 
Tue Jun 16 08:45:19 PM EDT 2026
Wed Jun 17 07:45:24 AM EDT 2026


# pass either method into faketime to temporary set the terminal (and all subsequent commands) to that time
$ faketime "$(net time -S 10.129.10.10)" bash
$ date && date -d "$(net time -S 10.129.10.10)"          
Wed Jun 17 07:45:23 AM EDT 2026
Wed Jun 17 07:45:24 AM EDT 2026