Port-forwarding, UPNP, NAT-PMP issues I can't resolve...
-
@johnpoz said in Port-forwarding, UPNP, NAT-PMP issues I can't resolve...:
Thanks again for your help in nailing down the cause, much appreciated...
Your first image there shows the client sending RST!!! So no the port is not going to show open because the client basically said in a nutshell - F OFF!!
Do you have any idea why it might be sending this "RST"? Is it likely the OS sending it or Transmission? Any ideas on how one might fix the problem?
You can not actually validate UDP ports with sites like can you see me org..
I think the problematic packet and the RST are a TCP packet... no?
-
The RST is tcp yes... But you can not actually know if something is working or not with canyouseeme if its UDP. P2P is going to normally be tcp and udp..
As to why your client is answer back with RST, no idea - but that is not anything to do with with pfsense.. You would have to get with mac os users or forum support your transmission client, etc.
What OS you running on this mac mini? Is apple or a linux OS? If linux could be of some help, but I don't use OS X so not going to be much help trying to figure out what is sending RST... What I can tell you is that is BAD practice.. Especially to a public IP.. sending RST to IP that is on the same local network is ok - but answering RST to some ip that is not local is bad.. Firewalls don't normally do that, because its bad idea and if under attack for some sort of dos attack your just going to be hurting yourself sending a RST..
Is it sending a icmp redirection as well? Sniff for the IP on the pfsense lan and do your test again.. Any as the protocol, ipv4
-
@johnpoz said in Port-forwarding, UPNP, NAT-PMP issues I can't resolve...:
As to why your client is answer back with RST, no idea - but that is not anything to do with with pfsense.. You would have to get with mac os users or forum support your transmission client, etc.
Thanks. Ugh, I think this is going to be hard to nail down. I'm running Mac OSX 10.12.
Is it sending a icmp redirection as well? Sniff for the IP on the pfsense lan and do your test again.. Any as the protocol, ipv4
I don't think so. Here is an all ports capture of the Mac Mini.
I have tried complete uninstall and reinstall of Transmission but it didn't help. I am thinking it must be something in the OS itself, rather than Transmission, because the same issue happens when I try to get remote access to Plex media server....
PS - Ignore the change from 192.168.0.4 to .2 - that was me changing the IP for testing, it's the same machine.
I've posted for advice on the r/osx subreddit here: https://www.reddit.com/r/osx/comments/9adpuk/osx_networking_issue_port_forwards_failing_rst/
-
I would have to guess your firewall is still running.. But in a bad configuration - what OS are you running?
Did actually validate listening on those ports with say a netstat -an.. This command works on any os really.. window, linux, os
Many OSes if hit directly with no firewall will send RST when port is not listing..
Im not listening on 444, if I forward 444 to my windows machine it sends back a RST..
-
@johnpoz said in Port-forwarding, UPNP, NAT-PMP issues I can't resolve...:
I would have to guess your firewall is still running.. But in a bad configuration - what OS are you running?
Did actually validate listening on those ports with say a netstat -an.. This command works on any os really.. window, linux, os x
I did a netstat and traceroute, and posted the results in my post on Reddit here (I didn't want to clog up this forum any more seeing as it's clearly an OSX issue not pfSense): https://www.reddit.com/r/osx/comments/9adpuk/osx_networking_issue_port_forwards_failing_rst/e4urk4v/
I tried two other things: Using a different user account on the Mac Mini = same problem. Booting the mac Mini from a clean OSX install on external drive = NO problem. This clearly indicates to me it's an issue with the OSX install... I think when I have time I'll have to nuke the whole OS and start all over again, but that's going to take some serious time so I'll have to put that plan on hold.
Appreciate all the help - at least I don't need to spend any more time investigating pfSense, switches, etc.
-
Those are netstat -r, just showing your routes... Not what your machine is actually listening on.. For example
See here listening on 3389 (remote desktop) on my windows machine
actually validate your machine is listening on the port you think it is! tcp will send RST when not listening.. But firewall normally default to "stealth" mode..
-
I was unable to do netstat with the "find" addition like in your screenshot, maybe syntax is different in OSX. But when I do "netstat -an" and then search for 10002 in the long list of output, I see these items (Transmission port is now set to 10002):
Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp6 0 0 *.10002 *.* LISTEN tcp4 0 0 *.10002 *.* LISTEN tcp4 0 0 192.168.0.2.10002 185.230.125.35.37657 TIME_WAIT tcp4 0 0 192.168.0.2.10002 87.67.39.175.56083 TIME_WAIT tcp4 0 0 192.168.0.2.10002 84.104.165.198.63194 TIME_WAIT tcp4 0 0 192.168.0.2.10002 82.173.50.104.57184 TIME_WAIT udp4 0 0 *.10002 *.* -
Well yeah its different in windows ;)
So something is listening on 10002, And looks like your in a time_wait connection with 4 other IPs..
Time wait means that hey this connection should be close but will leave the socket open until the time out..
You sure you don't have any sort of ACL or something in the software that says who can talk to it? Do you see the same thing for your plex?
Normally!!! If you your in a time_wait state and you get more traffic on that same conversation setup ie same IP and same port as source the server (listening side) would for sure send back a RST.. Telling you hey this conversation is closed..
If the socket was in in time_wait and it got an RST then I believe it should close right then.. You seeing sockets in time_wait is another wrench in the issue..
But again - this has zero to do with pfsense, or connectivity at all.. And something with the OS or application on the box.. Pfsense did its job it sent the SYN through.. It can not help the that client sends back RST..
-
Ok I worked out the OSX netstat syntax to focus on particular ports. Here is for Transmission and then for the Plex port:
mediamac:~ ben$ netstat -an |grep .10002 tcp4 0 0 192.168.0.2.10002 94.245.58.211.60686 SYN_RCVD tcp4 0 0 192.168.0.2.10002 178.82.144.61.60173 ESTABLISHED tcp6 0 0 *.10002 *.* LISTEN tcp4 0 0 *.10002 *.* LISTEN tcp4 0 0 192.168.0.2.10002 84.104.165.198.58890 TIME_WAIT udp4 0 0 *.10002 mediamac:~ ben$ netstat -an | grep .32400 tcp4 0 0 127.0.0.1.32400 127.0.0.1.51153 ESTABLISHED tcp4 0 0 127.0.0.1.51153 127.0.0.1.32400 ESTABLISHED tcp4 0 0 127.0.0.1.32400 127.0.0.1.51096 ESTABLISHED tcp4 0 0 127.0.0.1.51096 127.0.0.1.32400 ESTABLISHED tcp4 0 0 127.0.0.1.32400 127.0.0.1.49318 ESTABLISHED tcp4 0 0 127.0.0.1.49318 127.0.0.1.32400 ESTABLISHED tcp46 0 0 *.32400 *.* LISTENSo it seems same for Plex. And agreed nothing to do with pfSense....
-
Looks like in your 10002 your in syn_rcvd state from that 1 IP.. And do have an established connection with 178.82.x.x and in a time wait for another..
So your going to have to work out whatever is wrong if your client or ACL... Possible your running a block list in transmission, you know keep the "spies" out... isn't there large black lists of the bad guys to try and keep out of the swarm?
As to plex.. Maybe something common with firewall running that you think you turned off, or 3rd party security software you running on the box?
-
SOLVED.....
On the offchance it helps someone else, in the end I fixed it by...
- Deleting the OSX firewall preference .plist located at /Library/Preferences/com.apple.alf.plist
- Cleaning system & user caches
- Restarting
- Enabling the firewall
- Doing this all a couple of times...
What's strange is this whole time the firewall was OFF in System Preferences, so I've no idea why this should affect things. In addition, I had previously during testing deleted this file but seems you have to do it and restart, maybe more than once, to really clear it.
Thanks for all the patient help in narrowing down the problem, really much appreciated....
