NAT pois todo mundo merece um IP privado

NAT, porque expor o seu IP na internet é pedir pra ser hackeado. Nem todo mundo precisa saber onde seu roteador mora.

NAT pois expor seu IP por aí é pedir pra ser espionado

NAT é aquele recurso da rede que ninguém vê, ninguém elogia, mas que segura as pontas pra internet não virar uma bagunça ainda maior.

Enquanto você está aí assistindo Netflix na rede Wi-Fi da sua casa, o NAT está nos bastidores fazendo um malabarismo digno de Las Vegas só pra manter sua navegação funcionando direito — e, de quebra, escondendo seu IP da curiosidade alheia.

Por que raios o NAT existe?

Porque alguém lá atrás percebeu que, do jeito que a coisa ia, o estoque de endereços IPv4 ia acabar mais rápido que bateria de celular novo.

Então, inventaram a NAT pra resolver isso: transformar um monte de endereços IP privados (aqueles 192.168.x.x que você já viu no seu roteador) em um único IP público visível na internet.

Em bom português: é como se toda sua casa navegasse com uma só máscara, enquanto cada dispositivo vive sua própria vida internamente.

Bonito, né?

Como o NAT funciona?

Simples — ou quase.

Imagine que o roteador é um secretário de alto desempenho.

Ele recebe pedidos da sua geladeira, do seu celular, do notebook, do videogame, e empacota tudo como se fosse dele.

Lá fora, na internet, ninguém vê quem fez o pedido.

Só vê o endereço do secretário.

Quando a resposta chega, o NAT desfaz o pacote e entrega cada coisa pro dono certo.

É isso que ele faz.

O tempo todo.

Sem errar.

E sem receber um obrigado.

Ah, então o NAT também é segurança?

Sim.

Acidentalmente genial.

Além de poupar endereços, o NAT também atua como uma camuflagem: o que está na sua rede interna fica invisível pra quem está de fora.

É tipo uma cerca elétrica virtual — não impede 100% os ataques, mas já espanta muito curioso metido a hacker.

Com o NAT, sua rede não sai por aí gritando “olha meu IP, pode me invadir!”.

E como que configura essa belezura?

Agora que você se empolgou, vem a parte técnica.

Configurar NAT tradicional exige duas coisas: uma interface pra dentro (sua rede local) e outra pra fora (a internet).

Depois, você cria regras pra dizer quem pode sair e como sair.

Simples… até você se deparar com mil parâmetros, listas de acesso, pools de IP, e aquele sentimento de “talvez eu devesse ter virado biólogo”.

Tem também a tal da NAT Virtual Interface (NVI), que simplifica algumas dores, mas exige atenção redobrada.

Porque com grande poder vem grande responsabilidade — e mais risco de quebrar tudo se errar um comando.

E o NAT da Cisco, é diferente?

Depende do humor do roteador.

A NAT no Cisco IOS funciona de um jeito, o Cisco PIX (firewall) de outro.

Alguns modelos aceitam tudo, outros só certas aplicações.

Leia a documentação antes de sair configurando no grito.

E se você não tem login na Cisco, nem tenta acessar os guias — eles guardam tudo a sete chaves.

NAT faz balanceamento de carga? Faz. NAT funciona com IP fixo? Também. NAT em rede Wi-Fi pública? Vai fundo.

Se você acha que é só pra compartilhar IP, está enganado.

Ele também consegue distribuir conexões entre servidores internos, ajudar usuários com IP estático em rede pública, controlar quantas traduções simultâneas rolam no roteador e até lidar com vírus e ataques de negação de serviço.

É quase um canivete suíço da rede.

Mas e quando o IP se repete? Sobreposição de IP?

Aí é quando a coisa fica divertida — ou catastrófica.

Quando duas redes têm os mesmos IPs privados (tipo quando duas empresas se fundem e ambas usam 192.168.0.0/24), é como dois casais chamando o filho de “Joãozinho” e depois indo no mesmo parquinho.

Caos.

Ele resolve isso interceptando as conversas e ajustando os endereços e respostas DNS pra que ninguém brigue.

Milagre?

Quase.

E quanto NAT é demais?

Depende do roteador.

