Hello,
the problem you’re experiencing is called “NAT reflection”.
What happens?
Let’s say your internal subnet is 10.1.1.0/24 and the host that tries to access your NC via the outside ip address is 10.1.1.100. The internal ip address of the the NC box is 10.1.1.11.
The host checks the external IP address of the external hostname, e.g. nextcloud.dyndns.com points to 1.2.3.4, and then connects there.
So a packet goes out from: 10.1.1.100 to 1.2.3.4.
As your host is not part of the 1.2.3.4 subnet it forwards the packet to the router.
The router gets the packet, sees that it holds the ip address 1.2.3.4 and applies it’s NAT rules. As reverse NAT just alters the DESTINATION address the router rewrites the packet and:
from 10.1.1.100 to 1.2.3.4
becomes
from 10.1.1.100 to 10.1.1.11
Now the router forwards the packet to 10.1.1.11.
The NC box (10.1.1.11) picks up the packet, opens the connection and sends the SYN-ACK back. The packet gets generated in the box’ kernel and then hits the kernel’s routing table. And now … that’s where the problem kicks in…
The NC box’ routing table knows that 10.1.1.100 belongs to its own subnet. So instead of sending the answer back to the router so that the router can apply the rewriting of the packet and send it back to your client, it sends it DIRECTLY to your client looking like this:
from 10.1.1.11 to 10.1.1.100
Now your client on the other hand doesn’t have a connection to 10.1.1.11. It’s waiting for a response from 1.2.3.4 and that never arrives. So it ditches the packet from 10.1.1.11 and continues to wait for the answer from 1.2.3.4.
What can you do?
Well… You can either enable source nating for incoming connections that would change the source ip address to the router’s address and the answer would flow back in the right direction BUT in your access logs of your webserver all you will see is access from 10.1.1.1 … And as there is not HTTP header inserted, because packet filters don’t do that, you have no chance of recovering the original host that tried to access your box.
Or you assign your NC box an ip address in another subnet. Let’s say 10.1.2.0/24. Also add the subnet to the router and then forward the requests to 10.1.2.11 instead of 10.1.1.11. That way 10.1.2.11 needs to reply to 10.1.1.100 and as a direct connection between 10.1.2.11 and 10.1.1.100 is not possible in two different /24 it needs to send the packet back to the router. And tada. NAT reflection problem solved and you can see the external ip address that tries to access your NC box in the logs again.
Give it a shot. I’m pretty certain it works 
Cu