¿Es posible bloquear usuarios específicos que se conectan a Internet detrás de la misma puerta de enlace con NAT?

En el caso general, no.

En algunos casos específicos, puedes. Por ejemplo, si está ejecutando un servidor web y el NAT de la puerta de enlace modifica las solicitudes HTTP para incluir un encabezado "X-Forwarded-For", puede usar la cabecera XFF para distinguir y bloquear computadoras individuales (suponiendo, por supuesto, que la puerta de enlace es honesto).

Si pudiera detectar de manera confiable el puerto de origen que se está utilizando, podría bloquear todo el tráfico de ese puerto de origen. A menudo, NAT diferencia entre usuarios por puerto. El problema es que los puertos de origen pueden cambiar, por lo que tendría que detectar el tráfico de ataque únicamente mediante un identificador cambiante.

Estoy de acuerdo con Mark; en el caso general no.

Puede 'intentar' hacerlo usando características específicas para un usuario (UserAgent diferencias / XFF / lo que sea), pero ninguna de estas características es confiable, y la mayoría son modificadas trivialmente por el usuario.

Dependiendo de cómo lo esté haciendo, podría exponerse a ataques de agotamiento de recursos si las personas falsifican un millón de cadenas XFF o UA, etc., para ver qué hace su sistema ... y su sistema intenta almacenar & registra todo eso.

Hay una solución, pero no sé si es viable en su caso, ya que no tengo la imagen completa: certificados del lado del cliente .

En pocas palabras, necesitará un firewall de aplicación y para mover la validación de SSL en el perímetro. Si el cliente está autorizado, tienen acceso. Si no (y por defecto) están bloqueados.

Obviamente, esto abre otra lata de gusanos, ya que tendrás que administrar certificados, mantener actualizada tu lista de revocaciones, etc.

Además, como han sugerido otros, corre el riesgo de ser víctima de un ataque de agotamiento de recursos. En este punto, vale la pena considerar si el costo de configurar una arquitectura como la que describí anteriormente puede ser más que simplemente escalar su servidor o trasladarlo a un proveedor más capacitado, tal vez uno de los que tienen "protección" DDoS.