[snvzz]

Note this is only an issue if not using IPv6.

CGNAT is for access to legacy IPv4 only.

[rnhmjoj]

Well, for different reasons, but you have similar issues with IPv6 as well. If your client uses temporary addresses (most likely since they're enabled by default on most OS), OpenSSH will pick one of them over the stable address and when they're rotated the connection breaks.

For some reason, OpenSSH devs refuse to fix this issue, so I have to patch it myself:

    --- a/sshconnect.c
    +++ b/sshconnect.c
    @@ -26,6 +26,7 @@
     #include <net/if.h>
     #include <netinet/in.h>
     #include <arpa/inet.h>
    +#include <linux/ipv6.h>
     
     #include <ctype.h>
     #include <errno.h>
    @@ -370,6 +371,11 @@ ssh_create_socket(struct addrinfo *ai)
      if (options.ip_qos_interactive != INT_MAX)
        set_sock_tos(sock, options.ip_qos_interactive);
     
    + if (ai->ai_family == AF_INET6 && options.bind_address == NULL) {
    +  int val = IPV6_PREFER_SRC_PUBLIC;
    +  setsockopt(sock, IPPROTO_IPV6, IPV6_ADDR_PREFERENCES, &val, sizeof(val));
    + }
    +
      /* Bind the socket to an alternative local IP address */
      if (options.bind_address == NULL && options.bind_interface == NULL)
        return sock;

[Dylan16807]

The temporary address doesn't stay active while there's a connection on it? I think that would be the actual "fix".

[rnhmjoj]

I think it does, but that's not the issue: if the interface goes down all the temporary address are gone for good, not just "expired".

[Dylan16807]

If you're on a stable address, and the interface goes down, will it let your connection/socket continue to exist?

Because if the connection/socket gets lost either way, I don't really care if the IP changes too.

[rnhmjoj]

I'm not sure what happens to the socket, maybe it's closed and reopened, but with this patch I have SSH sessions lasting for days with no issues. Without it, even roaming between two access points can break the session.

[gspr]

Interesting! Is there anywhere a discussion around their refusal to include your fix?

[rnhmjoj]

See this, for example: https://groups.google.com/g/opensshunixdev/c/FVv_bK16ADM/m/R...

It boilds down to using a Linux-specific API, though it's really BSD that is lacking support for a standard (RFC 5014).

[lxgr]

It would also seem to break address privacy (usually not much of a concern if you authenticate yourself via SSH anyway, but still, it leaks your Ethernet or Wi-Fi interface's MAC address in many older setups).

[gspr]

This is a good argument for not making it the default, but it would be nice to have it as a command line switch.

[rnhmjoj]

Well, yss, but SSH is hardly ever anonymous and this could simply be a cli option.

[lxgr]

Not anonymous, but it's pretty unexpected for different servers with potentially different identities for each to learn your MAC address (if you're using the default EUI-64 method for SLAAC).

[dsl]

This is a very common misconception. The issue is not IPv4 or CGNAT, it's stateful middleboxes... of which IPv6 has plenty.

The largest IPv6 deployments in the world are mobile carriers, which are full of stateful firewalls, DPI, and mid-path translation. The difference is that when connections drop it gets blamed on the wireless rather than the network infrastructure.

Also, fun fact: net.ipv4.tcp_keepalive_* applies to IPv6 too. The "ipv4" is just a naming artifact.

[lxgr]

Mobile carriers usually have stateful firewalls for IPv6 as well (otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan), so it's an issue just the same.

The constrained resource there is only firewall-side memory, though, as opposed to that plus (IP, port) tuples for CG-NAT.

[withinboredom]

> otherwise you can get a lot of random noise on the air interface, draining both your battery and data plan

I highly doubt you get "random" data over ipv6. There are more ipv6 addresses than there are atoms on the planet.

[lxgr]

Yes, but they're not randomly distributed across the entire number space.

For example, receiving traffic from a given address is a pretty good indicator that there's somebody there possibly worth port scanning.

And where there has once been somebody, there or in the same neighborhood (subnet) might be somebody else, now or in the future.

[withinboredom]

Then it isn't random noise. It is determined by your own actions.

[lxgr]

Or my predecessor/address space neighbor, or that of somebody using my wireless hotspot once, or that of me clicking a random link once and connecting to 671 affiliated advertisers's analytics servers...

I think a default policy of "no inbound connections" does makes sense for most mobile users. It should obviously be configurable.