Ssh – Can not connect to ssh over network

Overview

I can not connect to a host via ssh.
I have 2 macs, both on the same wifi. Mac A can connect to a VPN and ssh into machines over wifi. Mac B can connect to the VPN but can not ssh.

Both machines have the same .pem file, in the same location, the permission is set to chmod 400 (-r--------). Both also have the same ~/.ssh/config files.

From the investigating that I have done this does not seem to be a server issue, and I think it is a problem with mac B and its network settings.

Working Machine — Mac A

OpenSSH_7.2p2, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /Users/matthewlowe/.ssh/config
debug1: /Users/matthewlowe/.ssh/config line 8: Applying options for *
debug1: /Users/matthewlowe/.ssh/config line 21: Applying options for *.internal
debug2: add_identity_file: ignoring duplicate key ~/.ssh/innometrics.pem
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug2: resolving "ip-10-0-4-139.eu-west-1.compute.internal" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to ip-10-0-4-139.eu-west-1.compute.internal [10.0.4.139] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: fd 3 clearing O_NONBLOCK
debug1: Connection established. 

Failing Machine — Mac B

When running ssh -vvv ipaddress.eu-west-1.compute.internal I get the following:

OpenSSH_7.2p2, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /Users/username/.ssh/config
debug1: /Users/username/.ssh/config line 8: Applying options for *
debug1: /Users/username/.ssh/config line 21: Applying options for *.internal
debug2: add_identity_file: ignoring duplicate key ~/.ssh/username.pem
debug1: Reading configuration data /usr/local/etc/ssh/ssh_config
debug2: resolving "ipaddress.eu-west-1.compute.internal" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to ipaddress.eu-west-1.compute.internal [xx.x.x.xxx] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address xx.x.x.xxx port 22: Operation timed out
ssh: connect to host ipaddress.eu-west-1.compute.internal port 22: Operation timed out

What does fd 3 setting O_NONBLOCK do? I gathered that fd 3 is looking for a file descriptor #3 and have found that dir on my machine. Why would it timeout here?

This doesnt seem to be a DNS issue, as the DNS name I provide is then resolved to the correct AWS IP.

Additional Details

Firewall: Off

Wifi Settings

Using DHCP
DNS Servers: 192.168.1.1
NetBIOS Name: IP-192-168-1-63 (IP-192-168-1-63 is currently being used)
Hardware configured automatically, MTU 1500

From /etc/ssh/ssh_config The only active part:

 Host *
   SendEnv LANG LC_*
   HashKnownHosts yes
   GSSAPIAuthentication yes
   GSSAPIDelegateCredentials no

And the same from /etc/ssh/sshd_config

UseDNS no
UsePrivilegeSeparation sandbox
AuthorizedKeysFile  .ssh/authorized_keys

The working machine also has XAuthLocation /opt/X11/bin/xauth though I dont know if that is relevant or not.

I have tried a wired connection and that does not work either.

I can post additional information if needed.

Papa Bless.

UPDATE #1

I have reinstalled openssh and open ssl. /usr/local/bin/ shows the correct sym link to the installed versions. I am not using an older version by mistake.

I have run ifconfig to compare the wifi network interfaces. I have also run /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I en1 to dig a little deeper into it. All looks normal though.

UPdate #2

Running route -n get dnsnamehere on A:

17:36 $ route -n get ip-10-0-2-121.eu-west-1.compute.internal
  route to: xx.x.x.xxx
destination: xx.x.x.xxx
 interface: ppp0
     flags: <UP,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
      0         0         0        52         2         0      1444         0

Running the same on B:

17:31 $ route -n get ip-10-0-2-121.eu-west-1.compute.internal
   route to: xx.x.x.xxx
destination: xx.x.x.xxx
    gateway: 192.168.1.1
  interface: en0
      flags: <UP,GATEWAY,HOST,DONE,WASCLONED,IFSCOPE,IFREF>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1453         0

We also have machine C that looks similar to the results of A. Looks like the bad machine is routing through the wifi en0 rather than through the VPN (ppp0)? If this is the case, how do I fix it?