Hmm... the explanation there is just as confusing.... Any other topics to point me to?
Hi chertel,
from reading your problem description, I guess the explanation lies in a different NAT "hair pinning" behaviour of your DIR-655 router and hence, in addition to all differences explained elsewhere there is another one:
1) "Port Forwarding" obviously uses a NAT hairpinning behaviour of "Internal source IP address and port" (Edit: or doesn't do hairpinning at all)
2) In contrast "Virtual Server" obviously uses a NAT hairpinning behaviour of "External source IP address and port"
For an explanation of those terms read
chapter 6 of
RFC4787. In your case X1'=X2' is valid.
This would perfectly explain the observed behaviour. And if this explanation is correct, it also proves that D-Link's NAT implementation in case of "Port Forwarding" does not conform to RFC4787 (and in your case RFC5382 respectively, see
Edit below), which clearly states:
(Edit:
REQ-9: A NAT MUST support "Hairpinning")
REQ-9a: A NAT Hairpinning behavior MUST be "External source IP address and port"In order to allow a communication from your internal computers to your internal HTTP and SSH server within your original configuration using "Port forwarding", you must prevent your clients from using the external address, because in this case your router uses the wrong NAT hairpinning behaviour. To achieve this you must configure your clients in a way, that the dyndns name of your server gets resolved to its internal address, e. g. by configuring HOSTS files. This would lead to a direct communication between your clients and your server without any participation of your router.
PT
Edit: Sorry, I referenced the wrong RFC which explains NAT behaviour for UDP. But there is another one explaining NAT behaviour for TCP: Read
chapter 7.2 in
RFC5382 which states the same requirement for NAT Hairpinning behavior now numbered REQ-8 and REQ-8a respectively.