Accessing tcp port 8080 externally on macos mojave - macos

I am trying to access a listening tcp socket on my macbook from any external client on the same wi-fi lan.
This works for specific ports, eg. 8000, but not other ports, eg. 8080, 8081, 8082
How can I open up or access the 8080 tcp port externally?
Working steps on port 8000
Server
$ nc -lv 8000
Client
$ nc -z 192.168.101.98 8000
Connection to 192.168.101.98 port 8000 [tcp/irdmi] succeeded!
Non-working steps on port 8080
Server
$ nc -lv 8080
Client
$ nc -z 192.168.101.98 8080
(The command just hangs)
Diagnostics
$ lsof -P -i TCP:8000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nc 75782 ... 3u IPv4 0x5be3e11e5a732339 0t0 TCP *:8000 (LISTEN)
$ lsof -P -i TCP:8080
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
nc 75952 ... 3u IPv4 0x5be3e11e581e2fb9 0t0 TCP *:8080 (LISTEN)
$ sudo pfctl -s all | grep Status
No ALTQ support in kernel
ALTQ related functions disabled
Status: Disabled Debug: Urgent
I am running macOS Mojave 10.14.1 (same behavior on 10.14 as well).
Update
I changed nothing, everything suddenly works. I am very curious what made the difference. Will close the question, if everything keeps working.

Solution
I had the Endpoint Security VPN client installed. This activates a firewall at all times blocking some ports. Even when not connecting to a vpn server.
By shutting down the client daemon, i can access all ports again.
Steps to shutdown daemon
From: https://gist.github.com/phoob/671e65332c86682d5674
kill client and run commands to stop daemon:
sudo launchctl unload /Library/LaunchDaemons/com.checkpoint.epc.service.plist
sudo kextunload /Library/Extensions/cpfw.kext

Related

UDP port forwarding not working with Docker on Windows 10

I am running a Docker container for snmptrapd.
It runs fine on a Linux host (Ubuntu 18.04), but not on Windows (10 Pro).
Dockerfile:
FROM alpine:3.8
RUN apk --no-cache add net-snmp
COPY mibs/ /usr/share/snmp/mibs
COPY snmptrapd.conf /etc/snmp/snmptrapd.conf
COPY snmp.conf /etc/snmp/snmp.conf
EXPOSE 162/udp
ENTRYPOINT ["snmptrapd","-L","o","-f"]
We also forward UDP port 162 in the Docker run command:
docker run -d --rm -p 162:162/udp snmp_server
A simulated SNMP trap originating from inside the Windows host reaches the container correctly.
But any trap originating from outside the Windows host is not reaching the container.
It is not a Windows firewall problem, because I can run Wireshark on the Windows host and see the traps arriving, destination port UDP 162, as expected.
After the container is started, netstat on Windows shows that there is a listener on UDP port 162, bound to all interfaces:
netstat -ano | findstr 162
UDP 0.0.0.0:162 *:* 13952
UDP [::]:162 *:* 13952
Inside the container, netstat shows that there is a listener on UDP port 162, bound to all interfaces.
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 0.0.0.0:snmptrap 0.0.0.0:*
Docker version 19.03.1, build 74b1e89
I have tried:
--network=host instead of the default bridge mode;
--privileged
--cap-add NET_BROADCAST
Grasping at straws at this stage!

Able to open TCP port but not listening

Using Add rule in windows firewall, I was able to open TCP port 15537. When i am trying to executing command netstat -ano on terminal windows, this port is not listed. I tried to execute telnet command on terminal window (e.g. telnet IP port) but getting
Connecting To localhost...Could not open connection to the host, on port 15537: Connect failed
Then I downloaded PortQry application and execute it from different machine, this machine is also in the same network, the result I received was
"Not Listening".
I already spent more than 2 days and asked internal group but could not find solution.
Note: both machines are having Windows 10 OS.
No solution is needed as no problem is indicated in the question. You have opened a TCP port successfully. You have not made any attempt to cause anything to listen to that TCP port.
It's not clear what results you expected, but you got the results that you should have expected. Nothing is wrong. The port is open because you opened it. Nothing is listening on that port because you didn't set anything to listen on that port.
There may be some forwarding rules? Since the purpose of access is not on the local machine, the netstat command cannot see the port on listening, but it can see the next action based on this port, usually to do some forwarding
I am not very familiar with windows firewall configuration, but I know that if there is a forwarding rule in linux, like
-p tcp -m tcp --dport 8080 -j {other forwading chain}
we can not see 8080 listening on this host (netstat -tunpl), but telnet host:8080 may see connected
Use nmap instead of netstat for detecting opening port
nmap -p your_port_number your_local_ip
Run service on that port
For eg- In my case,in order to open port,I use
"service ssh start" or "service apache2 start "and it's open port 22 and 80 for connection respectively in my linux machine.
On using nmap in my lan network both ports opened.
Hope it help

