2

I have a Draytek router configured to port forward SSH connections to an internal server from specific ip addresses only. Clients and myself can connect externally successfully except one who cannot connect to our router's public static ip address but to its domain name only. router.domain.com Should the router even have a domain name assigned to it?? Not really sure why they can only connect to the domain name and not the ip - Advice appreciated

Squid_Vicious
  • 87
  • 1
  • 1
  • 9
  • Is the problem that the client is unable/unwilling to ssh to an IP, but want to ssh to a hostname? Could they just add an entry to their `hosts` file? – Eric Renouf Mar 31 '16 at 12:02
  • Eric - they dont mind connecting to either hostname or ip . I would like to resolve the ip problem as it may indicate a deeper issue that may cause future headaches. We could certainly try the hosts file but is that not treating the symptom rather than the cause ? (I dont mean that in a nasty way) – Squid_Vicious Mar 31 '16 at 12:11
  • So it's not a question of the client only wanting to do it a certain way, it only works if they connect to a host name and does not work if they connect to an IP? I'm just trying to make sure I understand the problem. – Eric Renouf Mar 31 '16 at 12:13
  • yes, exactly. It only works if connecting to a hostname and wont connect to an IP. – Squid_Vicious Mar 31 '16 at 12:20
  • Huh, I wonder if they have some sort of filtering on their side. Can they reproduce the issue with `ping` against the name and the IP? If so `traceroute` might be helpful in seeing where there's a difference – Eric Renouf Mar 31 '16 at 12:27
  • yes, ping and traceroute produce the same result. I have checked firewall logs and their ip address is not present (when testing on ip address). It is not on our side as we have other incoming connections that are normal. – Squid_Vicious Mar 31 '16 at 12:48

1 Answers1

2

Based on the limited information in the question it is not possible to say for sure why connectivity using a hostname works but connecting to the very same server using an IP address does not work.

However I guess the most likely explanation is the client is depending on DNS64+NAT64 in order to connect to the server. Since IPv4 addresses ran out, deployments of various kinds of CGN solutions have become more common. One of them is DNS64+NAT64, and those has the limitation that clients cannot connect to IPv4 servers by IP address.

What will happen when such a client connects to an IPv4-only server is this:

  • Client sends AAAA query for server.example.com
  • DNS64 server sends AAAA query for server.example.com
  • Authoritative server sends NOANSWER.
  • DNS64 server sends A query for server.example.com
  • Authoritative server responds with 192.0.2.1
  • DNS64 translates 192.0.2.1 into 64:ff9b::192.0.2.1
  • Client connects to NAT64 on address 64:ff9b::192.0.2.1
  • NAT64 translates 64:ff9b::192.0.2.1 to 192.0.2.1

If the client is OpenSSH, you can use ssh -v on the client side to see which IP address it is connecting to. If the server is IPv4 only, and the client connects to an IPv6 address when given the hostname, you will know that the client is depending on DNS64+NAT64.

Possible mitigations if you cannot connect to IP address due to NAT64:

  • Enable IPv6 on the server and create an AAAA record alongside the current A record. The client can now connect directly to the IPv6 address of the server. This is the preferred method even if the client keeps using connections by hostname, because it will remove the dependency on the NAT64.
  • Leave it as is. You said connections using the servers hostname works. So DNS64+NAT64 is working as intended and there is no immediate need to change anything. In most cases connections using a hostname is considered better practice than connecting directly to the IP address, so there is no real reason to stop using the hostname.
  • Have the client connect using hostname once to learn the IPv6 address that the DNS64 mapped to, and then keep connecting through the NAT64 using this IPv6 address. (Works but seems a bit silly)
  • Have the client use NAT464. This is a solution intended for the case where the client software only supports IPv4 but the client is connected to an IPv6-only access network. However if connections by hostname already works, then you don't need NAT464 and you are better off using one of the other solutions.
kasperd
  • 29,894
  • 16
  • 72
  • 122
  • Will certainly look into your answer kasperd. We have only ipv4 addresses and our ISP has not yet rolled out ipv6 addresses . – Squid_Vicious Mar 31 '16 at 13:31
  • @Squid_Vicious If the client is on an IPv6-only access network with DNS64+NAT64, then they will see the symptoms you described. More details about what is seen from the client side can confirm whether this is the case. For example output using `ssh -v` will surely tell you something. – kasperd Mar 31 '16 at 13:34