If it's configured to do NAT instead of routing, then it's not being a router. Routing is a job and "router" describes a role, not a static property of a box. Like firewall, bridge, etc.
Routing is defined as shuffling packets where they need to go unmolested - without messing with the address or port fields. It's specced in the IP RFC's. If you're mangling the traffic, you're violating router requirements.
In retrospect, I think using TCP_KEEPALIVE would be a better solution to this specific use case. Are TLS heartbeats truly indistinguishable from normal traffic?
My understanding, from the heartbleed page, is that the packets for the heartbeat have a specific packet type identifier and that you can use this to train an IDS to watch for the heartbleed attack.
Sure it does. SSH to a remote host, do nothing, then disconnect the cable connected to your router's uplink. SSH (for example) won't notice as long as you do nothing in your SSH session.
On some connections where I have SSH keepalives disabled, I can suspend my laptop, go for a drive around town with it, come home, resume, and still have my session connected.
TCP absolutely needs a heartbeat/keepalive to tell if the connection went down. There is no way to distinguish between no traffic being sent and session going down uncleanly. It's very common that some NAT drops the binding of an idle TCP connection and the peers don't discover that until their timeouts expire (could be anything from minutes to hours).
If you want to know if the connection went down in a reasonable timeframe e.g tens of seconds, then you need to implement heartbeating over TCP. This is the first thing any new protocol on TCP usually does.
