Unable to receive response to curl request against private IP address of computer on OSX

I am experiencing an interesting issue that I am struggling to get to the bottom of and would welcome any insights into what might be going on.

I am running a Macbook pro on OSX 10.13.6.

My issue is as follows... I start up a node server binding to all interfaces through the 0.0.0.0 address. I am able to Curl localhost:3000 and 127.0.0.1:3000 and successfully hit the server and receive a response.

When I try to curl my private IP from my machine curl 192.168.1.113:3000 the request is received by the server and a response is sent, however, the response is never received by curl. Colleagues on the network are successfully able to curl my private IP and get a response.

Here is what I have observed so far.

I flush my routing tables netstat -rn looks like this.

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc           74        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              3 1561554184     lo0
169.254            link#12            UCS             0        0     en0
192.168.1          link#12            UCS             0        0     en0
192.168.1.1/32     link#12            UCS             1        0     en0
192.168.1.1        70:4f:57:81:72:d2  UHLWIir        24       37     en0   1198
192.168.1.113/32   link#12            UCS             0        0     en0
224.0.0/4          link#12            UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0        2     en0
255.255.255.255/32 link#12            UCS             0        0     en0

My private IP has a record 192.168.1.113/32 that is bound to the en0 interface. When I access the server using curl on localhost and 127.0.0.1 nothing changes in my routing tables.

Immediately after accessing curl 192.168.1.113:3000 from my machine a new record appears in the routing table as shown below.

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc           71        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              5 1561554801     lo0
169.254            link#12            UCS             0        0     en0
192.168.1          link#12            UCS             1        0     en0
192.168.1.1/32     link#12            UCS             1        0     en0
192.168.1.1        70:4f:57:81:72:d2  UHLWIir        22       43     en0   1170
192.168.1.113/32   link#12            UCS             1        0     en0
192.168.1.113      88:e9:fe:4c:a3:58  UHLWIi          2        8     lo0
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0       11     en0
224.0.0/4          link#12            UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0       18     en0
255.255.255.255/32 link#12            UCS             0        0     en0

The line has a gateway interface which is the en0 interface and is bound to lo0 the loopback interface.

192.168.1.113 88:e9:fe:4c:a3:58 UHLWIi 2 8 lo0

I'm wondering if the response packets are being routed in a bad way when the request is being made from inside the host. All help appreciated.

EDIT -> ifconfig below

ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
    options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
    inet 127.0.0.1 netmask 0xff000000
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
    nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
XHC0: flags=0<> mtu 0
XHC1: flags=0<> mtu 0
XHC20: flags=0<> mtu 0
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=60<TSO4,TSO6>
    ether 32:00:f0:81:a8:01
    media: autoselect <full-duplex>
    status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=60<TSO4,TSO6>
    ether 32:00:f0:81:a8:00
    media: autoselect <full-duplex>
    status: inactive
en3: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=60<TSO4,TSO6>
    ether 32:00:f0:81:a8:05
    media: autoselect <full-duplex>
    status: inactive
en4: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
    options=60<TSO4,TSO6>
    ether 32:00:f0:81:a8:04
    media: autoselect <full-duplex>
    status: inactive
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 88:e9:fe:4c:a3:58
    inet6 fe80::a5:7168:25d:73ec%en0 prefixlen 64 secured scopeid 0xc
    inet 192.168.1.113 netmask 0xffffff00 broadcast 192.168.1.255
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
    ether 0a:e9:fe:4c:a3:58
    media: autoselect
    status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
    ether a2:cf:3c:7c:70:56
    inet6 fe80::a0cf:3cff:fe7c:7056%awdl0 prefixlen 64 scopeid 0xe
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    options=63<RXCSUM,TXCSUM,TSO4,TSO6>
    ether 32:00:f0:81:a8:01
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
        ipfilter disabled flags 0x2
    member: en1 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 8 priority 0 path cost 0
    member: en2 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 9 priority 0 path cost 0
    member: en3 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 10 priority 0 path cost 0
    member: en4 flags=3<LEARNING,DISCOVER>
            ifmaxaddr 0 port 11 priority 0 path cost 0
    nd6 options=201<PERFORMNUD,DAD>
    media: <unknown type>
    status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
    inet6 fe80::61db:32d6:4611:1341%utun0 prefixlen 64 scopeid 0x10
    nd6 options=201<PERFORMNUD,DAD>
en5: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether ac:de:48:00:11:22
    inet6 fe80::aede:48ff:fe00:1122%en5 prefixlen 64 scopeid 0x7
    nd6 options=201<PERFORMNUD,DAD>
    media: autoselect
    status: active

Server can be started in Node

require('http')
 .createServer(function (req, res) {
   res.end('OK');
 })
 .listen(3000, '0.0.0.0');

or Python 2

python -m SimpleHTTPServer 3000

Simon McClive

Posted 2018-08-01T11:03:07.323

Reputation: 121

Can you provide an ifconfig output. I've got an inkling of the issue but need to confirm the interface configuration. – Hogstrom – 2018-08-02T12:20:08.517

Hi @hogstrom I've added the ifconfig to the post. Thanks. – Simon McClive – 2018-08-03T12:34:46.700

