Port Forwarding Fails on AEBS

FYI ... Apple uses the term "default host" to mean the same thing as a DMZ. When you place a host device in a DMZ all of its ports are open to the Internet. Effectively nullifying any port mappings that you set of for that same host. If you goal is to use port mapping to only open a select number of ports then you should disable the "default host" option.

I then checked all ports from 80 to 89 and only the working port 82 for my weather station was successful.

If you telnet to the IP camera on port 89 and it does not respond then it is not configured correctly.

This is the advantage of using telnet to the specific port.

I suspect it is working on the local LAN because it is working on port 80.

And I think the setup in the Airport is fine.

When you place a host device in a DMZ all of its ports are open to the Internet. Effectively nullifying any port mappings that you set of for that same host.

Using DMZ is only intended as a test.. as it will then open all ports.. what we are trying to check is that the airport is functioning correctly. Since it fails as does Telnet then I am pretty sure the issue is the camera is not actually responding on the port you set.

It would seem unlikely if port 82 is working that 83 is not ... when the config is accepted without error in the airport.

Are you sure the camera is not responding on port 80 in local lan rather than port 83?

I am rereading the question and am now a bit confused.

I have tried resetting the AEBS, and also resetting to factory settings without success. Port 82 works but I am unable to add any additional rules.

Unable to add rules.. is completely different to having no issues with the config being accepted but not working.

No errors are reported from the Airport Utility program and everything appears OK when the config is viewed.

So you mean the rule is not accepted. Is the IP of the camera correct?

Usually a rule will work unless the port is already taken.. try a different port.. one above 1024.

Try from a computer using telnet to test the port.

This is a great and simple way to test port opening.

eg airport router has 5009 open for configuration.

If I telnet to it.. will get a connection.. but of course nothing else. The connection will drop out in a few minutes. Or close the terminal.

$ telnet 192.168.2.201 5009

Trying 192.168.2.201...

Connected to 192.168.2.201.

Escape character is '^]'.

https://support.microsoft.com/en-au/help/187628/using-telnet-to-test-port-3389-f unctionality

https://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-sess ion-2/

Try from a computer using telnet to test the port.

Unfortunately, Apple has removed telnet from macOS High Sierra. I believe they removed ftp as well. Sad!

There are two potential workarounds:

1. If you have a Time Machine backup old enough to still have either app in the /usr/local/bin folder, you can restore them.
2. Download from GNU.

Unfortunately, Apple has removed telnet from macOS High Sierra.

Unbelievable. Testing for ports via telnet is one of those tricks by network admins the world over. We all know it is not secure but to remove it completely is just dumb. At least make it optional install.

I have checked the camera and confirmed the IP and port are correct.

The advantage of running Telnet is you check the port is actually more than open.. it is responding.

Just as a test.. try using default host.

Put in the IP of the camera and then try again.. this is not suitable for long term.. but it will check if there is something strange happening.

This is Apple's version of DMZ.

Tell me what happens.

A screenshot of the actual port forwards might also help.. you can blank out details if you must.. but private IP are not routable so blanking them out is not required.

I do think using a different port.. above 1024 can help.

My IP camera works perfectly on my LAN and I have configured the AEBS for it in exactly the same way as my WeeWx Pi to no avail.

Port mapping is only required if you need to traverse a firewall. That could be a NAT or dedicated hardware firewall on a router or a software firewall on a host computer.

If you can access your camera successfully on the local network, then you know that a software firewall is not the issue. When you can access the camera from a remote location, then either the firewall or you WAN-side IP address of the router will, most likely, be the culprit.

Most consumer-grade Internet service comes with a dynamic WAN-side (public) IP address that starts with something other than 10, 172, or 192. If yours does, you don't need to post it. If it does start with one of those address, then it is not publicly reachable and may be the reason for the issue. On the other hand, business-grade service typically comes with a static public IP address. Do you know which one that you have?

There are Gremlins for sure.. !!

Thanks for the feedback. Nice to know we are not all going mad.. just the machines.. !!