On this Mac OSX there was the setting "Always Require VPN" on MullvadVPN application.

This setting is extremely desirable when on the internet filtering ads and keeping privacy and security, and it is great that it works well. The app changes very deep OSX configurations and the user has no network if not connected to the VPN. This is to avoid leaks. To guarantee no request will go through another socket. It also cuts internet if VPN connection is interrupted and user has to wait until it's restablished. Even if the app is killed, one will not be able to request anything via sockets other than the VPN.

It's a great setting, but it does not allow one to connect to a service running on the own machine, or a minikube cluster, or this case above, a simple ethernet connection with no DHCP or any complication.

Lessons learned on the way to troubleshoot problems like this:

• When ping fails, the result from arp -a can help troubleshooting. OSX will display a question mark as domain name if cut from networking.

~ $ arp -a
? (169.254.13.100) at 0:1:0:0:0:4d on en4 [ethernet]

But it will display the domain name when having lan access:

~ $ arp -a
tux.local (169.254.13.100) at 0:1:0:0:0:4d on en4 [ethernet]

Unfortunately this same command on linux will not be capable of reading OSX name.

• The FireWire 2 adaptor was working. If the switch lights blink, ether is okay. In any case, I found the bellow resource for FireWire 2 problems that might help people. http://www.thexlab.com/faqs/firewiretroubleshooting.html

• OSX Firewall does not block ping in or out. When the VPN was out, all worked with the Firewall on block-all.

On this Mac OSX, there was the setting "Always Require VPN" on MullvadVPN application.

This setting is extremely desirable when on the internet filtering ads and keeping privacy and security, and it is great that it works well. The app changes very deep OSX configurations and the user has no network if not connected to the VPN. This is to avoid leaks. To guarantee no request will go through another socket. It also cuts the internet if the VPN connection is interrupted and the user has to wait until it's reestablished. Even if the app is killed, one will not be able to request anything via sockets other than the VPN.

It's a great setting, but it does not allow one to connect to a service running on the own machine, or a Minikube cluster, or in this case above, a simple ethernet connection with no DHCP or any complication.

Lessons learned on the way to troubleshoot problems like this:

• When ping fails, the result from arp -a can help troubleshooting. OSX will display a question mark as domain name if cut from networking.

    ~ $ arp -a
    ? (169.254.13.100) at 0:1:0:0:0:4d on en4 [ethernet]

• But it will display the domain name when having LAN access:

    ~ $ arp -a
    tux.local (169.254.13.100) at 0:1:0:0:0:4d on en4 [ethernet]

Unfortunately, this same command on Linux will not be capable of reading the OS X name.

• The FireWire 2 adaptor was working. If the switch lights blink, ether is okay. In any case, I found the below resource for FireWire 2 problems that might help people. http://www.thexlab.com/faqs/firewiretroubleshooting.html

• OSX Firewall does not block ping in or out. When the VPN was out, all worked with the Firewall on block-all.