Cada tradução consome memória (cerca de 312 bytes por sessão), então não adianta querer 1 milhão de sessões num roteador de entrada.

Planejamento é tudo.

E claro, se você for chique e usar Cisco IOS moderno, pode até limitar a taxa pra evitar sobrecarga — ou seja, NAT com freio e controle de velocidade.

---

Como é a ‘cara’ desse troço?

O NAT não é glamouroso.

Não tem interface legal, nem vira assunto em mesa de bar.

Mas sem ele, sua casa não teria internet.

Seu roteador estaria exposto feito celebridade em escândalo.

E seus dispositivos privados estariam na mira de qualquer um com um escâner de IP.

Então, da próxima vez que a internet cair e você for xingar o roteador, lembra: o NAT está lá.

Trabalhando.

Escondendo seus pecados digitais do mundo exterior.

Entenda (de uma vez por todas) o que é inside, outside, local e global — sem bullshit

Você já deve ter topado com essa sopa de letrinhas quando mexe com NAT: Inside Local, Inside Global, Outside Local, Outside Global.

E se você achou isso confuso… parabéns!

Está completamente certo.

Não porque é difícil, mas porque a documentação técnica muitas vezes faz parecer que estão falando em klingon.

Mas calma.

Vamos descomplicar isso aqui.

De forma didática, ácida e direta ao ponto.

Afinal, NAT já é um mal necessário, então não precisa ser também um enigma do Oráculo de Delfos.

---

Antes de começar: o que você realmente precisa saber?

Você não precisa de mil pré-requisitos.

Não precisa saber Lua, Java e nem fazer yoga.

Só precisa entender como o NAT enxerga a rede e como os endereços mudam de nome dependendo de onde estão e quem está olhando.

Ah, e antes que você pense em seguir esse guia num ambiente de produção sem pensar: não faça isso.

Esse post foi baseado em um laboratório com tudo resetado.

Se sua rede está rodando, faça backup, tome café, respire fundo.

Depois, siga.

---

NAT e seus 4 cavalos do apocalipse: Inside/Outside + Local/Global

A Cisco inventou esses termos e jogou no mundo como se fossem autoexplicativos.

Não são.

Vamos aos “quatro evangelistas” do NAT:

🧠 Inside Local

O endereço IP que o host interno acha que tem.

Geralmente um IP privado, tipo 10.10.10.1.

O host nem imagina que, lá fora, ele tem outro nome.

Na prática, é o IP que está na NIC da máquina ou o que ela pegou via DHCP.

🌍 Inside Global

O endereço que o mundo exterior vê quando o host interno tenta sair.

É o IP “famosinho” que o NAT coloca no lugar do Inside Local.

Geralmente um IP público, ou algo que o roteador NAT decide jogar no mercado internacional de pacotes.

---

🔍 Outside Local

O jeito que o IP de fora aparece para a rede interna.

Sabe quando o servidor externo 172.16.68.1 chega e você, aqui dentro da sua DMZ, vê ele como 10.10.10.5?

Pois é.

Esse é o Outside Local — o endereço maquiado que o NAT deu pro visitante.

🛰 Outside Global

O IP de verdade do host lá fora.

É o endereço real do servidor externo.

Geralmente um IP público que o outro lado configurou corretamente e com orgulho.

---

Entendendo a dança dos pacotes

Pra facilitar, pensa assim:

• Local = IPs que aparecem dentro da sua rede.
• Global = IPs que aparecem fora da sua rede.

Agora misture com o “Inside” e “Outside”, que dizem de onde veio ou para onde vai o pacote:

• Um pacote que sai de dentro da rede começa com um Inside Local e vai para um Outside Local.
• Quando ele cruza a fronteira (aka roteador NAT), vira um pacote com Inside Global indo para um Outside Global.

Inverte isso quando o pacote vem de fora pra dentro.

Simples?

Mais ou menos.

Mas necessário? Infelizmente, sim.

---

Topologia: o laboratório da sanidade

Imagine essa configuração:

PC1 (10.10.10.1) --- [Roteador NAT] --- Internet (172.16.68.0/24)

Agora o roteador NAT faz a mágica negra dele:

ip nat inside source static 10.10.10.1 172.16.68.5

