Decoding the Enigma of “Weird Network Issue”: A Comprehensive Guide to Troubleshooting SSH IP Connectivity

Experiencing a weird network issue where you can successfully SSH into your Ubuntu MATE server using its hostname but fail when attempting to connect via its IP address is a perplexing, yet not entirely uncommon, challenge. This scenario, while frustrating, points towards a specific set of potential misconfigurations and network behaviors that we, at revWhiteShadow, are dedicated to dissecting and resolving. Our aim is to provide an exhaustive guide that not only illuminates the root causes of such connectivity problems but also empowers you with the knowledge to diagnose and rectify them, ultimately ensuring seamless SSH access to your server.

We understand the intricacies involved in network diagnostics, and we’re here to offer a detailed, step-by-step approach to unraveling this particular network problem. The symptoms you’ve described – the ability to SSH via hostname, successful outbound SSH connections from the server, functional internet browsing within the GUI, correctly populated ip route show output, and seemingly standard /etc/netplan configuration – all suggest that the fundamental network stack is operational. The anomaly lies in the specific interaction between your client and the server’s IP address for SSH connections, coupled with peculiar behavior observed in your Nokia BGW320-505 router’s device list.

This article will delve deep into the potential culprits, from DNS resolution nuances and firewall configurations to router-specific settings and advanced network stack behaviors. We will meticulously examine each possibility, providing concrete diagnostic steps and actionable solutions. Our goal is to surpass existing content in its depth and clarity, offering a definitive resource for anyone encountering a similar network issue.

Understanding the Core of the SSH IP Connectivity Problem

Before we dive into specific troubleshooting steps, it’s crucial to grasp why SSH might function with a hostname but not an IP address. Typically, when you SSH using a hostname, your system first performs a DNS (Domain Name System) lookup to translate that human-readable hostname into a machine-readable IP address. If this process is successful, the connection then proceeds to the resolved IP address. When you attempt to connect directly via IP address, you bypass this DNS resolution step.

The fact that hostname-based SSH works suggests that basic network connectivity and the SSH daemon (sshd) on your server are likely functioning correctly. The failure to connect via IP address points to issues that are either:

  • Preventing the client from correctly resolving the IP address: This is less likely if you’re explicitly typing the IP.
  • Interfering with the direct IP-to-IP connection: This could be due to firewall rules, routing issues specific to IP-based connections, or problems with how the server is advertising its IP address to the network, particularly concerning reverse DNS or name resolution mechanisms.
  • Related to the peculiar behavior of your router: The observation of “Intel Corporate” associated with the IPv4 address in your router’s device list is a significant clue.

We will systematically explore these avenues.

Deep Dive into Diagnostic Steps for the “Weird Network Issue”

Let’s begin by systematically examining your network environment and configurations.

#### Validating Basic Network Connectivity and Server Configuration

While you’ve stated that outbound connections and GUI browsing are functional, a re-verification of fundamental settings can often reveal subtle misconfigurations.

#### Verifying SSH Daemon Status and Configuration

The SSH daemon (sshd) must be running and correctly configured to accept connections.

  1. Check SSH Service Status: On your Ubuntu MATE server, open a terminal and run:

    sudo systemctl status ssh

    Ensure the output indicates that the service is active (running). If not, start it with sudo systemctl start ssh and enable it to start on boot with sudo systemctl enable ssh.

  2. Review SSH Configuration: The main configuration file for sshd is /etc/ssh/sshd_config. While unlikely to be the sole cause if hostname SSH works, it’s worth a quick review.

    sudo nano /etc/ssh/sshd_config

    Look for lines like:

    • Port 22 (or your custom SSH port).
    • ListenAddress 0.0.0.0 or ListenAddress <your_server_ip> (ensure it’s not commented out or set to an incorrect IP). If ListenAddress is not specified, sshd usually listens on all available interfaces.

  3. Restart SSH Service: After any configuration changes, remember to restart the SSH service:

    sudo systemctl restart ssh

#### Analyzing Network Interface Configuration with Netplan

Your provided /etc/netplan/01-network-manager-all.yaml shows a standard configuration using NetworkManager with DHCP for both IPv4 and IPv6 on enp4s0. This is generally robust.

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp4s0: # Replace with your interface name
      dhcp4: yes
      dhcp6: yes

The ip a show enp4s0 output you shared also looks typical for a DHCP-assigned address:

