When working with VMware Fusion 3.0 on Mac OS X 10.5.8 running an Ubuntu 8.04 VM, I encountered a frustrating scenario where SSH connections and ping requests from the host to the guest VM were timing out. The reverse connection (VM pinging host) worked flawlessly, which made the situation particularly puzzling.

First, let's verify the basic networking components:

# On Ubuntu VM:
sudo apt-get install openssh-server
sudo service ssh status
ifconfig -a

And on the Mac host:

ifconfig | grep inet
vmrun list

After switching from NAT to Bridged networking (as many tutorials suggest), I encountered "Time to live exceeded" errors. This turned out to be VPN-related interference. The solution was straightforward:

# Disconnect any active VPN connection
sudo route -n delete 172.16.193.0/24

VMware Fusion offers several networking modes. Here's how to check and change them:

# For NAT configuration:
sudo vi /etc/network/interfaces
# Ensure it contains:
# auto eth0
# iface eth0 inet dhcp

For bridged mode troubleshooting:

# On Mac host:
sudo tcpdump -i vmnet8
# On Ubuntu VM:
sudo tcpdump -i eth0

Even with correct networking, firewall rules might block traffic:

# On Ubuntu VM:
sudo ufw status
sudo iptables -L -n
# For testing, temporarily disable:
sudo ufw disable

To make the solution survive reboots and VPN reconnections:

# Create a network configuration script
sudo vi /etc/network/if-up.d/vmwarefix
#!/bin/sh
if [ "$IFACE" = "eth0" ]; then
    route add -net 172.16.193.0 netmask 255.255.255.0 dev eth0
fi

Remember to make it executable:

sudo chmod +x /etc/network/if-up.d/vmwarefix

---

When attempting to establish SSH connectivity between a Mac OS X 10.5.8 host and an Ubuntu 8.04 guest VM running on VMware Fusion 3.0, users may encounter complete network unresponsiveness - neither SSH connections nor basic pings succeed. This commonly occurs after:

• VMware Fusion upgrades (particularly from 2.x to 3.0)
• VM snapshot rollbacks
• VMware Tools updates

The default NAT configuration in VMware Fusion typically assigns IP addresses in the 172.16.193.x range. Verify the VM's IP with:

ifconfig eth0 | grep "inet addr"

Key observations from the reported case:

• Unidirectional connectivity (VM→host works, host→VM fails)
• Packet loss at layer 3 (ping failures)
• Timeouts at layer 4 (SSH connection attempts)

Begin with these diagnostic commands on the Ubuntu VM:

# Check SSH service status
sudo /etc/init.d/ssh status

# Verify firewall rules
sudo iptables -L -n -v

# Examine network interfaces
ip link show
ip addr show

1. NAT vs. Bridged Mode:
Switching between network modes often reveals underlying issues. Test both configurations:

# VMware Fusion CLI to check current mode
vmrun getGuestIPAddress /path/to/vm.vmx

2. VPN Interference:
Corporate VPNs frequently conflict with VM networking. The reported "Time to live exceeded" errors indicate routing issues. Diagnostic steps:

# On Mac host: check routing tables
netstat -rn

# On Mac host: test base connectivity
traceroute 172.16.193.129

For reliable NAT-mode operation, add these settings to /etc/vmware/vmnet8/nat.conf:

[incomingtcp]
# Allow SSH through NAT
22 = 172.16.193.129:22

[incomingudp]
# Optional: Add other required ports

Create this shell script to reset all networking components:

#!/bin/bash
# Reset VMware networking
sudo /Library/Application\ Support/VMware\ Fusion/boot.sh --restart

# Flush Mac network caches
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

# Restart VM networking
vmrun -T fusion stop "/path/to/vm.vmx" soft
vmrun -T fusion start "/path/to/vm.vmx" nogui

For persistent cases, enable detailed logging:

# On Mac host enable VMware logging
defaults write com.vmware.fusion loggingLevel -string "verbose"
defaults write com.vmware.fusion logging -string "vmx vmnet vmkernel"

Examine logs at:
~/Library/Logs/VMware/ and /Library/Logs/VMware/