Two things. Thanks for the ifconfig. Do you have your node js code in a form that you can share how your setting up the listen? Are you binding to "0.0.0.0". What's odd is that there is another entry that I don't understand.

192.168.1.113 88:e9:fe:4c:a3:58 UHLWIi 2 8 lo0

This shows your IP is bound to the loopback. This is odd to me at least I've never seen it. Can you provide a snippet of code so I can re-produce ?

Can you do this command as well so we can see what the IP the app is bound to? netstat -an -f inet -p tcp | grep LISTEN – Hogstrom – 2018-08-05T02:31:30.773

I've moved networks but same issue. Netstat output 192.168.0.27/32 link#12 UCS 1 0 en0 and 192.168.0.27 88:e9:fe:4c:a3:58 UHLWIi 1 29 lo0 for port 3000 the only record is this tcp4 0 0 *.3000 *.* LISTEN. Added node/python code above, both are binding to 0.0.0.0. – Simon McClive – 2018-08-06T07:25:41.540

You have a very strange network setup, which very likely is the reason. Are you responsible for your network, or is it some other person? A normal setup would have some /24 or other address range on en0 instead of single /32 addresses, and a complete LAN segment behind it, and it never would have the same address on lo. Is your network in any way special, or why did you end up with this setup? – dirkt – 2018-08-06T08:31:52.623

In attempting to re-create the problem I did see a sporadic assignment of the primary IP to the lo0 interface. It appears that manipulation of the routing tables is causing the issue.

To reset your network interface to a "default" configuration without rebooting you can do the following. (Note, worst case you might have to reboot if things stay nerfed) (Warning: this WILL DISRUPT all existing IP connections and services):

Shutdown all networking utilities and services like VPNs
Disable existing network interfaces. On most MacBooks this will be en0

Look for the interface that represents your primary IP. You can find that with this command:

ping `hostname`

Porky:Downloads hogstrom$ ping `hostname`
PING porky.local (10.0.0.114): 56 data bytes
64 bytes from 10.0.0.114: icmp_seq=0 ttl=64 time=0.055 ms

Look for that IP address (in this case it's 10.0.0.114) in the output in your ifconfig output

ifconfig

    en0: flags=8863 mtu 1500
        ether a0:99:9b:1a:a7:f1
        inet6 fe80::874:c2c9:c839:ac4a%en0 prefixlen 64 secured scopeid 0x5
        inet 10.0.0.114 netmask 0xffffff00 broadcast 10.0.0.255
        nd6 options=201
        media: autoselect
        status: active

Note the interface name (in this example it's en0)

Shutdown the current network
```
sudo ifconfig en0 down
```
`
Flush the existing routes sudo route -n flush

Note: the -n flag is needed otherwise you'll end up waiting for extended periods of time for network timeouts; which are expected as we're flushing the routing table.

Here is what the routing table looks like when the primary is down and the route -n flush has been run a few times. I execute the command three times.

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              1    97314     lo0
224.0.0            link#1             UmCS            1        0     lo0
224.0.0.251        link#1             UHmW3I          0        0     lo0     12

Bring up the primary interface shutdown in step 3.

sudo ifconfig en0 up

Use the interface name from step3.

Verify the network routing table:

netstat -rn

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.0.0.1           UGSc           92        0     en0
10/24              link#5             UCS             1        0     en0
10.0.0.1/32        link#5             UCS             2        0     en0
10.0.0.1           2c:fd:a1:2:49:40   UHLWIir        24        5     en0   1198
10.0.0.114/32      link#5             UCS             0        0     en0
10.0.0.255         ff:ff:ff:ff:ff:ff  UHLWbI          0        2     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              1    97314     lo0
169.254            link#5             UCS             0        0     en0
224.0.0/4          link#5             UmCS            2        0     en0
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
239.255.255.250    1:0:5e:7f:ff:fa    UHmLWI          0        2     en0
255.255.255.255/32 link#5             UCS             0        0     en0

Note: the primary IP (10.0.0.114 on my system) is not associated with lo0 which was the case based on the diagnostics provided. I did observe this happening when adjusting the routing table but it is anomalous and most likely the cause of the issue.

Verify the network configuration

I test by pinging Google’s primary DNS server.

ping 8.8.8.8

Porky:Downloads hogstrom$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=120 time=25.527 ms

At this point you should have a working network and should be able to access your node server using both localhost and your primary IP address.

Hogstrom

Posted 2018-08-01T11:03:07.323

Reputation: 1 312

Hi @Hogstrom, thanks for taking the time to post a reply, I've been out in the wilderness for the past week so apologies for the delay. I've ran through the steps above taking the network interface down and back up, but as soon as I spin up a server on port 3000 and fire a curl request against it the lo0 connection reappears on the same IP so it looks like this is not solving the problem, unfortunately. I am going to try and get hold of a clean laptop that has not been touched and see if I can reproduce and rule out if it happens on all Macs or only ones configured by this company. – Simon McClive – 2018-08-13T07:16:26.143

Hi @SimonMcClive sorry I couldn't help ... I assume there is some network software (VPN or other) that is messing you up. Good luck – Hogstrom – 2018-08-17T20:16:24.297

Unable to receive response to curl request against private IP address of computer on OSX

Answers