2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 04:42:1a:09:03:05 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.189/24 brd 192.168.1.255 scope global dynamic noprefixroute enp4s0 valid_lft 84230sec preferred_lft 84230sec
    inet6 2600:1700:47f0:5360::1a/128 scope global dynamic noprefixroute valid_lft 3150sec preferred_lft 3150sec
    inet6 2600:1700:47f0:5360:daf4:fd6c:8da4:b9a3/64 scope global temporary dynamic valid_lft 3551sec preferred_lft 3551sec
    inet6 2600:1700:47f0:5360:afd6:4163:2cb9:fef1/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 3551sec preferred_lft 3551sec
    inet6 fe80::9d39:8ff3:8ec5:a74f/64 scope link noprefixroute valid_lft forever preferred_lft forever

The presence of dynamic for inet and inet6 confirms these addresses are leased via DHCP. The scope global indicates they are routable.

If you suspect a DHCP issue, even though other things work, you could temporarily try a static IP configuration for testing purposes. Edit your netplan file:

sudo nano /etc/netplan/01-network-manager-all.yaml

And change it to something like this (replace with an IP address not in use on your network, e.g., 192.168.1.190 if 192.168.1.189 is your current IP):

network:
  version: 2
  renderer: NetworkManager
  ethernets:
    enp4s0:
      dhcp4: no
      dhcp6: no
      addresses: [192.168.1.190/24] # Use a static IP
      routes:
        - to: default
          via: 192.168.1.1 # Your router's IP
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4] # Google DNS or your preferred DNS

Then apply the changes:

sudo netplan apply

Test SSH using the new static IP. If this works, it points towards a DHCP lease or registration issue with your router. Remember to revert to DHCP if it doesn’t resolve the problem or if you prefer DHCP.

#### Examining Routing Tables

Your ip route show output being correct is a good sign. This command lists the kernel routing tables. It confirms that your system knows how to reach destinations, including the default gateway.

ip route show

The output should show a default route pointing to your router’s IP address (e.g., default via 192.168.1.1 dev enp4s0). The fact that you can reach the internet and SSH out confirms this is likely correct.

#### Firewall Considerations

Firewalls can be configured to block or permit traffic based on various criteria, including source IP, destination IP, and port.

#### UFW (Uncomplicated Firewall) on Ubuntu

Ubuntu MATE often comes with UFW enabled. We need to ensure it’s not inadvertently blocking IP-based SSH connections.

  1. Check UFW Status:

    sudo ufw status

    If it’s inactive, the firewall isn’t the issue. If it’s active, examine the rules.

  2. Review UFW Rules: If active, you’ll see output like:

    Status: active

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW       Anywhere
22/tcp (v6)                ALLOW       Anywhere (v6)

    Ensure that SSH (port 22 by default) is allowed from all necessary sources. If you only see ALLOW IN Anywhere without specifying the port, it might be implicitly allowing all ports, or you might need explicit rules.

    To explicitly allow SSH on port 22:

    sudo ufw allow ssh
# Or, if using a non-standard port, e.g., 2222
# sudo ufw allow 2222/tcp

    If you are connecting from a specific IP address or subnet, you can restrict it for added security:

    # Allow SSH from a specific IP
sudo ufw allow from 192.168.1.100 to any port 22
# Allow SSH from a subnet
sudo ufw allow from 192.168.1.0/24 to any port 22

  3. Test IP Connection After UFW Checks: After reviewing or adjusting UFW rules, attempt the SSH connection via IP address again.

#### Router-Level Firewall and Access Control

Your Nokia BGW320-505 router acts as the gateway and likely has its own firewall settings. While it permits traffic from your client to the server (since hostname SSH works), there might be subtle rules affecting direct IP access.

  • Port Forwarding: Ensure that port forwarding for SSH (TCP port 22) is correctly configured if you’re trying to access the server from outside your local network. However, for local IP access, this shouldn’t typically be the bottleneck unless the router’s internal firewall is very strict.
  • Access Control Lists (ACLs): Some routers have ACLs that can restrict access between devices on the same local network. Check your router’s settings for any such lists.
  • Firewall Zones: Understand how your router segments its network. Is your client and server in the same zone, and are there any intra-zone restrictions?

#### The Puzzling Router Device List and Hostname Association

This is arguably the most critical piece of evidence. The Nokia BGW320-505 showing “Intel Corporate” as the IPv4 hostname for your server’s IP address is a strong indicator of a naming resolution or configuration anomaly at the router level.

