Firewall: Portas para a Comunicação com as Finanças (AT)

O software de faturação trabalha bem durante o mês e falha no pior momento: o caixa não envia a fatura, o armazém fica com a guia de remessa por emitir, o contador não entrega o SAF-T no prazo. O erro típico é de ligação — timeout, ligação recusada ou uma resposta SOAP vazia — e a restante rede funciona sem problemas. A causa está quase sempre no mesmo sítio: os webservices da Autoridade Tributária não correm na porta 443, e a firewall do perímetro, preparada para deixar passar apenas HTTP e HTTPS, bloqueia as portas TCP próprias de cada serviço.

A AT publica endereços e portas nos manuais de integração de software, e não numa página única de requisitos de rede. Os números já mudaram, e manuais antigos ainda em circulação apontam portas desactualizadas. A tabela seguinte reúne os valores dos manuais em vigor, com produção e testes separados. A seguir vêm as regras prontas a aplicar em pfSense, OPNsense, Windows Firewall e UFW, os comandos de validação e os requisitos que não são de rede — o certificado do produtor e o subutilizador.

Neste artigo

1. 1. Por que é que a comunicação com a AT falha na firewall
2. 2. Os três canais de comunicação com a AT
3. 3. Portas de produção e de testes
4. 4. Regras no pfSense e no OPNsense
5. 5. Regras no Windows Firewall e no UFW
6. 6. Testar a conectividade
7. 7. Certificado SSL e subutilizador
8. 8. Erros Comuns
9. 9. Checklist
10. 10. Artigos Relacionados
11. 11. Fontes Oficiais

1. Por que é que a comunicação com a AT falha na firewall

A maioria das firewalls de PME sai da caixa com uma regra simples: tudo o que sai da rede interna é permitido, ou apenas HTTP e HTTPS. No primeiro caso o problema não aparece. No segundo, aparece no momento exacto em que o software de faturação comunica, porque os webservices tributários correm em portas TCP de três dígitos atribuídas pela AT, que um perfil restritivo de saída bloqueia sem qualquer aviso.

O browser abrir o Portal das Finanças não prova nada: isso só mostra que a porta 443 dos portais web está livre. O canal dos webservices é outro — SOAP sobre HTTPS, num endereço próprio e em portas próprias — e é esse canal que a firewall está a cortar.

A AT concentra todos os webservices num único endereço. Faturas, recibos, consulta e guias resolvem para o mesmo IP, o que simplifica as regras: um alias de destino cobre todos os serviços, só as portas variam. Confirme a resolução antes de criar regras:

nslookup servicos.portaldasfinancas.gov.pt

Saída típica:

Servidor:  dns-interno
Address:  192.168.1.1

Resposta não autoritativa:
Nome:    servicos.portaldasfinancas.gov.pt
Address:  89.115.248.148

Se a rede resolve o nome para 89.115.248.148, está tudo alinhado com as regras deste guia. Outro endereço significa infraestrutura nova — reler os manuais antes de fixar regras por IP.

2. Os três canais de comunicação com a AT

Envio em tempo real por webservice. Faturas e recibos seguem o serviço fatcorews, da comunicação dos elementos do documento de faturação, e os recibos usam a operação RegisterPayment no mesmo serviço. As guias de transporte seguem o SGDT, com cinco tipos: GR (remessa), GT (transporte), GA (ativos próprios), GC (consignação) e GD (devolução). Os dois serviços falam SOAP sobre HTTPS, num canal de envio imediato a cada documento.

Consulta. O serviço fatshare permite ao software consultar faturas comunicadas por terceiros, por exemplo para reconciliar o que os fornecedores já comunicaram. Canal separado, porta separada.

SAF-T (PT). Não tem porta TCP própria. O ficheiro submete-se no portal e-fatura, por browser ou pela aplicação de envio por linha de comandos que a AT disponibiliza. Para a rede, é apenas HTTPS na porta 443 — se os portais funcionam, o SAF-T funciona.

Os dois primeiros canais têm um requisito que não é de rede: o webservice exige certificado SSL do produtor de software assinado pela AT e um subutilizador com perfil próprio no Portal das Finanças. A secção 7 trata desse ponto.

3. Portas de produção e de testes