O que isso quer dizer? Simples:

• Quem tá dentro (10.10.10.1) agora é conhecido como 172.16.68.5 para o mundo externo.
• Quando alguém do lado de fora tenta falar com 172.16.68.5, o NAT responde: “Ah, isso aí é o 10.10.10.1, deixa comigo.”

Interfaces:

interface s0 ip nat inside interface s1 ip nat outside

Verificação com show ip nat translations:

Pro Inside global Inside local Outside local Outside global --- 172.16.68.5 10.10.10.1 — ---

Quando rola tráfego real (tipo um ping), aparece isso:

icmp 172.16.68.5:15 10.10.10.1:15 172.16.68.1:15 172.16.68.1:15

A mágica está na tradução dos IPs.

O NAT pega um IP interno e transforma em um IP “vendável” pro mundo.

Nada muito glamouroso, mas funcional.

---

Agora vamos inverter o fluxo (porque a dor nunca vem só)

Digamos que você queira que um host externo seja acessível com um IP “legal” aqui dentro.

Você faz:

ip nat outside source static 172.16.68.1 10.10.10.5

Resultado?

O mundo vê o servidor externo como 172.16.68.1, mas aqui dentro, a gente finge que ele é 10.10.10.5.

Pura encenação de rede.

Tradução NAT:

Pro Inside global Inside local Outside local Outside global --- --- 10.10.10.5 172.16.68.1

Com tráfego real:

icmp 10.10.10.1:37 10.10.10.1:37 10.10.10.5:37 172.16.68.1:37

---

O tudo junto misturado: Inside, Outside, Local, Global — no mesmo pacote

Sim, você pode (e provavelmente vai ter que) configurar ambos os lados:

ip nat inside source static 10.10.10.1 172.16.68.5 ip nat outside source static 172.16.68.1 10.10.10.5

Agora o roteador NAT vira uma central de mentiras:

• O host interno 10.10.10.1 acha que tá conversando com 10.10.10.5.
• O host externo 172.16.68.1 acha que tá conversando com 172.16.68.5.
• Na verdade, o tráfego é uma dança de máscaras entre identidades falsas.

---

Conclusão amarga, mas útil

NAT é tipo um teatro de marionetes onde todos os IPs usam máscaras.

Saber quem é quem depende de onde você está e pra onde está olhando.

Resumo para colar no datacenter:

Termo	Significado Claro
Inside Local	IP real do host interno (antes da tradução)
Inside Global	IP “público” do host interno (depois da tradução)
Outside Local	IP do host externo visto pela rede interna
Outside Global	IP real do host externo (lá fora, sem maquiagem)

---

Se NAT fosse uma novela, seria cheia de traições, disfarces e trocas de identidade.

A diferença é que, no seu ambiente de produção, não dá pra chamar o roteador de volta do intervalo comercial.

Ou você entende o papel de cada um, ou os pacotes vão se perder — e com eles, sua sanidade.

O pesadelo do “conjunto de regras” — explicado sem rodeios

Se você já configurou NAT num firewall Juniper (ou pior, teve que entender as regras de alguém que fez isso às 2h da manhã), já sabe: a lógica por trás dos conjuntos de regras e das regras dentro dos conjuntos de regras parece ter sido escrita por alguém que odeia a humanidade.

Mas calma.

Respire.

Vamos quebrar isso aqui no facão da realidade.

---

Começando pelo básico (ou quase)

No maravilhoso mundo do NAT, tudo gira em torno de conjuntos de regras e das regras dentro desses conjuntos.

É isso mesmo.

Você precisa de um conjunto, que guarda regras, que por sua vez guardam ações.

Parece uma anedota?

É só a arquitetura dele tentando te enlouquecer.

• Conjunto de regras: define de onde o tráfego vem e, às vezes, para onde vai.
• Regras: dentro do conjunto, analisam o tráfego com mais precisão e dizem o que fazer com ele (traduzir IP, alterar porta, sacrificar um bode, etc).

---

Tipos de conjuntos de regras: pois complicar é preciso

🔄 NAT Estático e NAT de Destino

Você pode escolher um destes para criar conjuntos baseados em:

• Interface de origem
• Zona de origem
• Instância de roteamento de origem