#### Understanding ARP and Hostname Resolution

  • ARP (Address Resolution Protocol): Within a local network, devices use ARP to map IP addresses to MAC addresses. When your server boots up, it broadcasts its IP-to-MAC mapping.
  • NetBIOS/LLMNR (Link-Local Multicast Name Resolution): These protocols allow devices to resolve hostnames on a local network without relying solely on DNS. Windows systems heavily use NetBIOS, while LLMNR is an open standard. Linux systems can also utilize LLMNR.
  • DHCP Hostname Option: When a device requests an IP address via DHCP, it can send its hostname to the DHCP server. The DHCP server can then use this information to populate its lease table or DNS server.

#### Investigating the “Intel Corporate” Hostname

The “Intel Corporate” string is highly unusual. It suggests one of the following:

  1. Stale DHCP Lease Information: Your router might have received this hostname from a previous device that used that IP address, or perhaps from the server itself at some point in its history, and it hasn’t updated correctly.
  2. Router’s Internal DNS/DHCP Server Misconfiguration: The router’s built-in DNS server or DHCP server might be assigning or incorrectly registering this hostname for your server’s IP.
  3. Server’s Own Hostname Configuration: While you’ve stated /etc/hosts is correct, other system services or network configurations might be inadvertently broadcasting or registering an incorrect hostname.

#### Actions to Address the Router’s Hostname Anomaly

  1. Reboot the Router: A simple reboot can often clear temporary glitches in the router’s memory and tables. Power cycle your Nokia BGW320-505.

  2. Renew DHCP Lease on the Server: Force your Ubuntu server to get a new IP address and hostname registration from the router.

    • Using dhclient:
      sudo dhclient -r enp4s0  # Release current lease
sudo dhclient enp4s0     # Request a new lease
      After this, check your router’s device list again.

  3. Clear Router’s ARP Cache: Some routers allow you to clear their ARP cache. Consult your Nokia BGW320-505 manual or web interface for this option.

  4. Check Router’s DHCP Client List/Reservations: Log into your router’s web interface.

    • Look for a section listing connected devices or DHCP leases.
    • See how your server’s MAC address (04:42:1a:09:03:05) is listed.
    • If there’s a static DHCP reservation or an entry with “Intel Corporate,” try deleting it and letting the server re-register itself.
    • Check if there’s an option to manually set hostnames for IP addresses. Ensure your server’s IP is correctly associated with its actual hostname (your_ubuntu_server_hostname).

  5. Investigate Server’s Hostname Settings:

    • /etc/hostname: This file should contain your server’s actual hostname.

      cat /etc/hostname

      Ensure it’s correct. If not, edit it (sudo nano /etc/hostname), change the line, and then reboot or run sudo hostname -F /etc/hostname.

    • /etc/hosts: You confirmed this is correct, but let’s review its typical structure:

      127.0.0.1   localhost
127.0.1.1   your_ubuntu_server_hostname

# The following lines are desirable for IPv6 capable hosts
::1     localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

      Ensure the 127.0.1.1 entry correctly points to your server’s actual hostname.

    • NetworkManager Configuration: Although Netplan uses NetworkManager, NetworkManager itself has its own configurations. However, the Netplan YAML is the primary interface for defining network settings.

    • LLMNR/NBT Settings (Less Likely on Linux Server): While your server is Ubuntu MATE, if other devices on your network (especially Windows) are involved, they might be broadcasting “Intel Corporate.” Ubuntu can participate in LLMNR. You can disable LLMNR on the server if you suspect it:

      # Check if avahi-daemon is running (handles LLMNR)
sudo systemctl status avahi-daemon
# If running and you suspect it, you can stop and disable it
# sudo systemctl stop avahi-daemon
# sudo systemctl disable avahi-daemon
# However, disabling this might impact other local network discovery.

      It’s more likely the issue is with the router’s perception of the hostname.

#### Advanced Network Troubleshooting Steps

If the above steps don’t resolve the issue, we need to employ more advanced diagnostic tools.

#### Tracing the Connection Path

Understanding where the connection fails is crucial.

  1. traceroute: This tool shows the hops a packet takes to reach a destination.

    • Using Hostname:
      traceroute your_ubuntu_server_hostname
    • Using IP Address:
      traceroute 192.168.1.189
      Compare the outputs. If they differ, it might indicate routing issues specific to how the IP address is being processed.

  2. nmap Port Scan: From your client machine, try scanning the SSH port on your server’s IP address.

    nmap -p 22 192.168.1.189

    This will tell you if the port is open, closed, or filtered. If it shows filtered, it implies a firewall (either on the server or router) is blocking the connection attempt.

#### Packet Analysis with Wireshark/tcpdump