As portas 4xx servem a produção e as 7xx o ambiente de testes. Durante a homologação o produtor comunica contra as 7xx, e a firewall tem de as deixar passar também. Feita a homologação, as de produção (423, 425, 401) são obrigatórias e as de testes podem fechar. A porta 402 só interessa a quem emite guias de aquisição agrícolas. Manuais anteriores a 2013 citam as portas 400 e 700 — estão desactualizadas, seguir os manuais em vigor: 401 e 701.

4. Regras no pfSense e no OPNsense

Nos dois sistemas a lógica é a mesma: um alias com o destino da AT e regras de passagem na LAN para cada porta.

Alias do destino. Em Firewall → Aliases → Add, criar um alias chamado AT_WS, do tipo Host(s), com o valor 89.115.248.148. Guardar e aplicar.

Regras na LAN. Em Firewall → Rules → LAN → Add (topo), criar uma regra por porta com Action Pass, Protocol TCP, Source LAN net, Destination AT_WS e Destination Port 423 — e repetir para 425, 401 e 402 conforme os serviços usados. A descrição identifica cada serviço (AT fatcorews faturas, AT fatshare consulta, AT sgdt transporte), o que facilita desactivar uma só regra quando um serviço muda de porta.

Depois de aplicar, confirmar as regras em Diagnostics → Command Prompt (ou por SSH):

pfctl -sr | grep 89.115.248.148

Cada linha da saída é uma regra activa, com interface e porta visíveis. O pfctl é o mesmo nos dois sistemas, porque ambos correm sobre pf — muda apenas o caminho do menu até ao terminal.

5. Regras no Windows Firewall e no UFW

O perímetro é a primeira camada, o sistema operativo do servidor é a segunda — as regras de saída têm de existir nas duas.

Windows Firewall, no servidor que corre a aplicação, em linha de comandos como administrador:

netsh advfirewall firewall add rule name="AT faturas" dir=out action=allow protocol=TCP remoteip=89.115.248.148 remoteport=423 profile=any
netsh advfirewall firewall add rule name="AT consulta" dir=out action=allow protocol=TCP remoteip=89.115.248.148 remoteport=425 profile=any
netsh advfirewall firewall add rule name="AT transporte" dir=out action=allow protocol=TCP remoteip=89.115.248.148 remoteport=401 profile=any
netsh advfirewall firewall add rule name="AT aquisicao agricola" dir=out action=allow protocol=TCP remoteip=89.115.248.148 remoteport=402 profile=any
netsh advfirewall firewall add rule name="AT testes" dir=out action=allow protocol=TCP remoteip=89.115.248.148 remoteport=701,723,725 profile=any

Para confirmar as regras criadas, em PowerShell:

Get-NetFirewallRule -DisplayName "AT*" | Format-Table DisplayName,Enabled,Direction

Saída esperada:

DisplayName              Enabled Direction
-----------              ------- ---------
AT aquisicao agricola       True    Outbound
AT consulta                 True    Outbound
AT faturas                  True    Outbound
AT testes                  True    Outbound
AT transporte               True    Outbound

Em Linux com UFW:

sudo ufw allow out to 89.115.248.148 port 423 proto tcp comment "AT fatcorews faturas"
sudo ufw allow out to 89.115.248.148 port 425 proto tcp comment "AT fatshare consulta"
sudo ufw allow out to 89.115.248.148 port 401 proto tcp comment "AT sgdt transporte"
sudo ufw allow out to 89.115.248.148 port 402 proto tcp comment "AT aquisicao agricola"
sudo ufw allow out to 89.115.248.148 port 701,723,725 proto tcp comment "AT testes"

O UFW permite o tráfego de saída por defeito, mas servidores endurecidos fecham o outbound e estas regras são então as que reabrem o caminho para a AT. Em Linux sem UFW, a alternativa directa em iptables:

sudo iptables -A OUTPUT -d 89.115.248.148 -p tcp -m multiport --dports 401,402,423,425,701,702,723,725 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo netfilter-persistent save

Sem o iptables-persistent, a regra desaparece no primeiro reboot.

6. Testar a conectividade

Em PowerShell no servidor do software:

Test-NetConnection servicos.portaldasfinancas.gov.pt -Port 423

Saída esperada:

ComputerName     : servicos.portaldasfinancas.gov.pt
RemoteAddress    : 89.115.248.148
RemotePort       : 423
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.1.50
TcpTestSucceeded : True