Parece simples?

Espere até a coisa complicar…

🌀 NAT de Origem

Aqui você define tanto a origem quanto o destino do tráfego.

E, adivinha só?

Se um pacote bater em mais de um conjunto, quem ganha é o que tiver a correspondência mais específica.

A hierarquia da especificidade (sim, isso existe) é a seguinte:

1. Interface de origem + interface de destino
2. Zona de origem + zona de destino
3. Instância de roteamento + qualquer coisa
4. Qualquer combinação bizarra que sua cabeça conseguir criar

Ah, e claro: não tente ser criativo demais.

Ele vai te punir.

Você não pode usar exatamente a mesma origem e destino em dois conjuntos diferentes.

O sistema não é fã de ambiguidade.

---

Regras, onde começa a verdadeira diversão (ou agonia)

Depois que o pacote bate em um conjunto, vem a pergunta: qual regra aplicar?

Simples: a primeira regra que combinar com o pacote leva a taça.

Você pode combinar com:

• IP de origem e destino
• Porta de origem (em NAT de origem/estático)
• Porta de destino

E é isso.

Se a regra bate, a ação é aplicada e ele começa a sua mágica de esconder a verdadeira identidade dos pacotes como se fosse um testemunho no Fantástico.

---

A ordem do caos: como ele processa as regras

Não basta ter regras.

Elas seguem uma ordem de execução, porque claro, por que não adicionar mais uma camada de complexidade?

Ordem dos fatores (e sim, aqui altera o produto):

1. NAT Estático
2. NAT de Destino
3. Roteamento
4. Política de segurança
5. Reverse NAT Estático
6. NAT de Origem

Tradução: se seu pacote não for tratado pelo NAT estático ou de destino antes da política de roteamento, ele já era. E se ele sobreviveu até aqui, o NAT de origem vai cuidar de dar a cartada final.

---

“Capacidade de Regras”: ou quantas regras você consegue enfiar sem derreter a caixa

Você achou que poderia criar regras infinitamente, né?

Que legal.

A realidade é que cada modelo de firewall da linha SRX tem seu limite de quantas regras NAT ele aguenta — e a documentação do Junos tem uma tabela enorme pra provar isso.

Alguns exemplos pra te desanimar ou te salvar:

Dispositivo	NAT de Origem	NAT de Destino	NAT Estático
SRX300	1.024	1.024	1.024
SRX345	8.192	8.192	8.192
SRX4100	30.720	30.720	30.720
SRX5800	51.200	51.200	51.200

Ah, e se você acha que 10.000 regras por conjunto é bastante… pense duas vezes.

Um firewall estressado é uma granada com o pino solto.

---

Algumas dicas toscas, mas úteis

• Não repita origem e destino nos conjuntos de NAT de origem. NAT não curte déjà-vu.
• Interface é mais específica que zona. E zona é mais específica que instância de roteamento. Parece briga de hierarquia da máfia, mas é só lógica do Junos.
• Só a primeira regra que bate é usada. Então pare de achar que sua regra número 47 vai fazer milagre.
• Planeje com base nos limites da caixa. Se seu SRX tem limite baixo, não tente criar o data center inteiro com uma única política.

---

Uma mistura de lógica com sadismo

Se NAT fosse uma pessoa, ela seria aquele colega de trabalho que responde um e-mail com 50 linhas só pra te dizer “não pode”.

Mas ainda assim, precisamos dele.

A estrutura de conjunto + regra é poderosa, mas perigosa.

Com o entendimento certo (e um pouco de ódio no coração), você consegue dominar essa arte obscura e fazer seus pacotes fluírem felizes, mesmo que maquiados.

---

Entendendo NAT e PAT: traduzindo IPs na marra

O Network Address Translation é uma daquelas soluções engenhosas que só existem porque alguém, lá no passado, achou que 4 bilhões de endereços IP seriam o suficiente para o mundo inteiro.

Não foram.

Ele está por aí desde sempre, mascarando redes internas com cara de gente grande para que elas possam falar com a internet sem parecer um amontoado de faixas privadas de endereços.

Mas se engana quem pensa que é só isso.

Há nuances.

E claro, complicações.

Um roteador, duas realidades

Sim, um único roteador pode, de forma bastante hipócrita, tratar parte dos usuários com NAT e permitir que outros na mesma interface Ethernet saiam com seus próprios IPs.

Isso se faz com uma Access List (ACL) bem direcionada — nada de usar aquele “any” preguiçoso, que é o equivalente técnico de “qualquer coisa serve”.

Defina com precisão os hosts e redes que devem ser traduzidos.

E claro, se você estiver usando NAT estático e o pacote não corresponder a nenhuma regra: adeus, conversão.

Ele vai sair como entrou.

PAT: o milagre da multiplicação dos IPs (via porta)

Quando falamos de PAT (Port Address Translation) — também conhecido como sobrecarga de NAT, ou o “truque sujo” que permite centenas de dispositivos compartilharem um único IP público —, as coisas ficam mais interessantes.

O PAT é um contorcionista: usa o IP global e mistura com as portas (de origem e destino) para diferenciar as conexões.

Cada IP pode ter milhares de sessões, pois PAT explora os intervalos de portas como quem minera ouro: 0–511, 512–1023 e 1024–65535.

Se a porta que o tráfego original quis usar já estiver ocupada, PAT vai tateando o intervalo até achar uma livre.

Se não achar?

Bem, sem porta, sem conexão.

O pacote é descartado sem dó.

Pools de IP: pois dividir é conquistar

Na prática, você pode definir pools — faixas de IPs que o NAT vai usar para alocar endereços conforme a necessidade.

O comando ip nat pool faz a mágica acontecer, e ACLs definem quem tem direito ao passe VIP da conversão.

Com um toque a mais de paranoia, você pode usar rotary pools, onde as conexões externas são balanceadas entre múltiplos hosts reais. Isso é NAT fazendo cosplay de balanceador de carga.

Ah, e claro: não vá achando que pode ter infinitos pools.

O IOS não é tão generoso.

Em versões modernas, há um limite de 255 pools.

Porque por mais que a teoria prometa o paraíso, a DRAM do roteador sempre nos lembra da dura realidade.

Route-maps: ACLs com esteroides

Enquanto ACLs são filtros, route-maps são roteiros de ação.

Eles permitem que você diga: “Se vier desse IP, traduz assim. Se for outro, trate de outro jeito.”.

Com isso, você pode criar mapeamentos dinâmicos mais granulares e até proteger seu servidor de ser exposto para o mundo todo, algo que a ACL, por si só, não faz com tanta elegância.

Endereços sobrepostos: o Frankenstein corporativo

Se um dia você tiver o infortúnio de lidar com duas empresas que usam a mesma faixa privada de IP (192.168.0.0/24, alguém?), bem-vindo ao maravilhoso mundo da sobreposição de endereços IP.

Isso acontece o tempo todo em fusões e aquisições, quando ninguém quis planejar sua rede direito.

Nesse caos, NAT vira o bombeiro: intercepta pacotes, manipula DNS, e traduz os IPs tanto na ida quanto na volta.

Um verdadeiro teatro para manter as aparências e fazer redes gêmeas acreditarem que não estão colidindo.

NAT estático: porque nem tudo precisa mudar

Quando você precisa de uma conversão um-para-um, o estático entra em cena.

É o método preferido para serviços internos que precisam ser acessados externamente (tipo servidores de email ou web).

É simples: um IP interno casa com um IP global, sem traições. Inclusive, dá para fazer isso a nível de porta, com a famosa PAT estática.

Mas cuidado: os IPs usados aqui não devem aparecer em nenhum pool dinâmico.

Sim, você precisa fazer esse controle manual.

Ele não vai segurar sua mão se você bagunçar a lógica.

Segmentação e fragmentação: pois a camada 3 e a 4 não se falam direito

Aqui entra a parte técnica chata, mas importante.

A fragmentação de IP ocorre na camada 3 (IP), quando um pacote é grande demais para passar por uma interface.

O TCP, lá na camada 4, segmenta dados antes de empacotar.

NAT lida com fragmentos IP, mas não gosta nada de lidar com segmentos TCP partidos.

Em outras palavras: cuidado com MTU, MSS, PMTUD e outros acrônimos que vão te fazer abrir wireshark às 3 da manhã.