For the most granular insight, packet capture is invaluable.

  1. On the Server: Capture traffic on the enp4s0 interface while attempting an SSH connection via IP from your client.

    sudo tcpdump -i enp4s0 'tcp port 22' -s 0 -w ssh_capture.pcap

    In another terminal on the server, try to SSH in using the IP. Then, stop tcpdump (Ctrl+C). Transfer ssh_capture.pcap to a machine with Wireshark and analyze.

  2. On the Client: Perform a similar capture on the client machine’s network interface while attempting the SSH connection.

    Analyzing these captures will reveal:

    • Whether the SYN packet from the client reaches the server’s IP address.
    • How the server responds (SYN-ACK, RST, or no response).
    • Any unexpected ICMP messages.

#### IPv6 Specifics

You have IPv6 addresses configured. While your primary issue is with IPv4 IP access, it’s worth ensuring IPv6 isn’t contributing to confusion.

  • Test IPv6 SSH: Try SSHing into your server using its IPv6 address (e.g., ssh your_ubuntu_server_hostname@2600:1700:47f0:5360::1a). If this works, it further isolates the problem to IPv4 handling or the router’s IPv4 device list.
  • IPv6 Privacy Extensions: The temporary IPv6 address is a privacy feature. It shouldn’t directly interfere with SSH IP connectivity unless specific firewall rules target temporary addresses.

#### Potential Solutions and Strategies

Based on the likely causes, here are the most effective strategies:

  1. Router Configuration Reset/Refresh:

    • Reboot your Nokia BGW320-505. This is the first and easiest step.
    • Renew DHCP Lease: Force your Ubuntu server to request a fresh IP address and re-register its hostname with the router.

  2. Static IP Configuration (Temporary or Permanent): Assigning a static IP address to your Ubuntu server on the router’s DHCP reservation settings or directly in the server’s Netplan configuration (as shown previously) can bypass potential DHCP registration issues. Ensure the static IP is within your subnet and not in conflict with other devices. If using static IP, ensure the router’s DNS settings are correctly propagated to the server.

  3. Router Firmware Update: Check if your Nokia BGW320-505 has any available firmware updates. Bugs in router firmware can cause unexpected behavior like incorrect device naming.

  4. Investigate Router’s DNS/DHCP Settings:

    • Disable LLMNR/NetBIOS on the Router: If your router has settings to disable these protocols, try disabling them to see if it removes the “Intel Corporate” association.
    • Check DHCP Server Settings: Examine how the router assigns hostnames. Is there an option for manual hostname mapping or a way to enforce client-provided hostnames?

  5. Explicitly Define Server Hostname in /etc/hosts on Client: While not a solution for the root cause, you can add an entry to your client’s /etc/hosts file that maps the server’s IP address to its correct hostname:

    # On your client machine
192.168.1.189   your_ubuntu_server_hostname

    This bypasses any potential DNS or router issues for your client but doesn’t fix the underlying problem.

  6. Server’s Hostname Broadcasting: If you suspect the server is broadcasting an incorrect hostname, ensure /etc/hostname is correct. You might also investigate services like nss-mdns or avahi-daemon if they are configured to announce the hostname and potentially causing conflicts, though this is less common for such a specific incorrect name.

#### Conclusion: Resolving the “Weird Network Issue”

The anomaly you are experiencing with SSH IP connectivity, coupled with the peculiar router device list entry, strongly suggests that the core of the problem lies within how your Nokia BGW320-505 router is managing hostname associations for your Ubuntu MATE server’s IP address. While the server’s network configuration and SSH daemon appear functional for hostname-based access and general network operations, the direct IP connection is being obstructed, likely due to a misinterpretation or incorrect registration of the server’s identity within the router’s internal network management.

Our comprehensive diagnostic approach, starting from validating basic network services, meticulously examining firewall rules, and then delving into the intricacies of router-level hostname resolution, provides a clear path forward. By systematically testing each potential cause, from DHCP lease renewals and static IP configurations to analyzing packet captures, you can pinpoint the exact point of failure.

The key takeaway is to focus on the router’s behavior regarding hostname registration. Renewing DHCP leases, clearing router caches, and verifying DHCP reservations are paramount. Should these fail, investigating advanced router settings or considering a firmware update for the Nokia BGW320-505 are the logical next steps.

At revWhiteShadow, we pride ourselves on providing detailed, actionable insights to overcome even the most perplexing network issues. By following these steps, you should be well-equipped to restore seamless SSH access to your server, resolving this weird network issue definitively.