TcpTestSucceeded : True confirma que o TCP chega ao destino. Um False com timeout indica bloqueio no caminho — perímetro, host ou ambos. Repetir para as portas de cada serviço em uso (425, 401).

O teste seguinte confirma o TLS e o certificado:

openssl s_client -connect servicos.portaldasfinancas.gov.pt:423 -brief

Saída esperada:

CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate:
subject = CN = *.portaldasfinancas.gov.pt
Verification: OK

Verificação a OK contra o certificado *.portaldasfinancas.gov.pt (de validação de organização, emitido pela Sectigo) mostra que a porta responde e que ninguém no caminho intercepta a ligação com um certificado próprio. O mesmo padrão repete-se nas restantes portas.

Em Linux, o curl dá um teste rápido em linha:

curl -sS --connect-timeout 10 -o /dev/null -w "%{http_code}" https://servicos.portaldasfinancas.gov.pt:423/fatcorews/ws/

Qualquer código HTTP — mesmo um 401 — prova que a porta responde e o TLS está estabelecido. Timeout ou connection refused é o bloqueio.

A AT tem ainda uma página oficial de teste, na área do produtor de software do portal e-fatura (testarLigacaoWebService.action), que executa a verificação completa do lado da AT: porta, TLS, certificado do produtor e credenciais do subutilizador. É o teste final antes de dar o software como operacional.

7. Certificado SSL e subutilizador

A porta aberta não chega. Os webservices autenticam o produtor em dois níveis, e ambos falham com mensagens que parecem de rede.

Certificado SSL do produtor. O webservice exige certificado do lado do cliente assinado pela AT — mutual TLS. Pede-se no Portal das Finanças, instala-se no servidor da aplicação e configura-se no próprio software. Tem prazo de validade, e a expiração produz falhas de handshake que a aplicação reporta como erro de comunicação — a data no inventário e a renovação com antecedência evitam a paragem inesperada.

Subutilizador com perfil próprio. O titular cria no Portal das Finanças um subutilizador para a aplicação, com perfil WFA para faturas e recibos e WDT para os documentos de transporte. As credenciais vão na configuração do software. Sem o perfil certo, autentica mas não autoriza — o webservice devolve erro de acesso.

Quando um dos três requisitos falta — porta, certificado ou subutilizador — o sintoma é o mesmo: a aplicação não comunica. A distinção faz-se nos testes da secção 6: TCP a funcionar com falha na autenticação aponta para certificado ou subutilizador, não para a firewall.

8. Erros Comuns

9. Checklist

• Regra de saída para 89.115.248.148 na porta 423 (fatcorews de produção) criada no perímetro
• Regra de saída na porta 425 (consulta de produção) criada no perímetro
• Regra de saída na porta 401 (SGDT de produção) criada no perímetro
• Porta 402 aberta só se existirem guias de aquisição agrícolas
• Portas 723, 725 e 701 abertas durante a homologação e fechadas depois
• Porta 443 aberta para os portais (browser, SAF-T e página de teste)
• Test-NetConnection com TcpTestSucceeded : True nas portas de produção
• Handshake TLS 1.2 ou superior com verificação OK em openssl s_client
• Certificado do produtor instalado e dentro do prazo de validade
• Subutilizador com perfil WFA (faturas) ou WDT (transportes) configurado na aplicação
• Regras e expirações documentadas no inventário de firewall da empresa

10. Artigos Relacionados

• pfSense: Configuração de Firewall, NAT e VPN em 2026
• OPNsense na PME: Firewall Open-Source a Sério em 2026
• Dia 9: Firewalls Linux — iptables, nftables, UFW e firewalld
• Diagnóstico de Conectividade Windows Server 2026: PowerShell Moderno, Hyper-V, Firewall Avançado, PktMon e SMB Multichannel

11. Fontes Oficiais

• Manual de Integração de Software — e-Fatura: Comunicação dos elementos dos documentos de faturação por webservice, aspetos genéricos (PDF da AT)
• Manual de Integração de Software SGDT — Comunicação de Dados dos Documentos de Transporte (PDF, espelho do manual oficial da AT, revisão de Agosto 2013 — inclui as guias de aquisição de produtos agrícolas, portas 402/702)
• Portal e-Fatura — área do produtor de software (teste de ligação ao webservice e submissão do SAF-T)
• Portal das Finanças