ALG: o tradutor do tradutor

Alguns protocolos, como FTP e SIP, são tão “inteligentes” que colocam IPs dentro da própria carga útil.

O NAT, claro, não consegue traduzir aquilo sozinho.

Entra em cena o ALG (Application Layer Gateway), que serve justamente para interceptar, entender e ajustar essas informações dentro dos protocolos.

É a gambiarra que faz o impossível acontecer.

Temporizadores e a paciência do NAT

Se você acha que NAT é um sistema paciente, pense de novo.

Um TCP handshake não completado dá 60 segundos de vida para a entrada.

Completou?

Aí sim, você ganha 24 horas.

Mas se o host mandar um FIN ou um RESET, voltamos à regra dos 60 segundos.

E sim, dá para ajustar todos esses tempos com comandos como tcp-timeout, icmp-timeout, finrst-timeout, etc.

Roteamento e NAT: o casal que precisa de terapia

Para que o ele funcione com regras mais sofisticadas (como NAT-NVI), você precisa fazer o básico: criar rotas.

Se você não apontar o caminho certo para os IPs globais e locais externos, o tráfego vai vagar no limbo, e o roteador vai agir como se nada tivesse acontecido.

Ele precisa de rota como carro precisa de estrada.

NAT não gosta de log

Para fechar com chave de ouro: se você está pensando em colocar log nas ACLs que controlam NAT, esqueça.

A arquitetura NAT da Cisco simplesmente não suporta.

Logue outra coisa.

---

Conclusão amarga, mas honesta:

NAT é uma solução brilhante nascida de uma limitação absurda.

Com o esgotamento do IPv4, ele virou padrão de fato — e, como toda gambiarra que vira norma, traz consigo um combo de complexidade, limitações e mal-entendidos.

Entender suas entranhas é obrigatório para qualquer profissional que não queira ser pego de surpresa quando tudo der errado.

Porque sim: vai dar errado, e adivinhe quem vão chamar?

Exatamente você.

NAT para voz: quando a Cisco lança o protocolo novo… e o NAT finge que não viu

Imagine o seguinte cenário: você está atualizando sua infraestrutura de voz, instala o CUCM 7 (Cisco Unified Communications Manager), e pensa: “Beleza, estamos rodando SCCP v17, tudo novo, tudo lindo”.

Só que aí entra o NAT, esse ser arcaico que ainda vive mentalmente em 2006, e sua rede começa a se comportar como se tivesse sido amaldiçoada.

Bem-vindo ao inferno do NAT com voz, onde cada avanço vira um retrocesso camuflado.

---

Quando a incompatibilidade não é bug, é design

Vamos direto ao ponto: SCCP v17 e NAT não se falam.

Literalmente.

Enquanto o CUCM 7 e os telefones IP da Cisco já negociam alegremente o protocolo Skinny v17, o NAT — coitado — está preso no passado e não entende nada acima do SCCP v16.

Resultado?

Chamadas falham.

Telefone não registra.

Áudio unilateral.

Sinais estranhos no console.

Admins arrancando os cabelos.

E não, não é uma falha transitória.

No momento da redação deste post (sim, ainda em 2025!), o NAT da Cisco continua sem suporte oficial para SCCP v17.

Simples assim.

Não é bug, é limitação da arquitetura.

E se você acha isso absurdo… bom, estamos juntos nessa indignação.

---

Solução? Downgrade. Sim, em pleno 2025.

Sabe aquela sensação de usar o Windows 11 e descobrir que precisa voltar pro Windows XP porque o driver da sua impressora só funciona lá?

Pois é.

A solução “oficial” para essa incompatibilidade entre NAT e SCCP v17 é… pasme… fazer downgrade do firmware do telefone IP.

Para isso, você precisa:

1. Voltar o firmware dos telefones para versão 8.3.5 ou anterior.
2. Com isso, os aparelhos negociam o SCCP v16 com o CUCM.
3. O NAT, feliz da vida, finalmente processa os pacotes sem travar.

Sim, você leu certo: você precisa forçar seus dispositivos modernos a usarem uma versão antiga do protocolo para conseguir compatibilidade com o NAT.

