0

I set up a Debian server VM in Parallels Desktop. I configured it to use the Bridge network. DHCP is enabled, however I configured the VM to use a static IP.

Shared Network in Parallels Desktop Preferences with DHCP from 10.211.55.1 to 10.211.55.200 (Subnet mask 255.255.255.0) without port forwarding rules

Shared Network in Debian Configuration

Virtio network adapter in Advanced Debian Configuration

On Debian within my VM the web server runs (127.0.0.1:5000) and the network is properly configured:

$ sudo cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug enp0s5
# iface enp0s5 inet dhcp
iface enp0s5 inet static
  address 10.211.55.201
  netmask 255.255.255.0
  gateway 10.211.55.1
$ sudo ifconfig
enp0s5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.211.55.201  netmask 255.255.255.0  broadcast 10.211.55.255
        inet6 fe80::21c:42ff:fedf:37b  prefixlen 64  scopeid 0x20<link>
        ether 00:1c:42:df:03:7b  txqueuelen 1000  (Ethernet)
        RX packets 564  bytes 78327 (76.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 308  bytes 49738 (48.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 15  bytes 1394 (1.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15  bytes 1394 (1.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ netstat -pln
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      -
tcp        0      0 127.0.0.1:5000          0.0.0.0:*               LISTEN      899/python3
tcp6       0      0 :::22                   :::*                    LISTEN      -
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node   PID/Program name     Path
unix  2      [ ACC ]     STREAM     LISTENING     13667    840/systemd          /run/user/1000/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     13673    840/systemd          /run/user/1000/gnupg/S.dirmngr
unix  2      [ ACC ]     STREAM     LISTENING     13675    840/systemd          /run/user/1000/gnupg/S.gpg-agent.browser
unix  2      [ ACC ]     STREAM     LISTENING     13677    840/systemd          /run/user/1000/gnupg/S.gpg-agent.extra
unix  2      [ ACC ]     STREAM     LISTENING     13679    840/systemd          /run/user/1000/gnupg/S.gpg-agent.ssh
unix  2      [ ACC ]     STREAM     LISTENING     13681    840/systemd          /run/user/1000/gnupg/S.gpg-agent
unix  2      [ ACC ]     STREAM     LISTENING     11990    -                    /run/dbus/system_bus_socket
unix  2      [ ACC ]     STREAM     LISTENING     13009    -                    /run/systemd/private
unix  2      [ ACC ]     STREAM     LISTENING     13011    -                    /run/systemd/userdb/io.systemd.DynamicUser
unix  2      [ ACC ]     STREAM     LISTENING     13012    -                    /run/systemd/io.system.ManagedOOM
unix  2      [ ACC ]     STREAM     LISTENING     13020    -                    /run/lvm/lvmpolld.socket
unix  2      [ ACC ]     STREAM     LISTENING     13024    -                    /run/systemd/fsck.progress
unix  2      [ ACC ]     STREAM     LISTENING     13032    -                    /run/systemd/journal/stdout
unix  2      [ ACC ]     SEQPACKET  LISTENING     13034    -                    /run/udev/control
unix  2      [ ACC ]     STREAM     LISTENING     10664    -                    /run/systemd/journal/io.systemd.journal
$ curl http://127.0.0.1:5000
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
...

Now I try to access the web server from the host (MacOS):

> ping 10.211.55.201
PING 10.211.55.201 (10.211.55.201): 56 data bytes
64 bytes from 10.211.55.201: icmp_seq=0 ttl=64 time=1.425 ms
64 bytes from 10.211.55.201: icmp_seq=1 ttl=64 time=0.317 ms
64 bytes from 10.211.55.201: icmp_seq=2 ttl=64 time=0.290 ms
64 bytes from 10.211.55.201: icmp_seq=3 ttl=64 time=0.386 ms
^C
--- 10.211.55.201 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.290/0.605/1.425/0.475 ms
> ssh [email protected] echo test
test
> curl http://10.211.55.201:5000
curl: (7) Failed to connect to 10.211.55.201 port 5000 after 1011 ms: Connection refused

The web server on port 5000 is oxen-io/oxen-observer. I installed all dependencies and started the server accordingly using FLASK_APP=observer flask run --reload --debugger. It's a Python project that uses Flask to host a web server and I want to start it for debugging purposes. I haven't changed any Flask configuration, I just updated my contrib/devnet-observer.ini:

[uwsgi]
chdir = /home/marty/proj/oxen/observer
socket = devnet.wsgi
plugins = python3,logfile
processes = 6
manage-script-name = true
mount = /=observer:app

logger = file:logfile=/home/marty/proj/oxen/observer/uwsgi.log,maxsize=1048576

It's definitely a fauly configuration as the webserver returns a 500, but that shouldn't prevent my host from retrieving the status code. I want to reach the web server from my host before moving on to further problems. The web server is clearly reachable from localhost, so what could be the issue that I can't reach it from my host?

6
  • "the web server". Which web server and what's your web server configuration? Seems to me from the netstat that it's only listening on 127.0.0.1:5000 and not on port 5000 for non loopback (local) traffic. Commented Jun 13, 2023 at 9:42
  • @YisroelTech I doubt the web server itself is the problem, as curl 127.0.0.1:5000 on the guest OS returns the HTML. However, I updated my question to give the information that you requested. Commented Jun 13, 2023 at 9:51
  • The web server isn't "a problem", it's simply not configured correctly. It's a perfectly valid configuration for someone to want for a server to listen on one network interface and not on a 2nd interface. In your case, as netstat is clearly saying, the server is listening to 127.0.0.1:5000 and not merely to ':5000` (on any interface). So what remains to be seen is where in the server's configuration this is set. Commented Jun 13, 2023 at 9:54
  • @YisroelTech Could you please elaborate? Yes, in my memory I was always able to curl the network address from the same OS as well (curl http://10.211.55.201:5000 on the guest), which does not work here as well. It seems the service doesn't run on the bridged enp0s5 interface. I never had to deal with this problem, my web services were always available on the primary interface, but on Parallels things could be different. Commented Jun 13, 2023 at 10:03
  • 1
    @YisroelTech You are so right, I had limited thoughts on this one. netstat now reports to use the local address 0.0.0.0:5000 as it should. Now I can reach my web server from my host. Commented Jun 13, 2023 at 10:11

1 Answer 1

1

This the default behaviour for Flask (and if your running in debug mode you should be cautious changing it, since it opens you up to attacks, except if you make sure to still not allow it from the internet).

See in the Flask documentation about it and how to allow external access by setting the listening port to all interfaces:

Externally Visible Server

If you run the server you will notice that the server is only accessible from your own computer, not from any other in the network. This is the default because in debugging mode a user of the application can execute arbitrary Python code on your computer.

If you have the debugger disabled or trust the users on your network, you can make the server publicly available simply by adding --host=0.0.0.0 to the command line:

$ flask run --host=0.0.0.0

This tells your operating system to listen on all public IPs.

1
  • Thanks for the lesson. In my mind I kinda missed the fact that a web server can run only on a single interface. Due to your comments I was able to search this up as well, but I'm glad that you answered, so I can accept your answer. :) Commented Jun 13, 2023 at 10:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .