Unable to access port (nc -l port) from outside with Alpine Linux container

Hi,

I’ve got a container on 192.168.2.81/24, it has a macvlan interface.

I am trying to get access to a port that I am listening on ie nc -l 10000.

When I try to access the port ie telnet 192.168.2.81 10000 I’m getting:

telnet: can't connect to remote host (192.168.2.81): Connection refused.

I see the request with tcpdump from inside the container:

IP 192.168.2.81.10000 > 192.168.2.1.44442: Flags [R.], seq 0, ack 4120349937, win 0, length 0

There is no firewall on either the host or in my container.

Incidentally I was able to get this working between two containers with bridged interfaces, but only if I was listening on Arch Linux and connecting with telnet from Alpine Linux. Not the other way round.

I was also unable to get this working via a VPN tunnel. For example I have a VPN tunnel connected in my container. I have the remote port forwarded on the remote server.

I should then be able to listen in the container, with nc, and if I connect to the server IP with that port see something inside the VM.

I’ve tested it with two physical hosts, and it works, so I know it’s not a miss-configuration with the VPN server.

I also do see something inside the container:

IP 172.16.39.64.26129 > vpnserver.example.com.40138: Flags [R.], seq 0, ack 1936498654, win 0, length 0

In this case 172.16.39.64 local IP of my VPN. vpnserver.example.com is the remote’s hostname.

Something I did notice, is when I used an ArchLinux container it appeared to work.

IP _gateway.46824 > dev1.38543: Flags [S], seq 2989267421, win 64240, options [mss 1460,sackOK,TS val 3536918230 ecr 0,nop,wscale 7], length 0
IP dev1.38543 > _gateway.46824: Flags [S.], seq 1246377359, ack 2989267422, win 65160, options [mss 1460,sackOK,TS val 2235408323 ecr 3536918230,nop,wscale 7], length 0
IP _gateway.46824 > dev1.38543: Flags [.], ack 1, win 502, options [nop,nop,TS val 3536918231 ecr 2235408323], length 0

(Gateway, being the the machine that I connected with Telnet from, and dev1 being the Archlinux container).

But it did work between two physical Alpine linux machines.

I wonder where I should be looking on the Alpine Linux container to determine what is causing this issue. hmm.

Another thing that I did test, was I installed nginx in the Alpine Linux container and started it.

Sure enough, I was able to see something through Telnet.

# telnet 192.168.2.81:10000
Connected to 192.168.2.81:10000
q
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 21 Nov 2020 16:04:14 GMT
Content-Type: text/html
Content-Length: 150
Connection: close

<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx</center>
</body>
</html>
Connection closed by foreign host

nc -l 10000 should do the same thing, yet it does not.

Where are you running telnet from and where are you running nc -l from?

Macvlan doesn’t allow communication between host and containers (by design).

So running nc -l on an alpine linux container. Running telnet from another physical host on the network. The issue seems to be that if a container is alpine linux, i can’t seem to connect.

I’ve also tested this with two containers, one alpine linux and one arch linux. I can listen on the arch linux side, but not the alpine linux side. In this case the interfaces were bridged, so it doesn’t appear to be a macvlan issue.

Additionally i’ve tested between a physical alpine linux host and an arch linux host, i can listen on the alpine linux host (these are two distinct physical computers).

I’ve never tried between host and guest, that’s not my intended purpose.

In my test I had to use nc -l -p 10000

E.g.

lxc launch images:alpine/3.12 c1
nc -l 10000

In another window:

Random port being listened on:

lxc shell c1
netstat -tlpn
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:40337           0.0.0.0:*               LISTEN      319/nc

In original window:

ctrl+c
nc -l -p 10000
netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 :::10000                :::*                    LISTEN      323/nc

I think I figured out the issue. :flushed:

Archlinux uses openbsd-netcat, whereas Alpine Linux uses busybox’s nc as a part of busybox-extras.

For example nc -l -p 3000 on Alpine Linux works, whereas this isn’t needed with openbsd-netcat, there nc -l 3000 works.

-l      Listen for an incoming connection rather than initiating a
        connection to a remote host. The destination and port to listen on
        can be specified either as non-optional arguments,  or with options
        -s and -p respectively.  Cannot be used together with -x or -z.
        Additionally, any timeouts specified with the -w option are ignored.

-p source_port
        Specify the source port nc should use, subject to privilege
        restrictions and availability.

Whereas with busybox’s netcat:

-l           Listen mode, for inbound connects
-lk          With -e, provides persistent server
-p PORT      Local port