Docker on Mac: how to test for listen port in container

I recently installed Docker native on Mac, switching over from docker-machine. I have a container with Zookeeper, which opens a port on 2181. This process can take some 10-15 seconds however.
Previously with docker-machine I used to check whether Zookeeper had started listening on the port using netcat:
nc -z 192.168.99.100 2181
Netcat returns non-zero exit code while Zookeeper is starting up and as soon as it's done, the connection succeeds and netcat returns zero.
In Docker Mac-native however, the connection always succeeds when the container is present, but during Zookeeper startup it drops the connection immediately. When Zookeeper is ready it keeps the connection open. Netcat does not see this difference and "nc -z" always returns zero.
So my question is: is there an easy way to check from outside of the container whether Zookeeper has actually started listening on the port?
If you are just checking wanna check manually , You can use telnet.
Command:
telnet localhost 80
Output:
Trying ::1...
Connected to localhost.
Escape character is '^]'.
This means that the connection was successful. The Command Usage:
telnet <address> <port>
Please note that you can only use telnet for TCP ports.
Another way would be checking the service from the container with docker exec :
docker exec <container name> "echo stat | nc <zookeeper ip> 2181"
docker exec <container name> "bash path/to/zkServer.sh status"

how to forward request to docker machine in local network in OSX

I am currently running a docker machine in local network that its IP & port is 192.168.99.100:8080
right now. I want to connect this machine from somewhere out of the local network and access it, so the best way I found is to NAT the sent request from my laptop computer to docker machine.
In other words, each request that has been sent to my laptop computer will be sent to the docker machine on its own IP and port!
I use pfctl to do this but when I check the port 8585 to find out which service is listening to this port, I can't find anything and it sounds like the requests do not arrive(get to) the destination!
I did as below:
1- csrutil disable
2- my pf role :
/etc/pf.anchors/mazafard:
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port 8585 -> 192.168.99.100 port 8080
3- my pf conf
/etc/pf-mazafard.conf
rdr-anchor "forwarding"
load anchor "forwarding" from "/etc/pf.anchors/mazafard"
and
sudo pfctl -vnf /etc/pf.anchors/mazafard
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port = 8585 -> 192.168.99.100 port 8080
and
sudo pfctl -evf /etc/pf.anchors/mazafard
fctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
No ALTQ support in kernel
ALTQ related functions disabled
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port = 8585 -> 192.168.99.100 port 8080
pfctl: pf already enabled
and
telnet 192.168.20.203 8585
Trying 192.168.20.203...
telnet: connect to address 192.168.20.203: Operation timed out
telnet: Unable to connect to remote host
My OSX v: 10.11.4
Docker version 1.9.1, build a34a1d5
Boot2Docker version 1.11.0-rc3, build

Trying to kill process on port 8000 confusion

I am writing a Ruby script that deploys a server on port 8000 in the background, and then in the foreground I issue queries to the server. After I've issued my queries I kill the server, however when I kill the server, it seems to be switching ports.
I am doing it the following way in the ruby script:
To see PID that is running on port 8000:
lsof -i:8000 -t
Result:
RUNNING ON PORT 8000: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 26364 user1 84u IPv6 199069 0t0 TCP *:8000 (LISTEN)
To kill the server I issue the command:
kill 26364
I then see if anything is running on port 8000:
# check if killed
lsof -i:8000 -t
Result:
RUNNING ON PORT 8000: COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
ruby 25560 user1 58u IPv4 199123 0t0 TCP localhost:45789->localhost:8000 (ESTABLISHED)
java 26364 user1 84u IPv6 199069 0t0 TCP *:8000 (LISTEN)
java 26364 user1 85u IPv6 199124 0t0 TCP localhost:8000->localhost:45789 (ESTABLISHED)
I only want to kill the process that is listening on port 8000,
and keep my ruby script running.
Can someone please tell me what is going on? Why is it switching ports? How can I only kill my server port?
It doesn't look to me like it's switching ports; it's still listening on port 8000. It looks to me like two things are happening:
The java process (PID 26364) is catching or ignoring the kill signal (SIGTERM), and continuing to listen on port 8000.
A ruby process (PID 25560) is making a connection to localhost:8000 (from port 45789, which was probably dynamically allocated). That is, ruby is making a normal connection to the server on port 8000.
Note that the java process owns the port 8000 end of the localhost:8000<->localhost:45789 TCP session, and the ruby process owns the port 45789 end.
Whether the ruby process's connection is somehow a result of the kill signal, or just something it happened to do at about the same time, I couldn't tell you.

Resources