É o equivalente a pedir para o seu carro elétrico funcionar com manivela porque o portão da garagem não reconhece motor silencioso.

---

Mas e o CUCM 6? Um caso raro de paz

A ironia do destino é que o velho CUCM 6.x acaba sendo a estrela da vez.

Isso porque ele vem com firmware padrão 8.3.x, que ainda utiliza SCCP v15 ou v16, os últimos que o NAT consegue digerir sem crises existenciais.

Logo, se você está rodando CUCM 6 ou anterior, sua vida é surpreendentemente tranquila — ao menos no que diz respeito à compatibilidade com NAT.

Mas a pergunta permanece: por quanto tempo vamos viver nessa simbiose forçada entre tecnologias que claramente não querem mais conversar?

---

O Gambiarra-as-a-Service: firmware antigo no CUCM novo

Se você é teimoso (ou pressionado por orçamento) e quer usar CUCM 7.x ou superior com NAT, sua única saída é assumir o modo “engenharia reversa”:

• Suba no seu CUCM TFTP Server um firmware antigo (ex: 8.3.x) compatível com SCCP v15.
• Configure os telefones para baixarem esse firmware manualmente, ignorando o padrão.
• Aguarde que todos se registrem com SCCP v15, permitindo que o NAT trabalhe.

É trabalhoso?

Sim.

É feio?

Bastante.

Mas funciona.

Você basicamente obriga a tecnologia nova a agir como se fosse velha só pra contornar a incapacidade de evolução do NAT.

Parece coisa de manual dos anos 90, mas está no guia oficial da Cisco.

---

Uma palavra sobre SIP: a alternativa (quase) moderna

Você deve estar pensando: “Ok, e se eu pular fora do SCCP e usar SIP?”

Boa ideia — até certo ponto.

O SIP funciona melhor com NAT, especialmente porque:

• É um protocolo padrão da indústria.
• Tem suporte mais amplo no mundo real.
• Trabalha melhor com ALG (Application Layer Gateway), que pode ajudar a resolver os problemas de NAT.

Mas (e sempre tem um “mas”):

• Se você usar SIP via TCP, o NAT ainda pode quebrar a segmentação.
• Nem todas as implementações SIP + NAT + ALG são confiáveis.
• O roteador precisa entender bem o SIP ALG, senão vai embaralhar os cabeçalhos e comprometer chamadas.

Ou seja: o SIP é uma alternativa viável, mas não é uma bala de prata.

Ainda assim, é infinitamente mais moderno e promissor do que continuar insistindo no SCCP com NAT cego.

---

Moral da história? Atualização seletiva é só um nome bonito para caos

O que mais impressiona (e irrita) nessa história é como a própria Cisco fragmenta suas tecnologias.

De um lado, empurra atualizações de firmware e protocolo como se fossem essenciais para segurança e performance.

Do outro, deixa o suporte a esses mesmos protocolos fora do alcance do NAT, obrigando admins a viverem em um eterno jogo de malabarismo entre versões.

Se você está pensando em atualizar seu CUCM, pense duas vezes.

E, principalmente, não esqueça de checar se o seu roteador, o firmware e o NAT estão na mesma página do calendário.

Provavelmente não estão.

---

Resumo ácido (pois a verdade dói)

• SCCP v17? O NAT não reconhece. Vai te deixar na mão.
• Quer que funcione? Use SCCP v15 ou v16. Pra isso, vai ter que fazer downgrade.
• CUCM 6.x com firmware 8.3.x? Funciona. Mas não diga isso alto demais.
• CUCM 7.x ou superior? Só com gambiarra no TFTP.
• Solução moderna? Migre para SIP — e reze para o ALG fazer sua parte.

---

Se você chegou até aqui, parabéns.

Ou você é um admin de rede à beira de um colapso nervoso, ou alguém com curiosidade mórbida por desastres tecnológicos disfarçados de “recursos avançados”.

De qualquer forma, uma coisa é certa: se há um lugar onde o tempo parou, foi no NAT da Cisco.

E ele está rindo da sua dor.

---

Você pode me seguir no Instagram e no YouTube para ver mais piadas toscas e deprimentes.

Siga também o grupo de comédia mais paia do mundo.