Not with your address and port likely, but some filtering software or hardware, which is filtering out connections from these ap1’s IPs and drops them. It could be a firewall or DDoS protection on your router (or another throttling “feature”), some device in your network (like PiHole), firewall on your host with nodes, or advanced antivirus software, or even your ISP.
If you use DDNS hostname, it must be reliable resolved to your public IP:
nslookup your.ddns.hostname 8.8.8.8
It is on the satellite side that there are different interfaces:
Non-authoritative answer:
Name: ap1.storj.io
Address: 35.189.132.42
Name: ap1.storj.io
Address: 34.80.215.116
Name: ap1.storj.io
Address: 34.92.204.130
Is it the node that connects to these IP addresses, or do these addresses connect to the node?
The administrator checked the communication logs for the last 2 days and does not see connections from the node to these IPs.
It’s both. Your node connect the satellite to perform a check-in (give it a report regarding free space, sending unsent orders and providing its external address and port for the contact).
Then satellite is trying to contact the node with provided contact information and report an error to the opened channel from storagenode to the satellite, if there is an error or commit that the provided external address is available and responding properly. It also provides information about earnings and reputation, disk space and bandwidth usage from confirmed orders.
So the filtering is happened when the satellite is trying to contact your node, it could be a wrong contact address (or the satellite cannot resolve the provided hostname and tried to use the cached IP for this hostname and it’s different from the current one) or something is blocking traffic from these IPs to the node’s contact address and port.