Troubleshooting: Recuperação do acesso ao firewall via console¶
Aplicável a: pfSense em VM na nuvem sobre ZFS (QEMU/KVM), com acesso de gerência restrito a VPN e a um alias de IPs públicos autorizados Versão testada: pfSense 2.8.0-RELEASE (amd64), FreeBSD 15.0-CURRENT
Por que isso importa?¶
Ambientes bem protegidos restringem gerência a poucos caminhos: uma VPN e um alias de IPs no firewall. Isso é correto, mas cria um ponto único de fragilidade: se vários desses caminhos falharem por motivos independentes ao mesmo tempo, o resultado é bloqueio total, mesmo com boas práticas aplicadas.
Este artigo cobre esse padrão: VPN indisponível, um IP do alias desatualizado, outro IP correto mas com a porta de SSH divergente da documentação, e uma senha documentada que já não é válida.
Não cobre ambientes em alta disponibilidade (CARP).
Pré-requisitos:¶
- Acesso ao painel da nuvem para reiniciar a VM e abrir o console web
- Saber se o disco usa ZFS ou UFS (veja como checar abaixo)
Diagnóstico:¶
- Teste a VPN de gerência. Se estiver fora do ar por um problema à parte (ex: CA interna vencida), trate isso separadamente.
- Teste cada IP do alias individualmente, não assuma que todos falham pela mesma causa: um pode estar desatualizado, outro pode estar correto mas apontar para um serviço com porta divergente da documentação.
- Se algum serviço for gerenciado por outra equipe e a credencial ainda não tiver sido repassada, trate como indisponível.
- Teste a senha documentada como root, local e via rede. Se falhar nos dois, a credencial está inválida, não é problema de porta ou rede.
Correção¶
1. Confirmar disco ZFS ou UFS¶
Ainda no Single User Mode (opção 2 no boot):
Partição freebsd-zfs no resultado confirma ZFS. Sem ela, mount -a tradicional já resolve, sem precisar dos passos seguintes.
2. Remontar o sistema de arquivos (ZFS)¶
3. Redefinir a senha pelo utilitário nativo¶
4. Liberação emergencial de acesso¶
Se o alias seguir desatualizado:
Trate essa regra como temporária. Confirme conectividade básica antes de seguir para a WebGUI:
5. Depois de restabelecer o acesso¶
Troque todas as senhas potencialmente comprometidas, substitua a regra emergencial por um ajuste definitivo no alias, corrija a porta divergente na documentação, e avalie migrar a VPN de gerência para algo sem dependência de cadeia de certificados, como WireGuard: Conectar clientes WireGuard a um túnel pfSense.
Validação¶
Login bem sucedido na WebGUI a partir do IP liberado, com a nova senha:
Handshake confirmado em Status > WireGuard (ou VPN equivalente), acesso já pelo alias formal atualizado, e SSH funcionando na porta real documentada.
Como evitar¶
- Manter todos os IPs do alias atualizados e propagados para todos os ambientes que dependem dele.
- Combinar com equipes terceiras que credenciais sejam repassadas assim que definidas, não só em emergência.
- Nunca presumir que uma senha documentada segue válida em ambientes pouco acessados.
- Tratar toda regra
easyrulecomo temporária. - Não depender de um único tipo de VPN como caminho de gerência.
Referência rápida de comandos¶
gpart show # confirma ZFS ou UFS
mount -u -o rw / # remonta raiz como leitura e escrita
zfs mount -a # monta os datasets ZFS
pfSsh.php playback changepassword # reset de senha interativo
pfctl -d && pfctl -e # ciclo do packet filter
easyrule pass wan any IP_AUTORIZADO_TEMPORARIO any any # libera acesso emergencial
pfctl -f /tmp/rules.debug # recarrega as regras
Checklist¶
- [ ] VPN testada como primeiro caminho.
- [ ] Todos os IPs do alias confirmados.
- [ ] Senha documentada testada e invalidada antes de assumir problema de porta/rede.
- [ ] ZFS confirmado com
gpart show. - [ ] Senha redefinida via Single User Mode.
- [ ] Regra emergencial substituída por ajuste definitivo.
- [ ] Porta real conferida e documentação atualizada.
- [ ] Login validado por caminho formal.