Configurar e solucionar problemas do Sophos SD-RED

Com um Sophos SD-RED, é possível conectar filiais, escritórios ou pequenos escritórios domésticos a uma Sophos Firewall. O RED estabelece um túnel criptografado para a firewall e fornece uma rede no local remoto, que é gerida centralmente pela firewall.

A vantagem prática: no local, normalmente não é necessária uma configuração VPN complexa. O SD-RED é conectado à Internet, carrega sua configuração através do Sophos RED Provisioning Service e, em seguida, estabelece o túnel para a Sophos Firewall. No entanto, o túnel por si só não resolve tudo. Zonas, regras de firewall, DHCP, VLANs, roteamento, DNS e versão do firmware também devem estar corretos.

O modo de funcionamento deve ser definido antes da configuração propriamente dita. Determina DHCP, gateway, caminho da internet, controlo central e o comportamento durante uma falha do túnel. Escolher o modo de funcionamento correto do Sophos RED explica as diferenças e os critérios de decisão.

Planeamento e requisitos

Classificação: SD-RED e RED entre firewalls

Existem dois casos atuais de RED que devem permanecer separados. Este artigo trata de uma SD-RED 20 ou SD-RED 60 física numa filial. O SFOS 22 também continua a suportar um túnel Site-to-Site RED entre duas Sophos Firewall, em que uma atua como Firewall RED server e a outra como Firewall RED client.

O segundo caso não necessita de hardware RED. Configurar Site-to-Site RED entre duas Sophos Firewall explica o ficheiro de provisionamento, as rotas estáticas sem interface selecionada, as regras nos dois lados e o serviço RED. Os modos de operação SD-RED não se aplicam a este design.

Requisitos no local principal

Antes de conectar o RED, os seguintes pontos devem estar claros na Sophos Firewall:

• O serviço RED está ativado na firewall.
• O endereço IP público ou o nome DNS/DynDNS da firewall é acessível.
• Conexões RED para a firewall são permitidas no lado WAN.
• RED é permitido em Administration > Device access para a zona WAN apropriada ou liberado especificamente através do Local Service ACL.
• Interface RED, zona e configuração IP estão planejadas.
• Regras de firewall da rede RED para as redes de destino estão previstas.
• DHCP, DHCP Relay ou endereçamento estático para clientes atrás do RED está resolvido.
• O padrão de firmware RED na firewall está atualizado.
• Backup e versão do firmware da firewall estão documentados antes de grandes alterações.

Para a comunicação RED, TCP 3400, UDP 3410 e NTP 123 são particularmente relevantes. Essas conexões não devem ser bloqueadas por roteadores de provedores, firewalls intermediárias ou gateways de segurança.

Requisitos no local remoto

No local remoto, o SD-RED precisa de uma conexão de Internet estável. O que importa não é apenas a largura de banda, mas principalmente a estabilidade, latência, perda de pacotes e se o provedor permite as conexões necessárias.

Deve-se verificar:

• A conexão de Internet é estável.
• A porta WAN do RED recebe um endereço por DHCP ou tem uma configuração estática correta.
• O gateway padrão é acessível.
• O DNS funciona.
• O NTP é acessível.
• TCP 3400, UDP 3410 e NTP 123 não são bloqueados.
• O roteador do provedor ou firewall intermediária não faz filtragem inesperada.
• Em VLANs, está claro qual porta opera como tagged, untagged ou híbrida.

Para locais simples, muitas vezes uma pequena conexão é suficiente. Na prática, no entanto, a perda de pacotes, roteadores de consumo instáveis, CGNAT, problemas de DNS ou firewalls restritivas de provedores são mais frequentemente a causa do que a largura de banda pura.

Provisioning e colocação em serviço

Provisionar automaticamente através do Sophos Provisioning Service

Para o provisionamento online normal, a firewall e a SD-RED precisam de acesso à internet. No primeiro arranque, a SD-RED tem de obter um endereço WAN por DHCP para poder descarregar a configuração. Uma configuração WAN estática exige, portanto, provisionamento manual por USB. Na firewall, ativa-se o serviço de provisionamento RED em System services > RED, introduzem-se os dados de contacto e aceitam-se os termos de utilização da Sophos.

Em seguida, cria-se uma interface em Network > Interfaces > Add interface > Add RED. Para o site, configuram-se Branch name, tipo de dispositivo, Automatically via provisioning service, endereço da firewall, uplink, modo de operação, rede RED, zona e DHCP. Numa RED utilizada pela primeira vez, Unlock code fica vazio. Depois de guardar, a firewall carrega a configuração para o serviço de provisionamento. A SD-RED obtém-na, abre o canal de controlo em TCP 3400 e depois estabelece o túnel de camada 2 em UDP 3410.

Para a zona RED dedicada, introduza um nome como RED-Branch em Network > Zones > Add, defina Type como LAN ou DMZ e selecione em Device access apenas os serviços efetivamente necessários. Guarde com Save e selecione esta zona em RED network settings na interface RED. Em Administration > Device access, por sua vez, ative o serviço RED para a zona a partir da qual a RED chega à firewall, normalmente WAN; aplique com Apply. A zona dos clientes por detrás da RED e a zona de entrada do túnel RED não são a mesma coisa.

Ao guardar pela primeira vez, o serviço de provisionamento gera um código de desbloqueio específico do dispositivo. O código aparece no WebAdmin e é enviado para o endereço de e-mail configurado em System services > RED. Deve ser guardado em segurança porque é necessário ao mover a RED para outra firewall. O WebAdmin volta a mostrá-lo quando a interface é eliminada. Se o código não estiver disponível, deve contactar-se o Sophos Support.

Definir conscientemente as proteções RED globais

Durante a ativação inicial em System services > RED, o SFOS cria um certificado para a comunicação RED a partir de Organization name, City, Country e Email. Por isso, Organization name e City não podem conter tremas nem caracteres especiais. O endereço de e-mail deve permanecer acessível, porque a Sophos envia para lá novos códigos de desbloqueio.

Para SD-RED 20 e 60 atuais, TLS v1.2 (strict) and later é o ponto de partida recomendado. Esta seleção utiliza apenas as cifras TLS 1.2 recomendadas pela Sophos. TLS v1.2 and later inclui também cifras que a Sophos não recomenda e não deve ser escolhido sem uma necessidade de compatibilidade comprovada. Após a alteração, todos os túneis RED de produção devem ser novamente ligados e testados de forma controlada.

Automatic device deauthorization impede que uma RED desligada durante muito tempo permaneça autorizada indefinidamente. O período deve adequar-se ao processo de incidentes e substituição da organização: depois de expirar, o dispositivo não é eliminado, mas a interface RED tem de ser explicitamente reativada em Network > Interfaces. A monitorização e a documentação do código de desbloqueio fazem, por isso, parte desta proteção.

Em SD-RED 20 e 60, mantenha RED unified firmware ativado. Um novo padrão de firmware RED é instalado conscientemente em Backup & firmware > Pattern updates e não é aplicado automaticamente. Deve ser planeada uma janela de manutenção e, em seguida, testados o túnel e um cliente.

Para configurar esta função, ative Automatic device deauthorization, indique o prazo e selecione Apply. Volte a ativar uma RED cuja autorização tenha sido revogada após o fim do prazo em Network > Interfaces, através do Menu à direita do dispositivo afetado. A função de proteção também se aplica a um Firewall RED Client. RED unified firmware está selecionado por predefinição; contudo, numa migração da firewall, a definição existente é mantida. Após uma reposição de fábrica, a opção volta a estar selecionada. Por isso, após uma migração ou reposição, verifique o valor real em vez de assumir apenas a predefinição.

Conectar o SD-RED

Procedimento típico:

1. Conectar a porta WAN do SD-RED ao roteador do provedor ou modem.
2. Conectar a porta LAN a um cliente de teste, switch ou rede local.
3. Fornecer energia ao SD-RED.
4. Aguardar até que o RED inicie, verifique o gateway e a Internet, carregue a configuração e estabeleça o túnel.
5. Verificar na Sophos Firewall se a interface RED está ativa.
6. Conectar o cliente de teste atrás do RED e verificar IP, DNS, gateway e acesso ao destino.

Se todos os LEDs relevantes estiverem verdes, o túnel técnico está estabelecido. Depois disso, começa a verificação real da rede: Zona, DHCP, regras de firewall, roteamento de retorno, DNS e, se necessário, VLANs.

Provisioning manual com pen USB

Normalmente, um SD-RED é provisionado através do Sophos RED Provisioning Service. O provisioning manual por pen USB é útil quando o dispositivo está numa rede privada ou fortemente restringida, precisa de uma configuração WAN estática ou o caminho de provisioning automático não é fiável.

A fonte horária da firewall e o fornecimento da hora à RED não são a mesma coisa: O guia de RED manual para SFOS 22 e 23 descreve, em Administration > Time, a seleção de Use custom NTP server, o próprio IP da firewall em Search/Add, bem como Add e Apply, como configuração de um servidor NTP para a RED. A documentação das definições de hora descreve, porém, este campo como uma fonte horária a montante para o relógio da firewall. Assim, as funções não correspondem de forma inequívoca; este procedimento não é um pré-requisito incondicional nem prova que a firewall fornece NTP à RED. Sem um percurso de sincronização horária confirmado e suportado para a versão instalada, a configuração NTP funcional mantém-se inalterada. Planear primeiro cada alteração confirmada em relação ao estado inicial documentado: uma mudança de servidores NTP volta a ligar todas as ligações IPsec. Se forem afetadas ligações de produção, garantir uma janela de manutenção e acesso de gestão local ou alternativo.

O processo é mais preciso do que apenas copiar um ficheiro de provisioning para USB:

1. Antes do provisioning manual, esclarecer o percurso de sincronização horária suportado para a versão instalada e documentar as definições NTP funcionais, bem como a hora e o estado de sincronização da firewall. Não alterar a fonte horária global para o próprio IP da firewall apenas devido a esta configuração RED; a restrição e a verificação NTP/HTTPS encontram-se abaixo.
2. Em Network > Zones, criar para os locais RED uma zona dedicada do tipo LAN ou DMZ. Uma zona separada impede que as regras LAN gerais se apliquem involuntariamente ao local remoto. Se for usada a zona VPN, a firewall não responde diretamente às consultas DNS dos clientes RED; nesse caso, o DHCP tem de distribuir outro servidor DNS acessível.
3. Em System services > RED, ativar o RED Provisioning Service.
4. Em Network > Interfaces > Add interface > Add RED, criar a interface RED.
5. Em Device deployment, escolher Manually via USB stick.
6. Introduzir RED ID, Unlock Code, uplink, RED network settings, zona, DHCP e VLANs adequados ao site.
7. Em Network > Interfaces, abra o Menu da interface RED e transfira o ficheiro de provisionamento correspondente a esta interface, gerado após Save.
8. Copiar o ficheiro para o diretório raiz da pen USB.
9. Desligar o RED, inserir a pen USB e voltar a ligar o RED.
10. Após o arranque, verificar interface, LEDs, IP do cliente, DNS, regra de firewall e acesso aos destinos.

Após uma alteração horária confirmada, atualizar o WebAdmin e verificar o relógio da firewall em Administration > Time, o estado de sincronização e as ligações IPsec. Verificar também o percurso de sincronização horária da RED, o handshake TLS e o estabelecimento do túnel. Se a sincronização horária falhar ou ocorrer uma regressão, restaurar as fontes horárias e as definições anteriores funcionais em Administration > Time e repetir as mesmas verificações; esta reversão também pode restabelecer as ligações IPsec.

Se o lado WAN do RED usar DHCP, tem de existir realmente um servidor DHCP a responder no site remoto. Se o RED não receber um endereço, pode entrar num ciclo de reinício. Com configuração WAN estática, IP, gateway, DNS e NTP têm de ser verificados com especial cuidado.

Mesmo uma RED com provisioning offline necessita de uma hora válida dentro do período de validade do certificado para o handshake TLS. Para a sincronização horária direta, tem de conseguir resolver de 0.sophos.pool.ntp.org a 3.sophos.pool.ntp.org e aceder-lhes por UDP 123. Se não conseguir, tenta sincronizar a hora com a firewall através de HTTPS em TCP 4444. Se o serviço de administração HTTPS não estiver autorizado para WAN em Administration > Device access, este fallback pode falhar sem uma exceção específica. Não ativar HTTPS de forma generalizada para a zona WAN para este efeito: a exceção também permite o serviço de administração HTTPS e tem de ser estritamente limitada.

Antes de uma alteração, documentar as definições existentes de Device Access e ACL e verificar se já existe uma exceção adequada. Determinar com Diagnostics > Packet capture o endereço de origem da ligação RED efetivamente observado na firewall. Atrás de um router NAT, este é normalmente o endereço público de saída NAT da sucursal, não o endereço WAN privado da RED. Utilizar apenas um host IP claramente conhecido e tão estável quanto possível; se o endereço NAT for partilhado, a autorização também se aplica a outros dispositivos atrás desse endereço. Não substituir uma origem variável ou desconhecida por uma autorização Any.

1. Abrir Administration > Device access > Local service ACL exception rule > Add e atribuir um nome único.
2. Definir Source zone como WAN. Em Source network or host, selecionar o host IP para o endereço de origem efetivamente observado; se necessário, criar um host IP adequado através de Add.
3. Definir Destination host para a porta WAN prevista da firewall, Services como HTTPS e Action como Accept. Guardar com Save.
4. Verificar a restrição de origem guardada e o host de destino. Depois, testar a sincronização horária da RED, o handshake TLS e o estabelecimento do túnel, e verificar que não foram autorizadas outras origens WAN para HTTPS.

Se uma exceção recém-criada for necessária apenas temporariamente, removê-la após o teste ou após o restabelecimento do percurso NTP direto. Removê-la também se for ineficaz ou permitir acesso indesejado; se uma exceção existente for alterada, restaurar o respetivo estado inicial documentado. Em seguida, voltar a verificar a restrição de origem, a acessibilidade HTTPS e o túnel RED. Documentar uma exceção necessária de forma permanente, juntamente com o endereço de origem NAT, e revê-la regularmente.

Estado, atualizações e migração

Entender o status dos LEDs

Os LEDs de status são frequentemente o ponto de partida mais rápido para o troubleshooting do RED, pois indicam em que ponto o processo de inicialização está travado.

Legenda:

• ⚫ apagado
• 🟢 aceso verde
• 🟢 piscando verde
• 🔴 aceso vermelho
• 🔴 piscando vermelho

Dependendo do ângulo de visão, foto ou luz ambiente, um LED pode parecer amarelado ou laranja. Para o diagnóstico, o que importa é qual LED está aceso ou piscando e se é verde ou vermelho.

Processo de inicialização normal

Se todos os quatro LEDs estiverem verdes, mas nenhum tráfego funcionar, o problema geralmente não está mais na configuração do túnel. Nesse caso, regras de firewall, DHCP, VLANs, DNS, NAT ou roteamento são mais prováveis.

Códigos de erro

Failover 3G/4G

Em modelos SD-RED com failover 3G/4G ou módulo correspondente, podem ocorrer padrões adicionais.

Controlar atualizações de firmware

Se os LEDs piscarem em conjunto, a RED pode estar a instalar firmware. Durante esta fase, não se deve desligar o dispositivo nem desligá-lo da Internet. Uma atualização pode demorar alguns minutos. A interpretação tem de corresponder ao padrão de LEDs e ao modelo concretos; o piscar simultâneo, por si só, não constitui um diagnóstico inequívoco de firmware, como também mostram os padrões de failover.

Na Sophos Firewall, deve-se verificar adicionalmente:

Backup & firmware > Pattern updates

Aí, o RED Firmware Pattern deve estar atualizado. Segundo a Sophos, a transferência e a instalação demoram entre cinco e dez minutos. Se um RED ficar preso num ciclo ou não arrancar corretamente após uma atualização da firewall, vale a pena verificar se o RED Firmware Pattern está desatualizado. Configurar e verificar atualizações de padrões no Sophos Firewall explica a relação entre o estado, a transferência automática e a instalação deliberada.

Um desejo operacional relacionado está descrito em Solicitação de Recurso da Sophos Firewall 2024: Em atualizações de firmware de RED e Access Point, muitas vezes faltam notas de lançamento visíveis diretamente no backend. Para ambientes produtivos, as atualizações devem ser planejadas conscientemente e não instaladas de forma descoordenada durante horários críticos de operação.

Verificar interface RED, zona e regras

Após o estabelecimento bem-sucedido do túnel, o RED precisa de uma configuração de firewall limpa.

Pontos típicos de verificação:

• A interface RED está ativa em Network > Interfaces.
• A interface está na zona correta.
• O servidor DHCP ou o DHCP Relay está configurado corretamente.
• Os clientes recebem endereço IP, gateway e DNS.
• As regras de firewall permitem apenas os destinos necessários.
• O roteamento de retorno para a rede RED funciona.
• O NAT é usado apenas quando planejado conscientemente.
• A configuração VLAN corresponde ao modo RED e à porta do switch.

Para o primeiro teste funcional, basta uma regra estritamente limitada em Rules and policies > Firewall rules: definir Source zone como a zona dedicada RED-Branch, indicar a rede dos clientes RED em Source networks and devices e permitir como destino apenas a rede interna de teste necessária. O acesso à internet exige uma regra separada com a zona WAN como destino e o tratamento NAT previsto. Em seguida, limite destinos e serviços às necessidades de produção. Assim, testa-se o caminho pretendido sem dar ao local remoto acesso a todas as redes internas.

Para as bases das regras, consulte Entender e configurar corretamente as regras da Sophos Firewall. Se o túnel estiver estabelecido, mas o tráfego não fluir, deve-se combinar Log Viewer e Packet Capture.

A opção MAC filtering type pode aplicar na rede RED uma allow list ou block list com um limite dependente do dispositivo, mas não substitui uma regra de firewall. Remote IP assignment também não é uma configuração predefinida: atribui por DHCP ou de forma estática um endereço ao bridge com o túnel RED no lado WAN e só deve ser investigada quando os dispositivos atrás da RED não respondem a pedidos ARP. Nenhuma das opções deve ser ativada como correção geral de desempenho ou conectividade.

Armadilhas de atualização e migração

Não confundir Site-to-Site RED com SD-RED

Um túnel RED entre firewalls continua a ser um design independente suportado no SFOS 22. Não utiliza nenhum dos quatro modos de operação SD-RED e não é definido através de DHCP nem das portas LAN de uma SD-RED. Durante uma atualização, ambos os tipos de RED são inventariados e cada um é depois validado com o respetivo teste funcional.

Para um planeamento de atualização mais amplo, consulte Planear corretamente a atualização de firmware da Sophos Firewall. O processo completo entre firewalls encontra-se em Configurar Site-to-Site RED entre duas Sophos Firewall.

Remover Firewall RED legacy e dispositivos RED antigos antes do SFOS 22

O SFOS 22.0 e versões posteriores já não suportam Firewall RED Server Legacy nem Firewall RED Client Legacy. Enquanto existir uma configuração deste tipo entre UTM e SFOS, a atualização, o restauro e a importação de configurações para o SFOS 22 ficam bloqueados. Isto não afeta os tipos atuais Firewall RED server e Firewall RED client. Antes da atualização, devem ser substituídas todas as dependências das interfaces legacy, eliminadas as interfaces e criada uma nova cópia de segurança da configuração.

RED 15, RED 15w e RED 50 também chegaram ao fim de vida. Os seus túneis deixaram de estabelecer ligação a partir do SFOS 20.0 MR1. Após uma atualização ou restauro para o SFOS 22, a configuração antiga permanece visível, mas não é aplicada e só pode ser eliminada. Não pode ser importada. Estes sites devem ser migrados para SD-RED 20 ou SD-RED 60 antes da atualização e testados com o respetivo caminho de dados real.

Máscara /32 corrigida para os hosts do sistema RED

A Sophos corrigiu para /32 a máscara de sub-rede dos objetos de host do sistema RED gerados automaticamente no SFOS 21.0 MR2 e 21.5 MR1. Se esses objetos eram anteriormente usados em regras ou outras configurações para vários endereços de host, as regras podem passar a corresponder ao tráfego de forma diferente após a atualização.

Verifique as dependências em Hosts and services > IP host ainda antes da atualização: Abra Usage para cada host de sistema RED e substitua o host de sistema pelo host IP ou Network adequado nas regras de firewall, rotas e restantes configurações apresentadas. Exemplo: Para o endereço RED 192.168.1.1/24, o host de sistema era anteriormente 192.168.1.1/24; agora é 192.168.1.1/32. Uma regra ou rota para toda a rede tem, por isso, de utilizar um host Network explícito; o host de sistema passa a abranger apenas o IP configurado da interface. Após a atualização, volte a testar as correspondências das regras e o percurso dos dados.

Após uma atualização, deve-se verificar:

• Os hosts do sistema RED são usados em regras de firewall?
• Uma regra espera erroneamente uma rede em vez de um único host?
• Devem ser substituídos objetos IP Host ou Network Host?
• As correspondências de regras no Log Viewer ainda estão corretas?

RED e failover HA

Em ambientes HA, os sites RED devem ser testados conscientemente após um failover. A Sophos indica que os túneis RED nem sempre se reconectam imediatamente ao dispositivo auxiliary após um failover HA. A duração depende, entre outros fatores, do número de interfaces e da configuração.

Para sites críticos, não se deve verificar apenas o estado HA da firewall. Também verificar:

• estado da interface RED após failover
• acesso de clientes atrás do RED
• correspondências relevantes de regras de firewall
• DNS e DHCP atrás do RED
• alertas de monitoring para interrupções de túnel prolongadas

Verificar o débito e o desempenho do RED

A Sophos indica um débito máximo do túnel de 250 Mbit/s para o SD-RED 20 e de 850 Mbit/s para o SD-RED 60. Estes são valores máximos da plataforma, não uma garantia para uma transferência SMB individual, um teste de velocidade no browser ou um único fluxo TCP. Os endpoints, o armazenamento, a janela TCP, a latência real entre os locais, a perda de pacotes, o percurso do operador, a carga da firewall e os perfis de segurança também influenciam o resultado.

Um ping de, por exemplo, 8 ms para um servidor público de teste de velocidade não descreve necessariamente a latência entre os dois locais RED. Um teste em cada ligação à Internet também não verifica o percurso cifrado end-to-end através do túnel RED. Para responder a esta questão, é necessário um servidor de teste numa LAN e um cliente de teste na LAN do outro local.

Testar o túnel RED com iPerf3 em ambas as direções

Antes do teste do túnel, deve criar-se uma baseline local com os mesmos endpoints ligados por cabo. Em seguida, executa-se o iPerf3 através do túnel RED, primeiro com um fluxo TCP, depois na direção inversa e, por fim, com quatro fluxos paralelos:

iperf3 -c 10.10.10.50 -t 30
iperf3 -c 10.10.10.50 -t 30 -R
iperf3 -c 10.10.10.50 -t 30 -P 4

10.10.10.50 é apenas um endereço de exemplo e deve ser substituído pelo endereço IP do servidor iPerf3 na LAN remota. O teste gera carga deliberadamente e deve ser realizado numa janela adequada. Testar corretamente o desempenho do Sophos Firewall com iPerf3 explica a instalação, a regra temporária da firewall, os testes UDP e a análise completa dos resultados.

Os três resultados respondem a perguntas diferentes:

• Se a baseline local já for lenta, verificar primeiro endpoints, NICs, controladores, cabos, switches e armazenamento.
• Se um fluxo for significativamente mais lento do que -P 4, é mais provável que a limitação esteja na latência, na janela TCP ou no fluxo individual da aplicação. Isto ainda não prova um limite do RED.
• Se um e quatro fluxos pararem no mesmo limite em ambas as direções, investigar as ligações físicas, o percurso do operador, a perda de pacotes, a configuração RED e a carga da firewall.
• Se apenas uma direção for lenta, comparar as respetivas velocidades de upload, os contadores das interfaces, os erros, os drops e o percurso de retorno.

Um padrão prático típico seria cerca de 400 Mbit/s com um fluxo e entre 700 Mbit/s e 800 Mbit/s com -P 4. Isto indica que o percurso pode transportar uma capacidade agregada significativamente maior, embora um único fluxo TCP ou SMB não a consiga utilizar por completo. Não garante que todas as aplicações atinjam o mesmo resultado com vários fluxos.

Durante cada execução, devem ser documentados o round-trip time real e a perda de pacotes entre os locais, as retransmissões do iPerf, a Firewall Rule ID, os perfis de segurança, a CPU da firewall e os contadores das portas envolvidas. As ligações WAN e LAN devem funcionar efetivamente a 1 Gbit/s, em Full Duplex e sem aumento dos contadores de erros ou drops. A velocidade e o duplex devem permanecer em auto-negotiation em ambos os lados, em vez de se forçar gigabit apenas num deles.

IPS ou outros perfis de segurança não devem ser desativados de forma geral. Para um teste A/B, utiliza-se no máximo uma regra temporária limitada à origem, ao destino e ao serviço iPerf3 concretos, removendo-a imediatamente depois. Se o resultado não mudar sem IPS, é menos provável que IPS seja a causa neste percurso de teste específico.

Desativar realmente 802.3az ou EEE

Para obter o melhor desempenho, a Sophos recomenda desativar 802.3az nos switches ligados a um SD-RED 20 ou SD-RED 60. Trata-se de Energy Efficient Ethernet, ou EEE. O EEE coloca partes do PHY Ethernet no estado Lower Power Idle quando a utilização da ligação é baixa, poupando energia. Não é o mesmo que PoE ou 802.3x Flow Control.

A definição não se encontra no WebAdmin nem na CLI do Sophos Firewall, nem num ecrã documentado do SD-RED. É alterada na porta do switch diretamente ligada. Isto aplica-se às ligações LAN utilizadas pelo RED e, se estiver envolvido um switch ou router gerível, também à ligação WAN física. Em dispositivos de outros fabricantes, a opção pode chamar-se EEE, Energy Efficient Ethernet, Green Ethernet, 802.3az ou Power Saving. Não existe uma CLI universal.

Num Sophos Switch, utiliza-se a página Port settings:

1. Selecionar a porta ligada diretamente ao SD-RED.
2. Abrir Edit.
3. Definir EEE status como Off.
4. Guardar com Apply.
5. Verificar o estado da ligação, a velocidade negociada, o duplex e os contadores de erros e repetir o mesmo teste iPerf3.

Num Sophos Switch atual, o estado pode ser apresentado em modo read-only na CLI:

show eee

Para a porta de exemplo 0/1, o EEE é desativado da seguinte forma:

configure terminal
interface gigabitethernet 0/1
no eee
exit
exit
save
show eee

0/1 deve ser substituído pela porta realmente ligada ao RED. no eee altera a configuração da porta. Se o switch só estiver acessível através deste percurso RED, são necessários uma janela de manutenção e um acesso de gestão local ou alternativo. Dependendo do switch e do firmware, a alteração pode provocar uma nova negociação da ligação.

Para repor o estado anterior num Sophos Switch, utiliza-se eee em vez de no eee no mesmo Interface Configuration Mode:

configure terminal
interface gigabitethernet 0/1
eee
exit
exit
save
show eee

Desativar EEE não desativa Ethernet nem gigabit. A desvantagem é que o PHY deixa de poupar a mesma quantidade de energia durante os períodos de inatividade, pelo que a porta consome um pouco mais e pode gerar mais calor. Não há garantia de um aumento específico do débito. O que conta é o teste reproduzível antes e depois. Num switch não gerido sem opção EEE, a definição não pode ser alterada de forma fiável; para o teste é necessário contornar o dispositivo ou utilizar temporariamente um switch gerível.

Alterar Tunnel compression e MTU apenas de forma controlada

A interface RED pode ser editada em Network > Interfaces. Aí encontram-se Tunnel compression e MTU. A Sophos descreve Tunnel compression como uma forma de comprimir o tráfego RED e aumentar o débito, sobretudo em ligações lentas. Dados já comprimidos ou cifrados praticamente não podem ser reduzidos, enquanto a compressão acrescenta trabalho de processamento. Por isso, uma única definição não é adequada para todos os locais.

Para um teste A/B, documentam-se primeiro o estado inicial e as medições. Depois altera-se apenas Tunnel compression, guarda-se e repete-se exatamente a mesma série iPerf3. Em seguida, repõe-se o estado inicial ou documenta-se conscientemente a variante que demonstrou ser melhor. Guardar pode interromper brevemente o túnel RED, pelo que uma janela de manutenção e um acesso alternativo são recomendáveis.

MTU não é um controlo geral da velocidade. Só deve ser investigado quando os pacotes pequenos funcionam mas as transferências maiores param, existe fragmentação visível ou o iPerf3 mostra muitas retransmissões. Verificar MTU e MSS do Sophos Firewall em problemas de VPN explica o teste DF seguro, os tamanhos dos pacotes e a reposição. Sem uma constatação MTU reproduzível, mantém-se o valor inicial documentado.

Solução de problemas

Não é possível criar ou editar a interface RED

Se a criação ou a gravação de uma interface RED já falhar, verifique primeiro as permissões de administrador, as configurações contraditórias, o ID da RED e o Unlock Code. A própria firewall tem de conseguir aceder ao Provisioning Server; um teste apenas na rede WAN da RED não é suficiente para determinar isso. É possível verificar o estabelecimento da ligação em 5. Device Management > 3. Advanced Shell na firewall:

telnet red.astaro.com 3400

Uma ligação estabelecida com êxito confirma apenas a resolução DNS e TCP 3400 a partir desta firewall. Não confirma nem o registo nem o Unlock Code. Em caso de falha, verifique o percurso de saída da firewall; se o teste for bem-sucedido, continue a investigar as permissões e a configuração concreta. Não elimine precipitadamente uma interface existente.

Não é possível alterar o IP do RED no SFOS 22.0 MR2

No SFOS 22.0 MR2 Build 546, pode surgir a mensagem Failed to update RED interface ao alterar o endereço IP de uma interface RED existente. O problema é que o WebAdmin pode já mostrar o novo IP, embora a firewall continue a utilizar internamente o endereço antigo. Por isso, o IP visível não confirma, por si só, que a alteração foi bem-sucedida.

O workaround documentado pela Sophos também altera o nome da filial e volta a guardar a interface:

1. Documentar o IP RED atual, a máscara de rede, o Branch Name e qualquer intervalo DHCP RED existente.
2. Em Network > Interfaces, abrir a interface RED afetada e introduzir o IP pretendido.
3. Se surgir Failed to update RED interface, voltar a abrir a interface.
4. Alterar efetivamente o Branch Name, por exemplo de Branch-Zurich para Branch-Zurich-01, e voltar a guardar com Save.
5. Em 5. Device Management > 3. Advanced Shell, verificar com o comando apenas de leitura ifconfig se o novo endereço está ativo na interface RED:

ifconfig

O nome da interface depende da configuração e pode ser identificado em Network > Interfaces. Reiniciar o dispositivo, reiniciar um serviço ou eliminar a interface RED não faz parte deste workaround.

Se o novo IP RED estiver numa rede diferente do intervalo DHCP RED anterior, o SFOS desativa o servidor DHCP RED. Este é um comportamento normal do produto e não depende da mensagem de erro. Em Network > DHCP, é então necessário adaptar o servidor existente à nova rede ou criar um novo servidor DHCP. O intervalo de leases, os mapeamentos MAC estáticos, o gateway e o DNS têm de corresponder ao novo endereçamento.

Por fim, renovar o lease DHCP num cliente atrás do RED e verificar o endereço IP, o gateway, o DNS, o estado do túnel e o acesso previsto. No Log Viewer, o tráfego deve voltar a corresponder à regra de firewall esperada. Se o IP no backend continuar antigo apesar de se voltar a guardar, não existe atualmente uma correção de produção publicada para NC-184971. As regras ou interfaces dependentes não devem ser eliminadas por tentativa; em vez disso, deve efetuar-se uma cópia de segurança da configuração e contactar o Sophos Support.

RED não recebe endereço IP

Se o RED ficar preso na etapa do roteador ou o código de erro indicar DHCP ou gateway, a causa geralmente está no local remoto.

Verificar:

• O roteador do provedor fornece um endereço IP por DHCP?
• O cabo de rede está corretamente conectado à porta WAN?
• O gateway padrão é acessível?
• Um endereço IP estático foi totalmente inserido?
• O endereço IP, máscara de sub-rede, gateway e DNS estão corretos?
• Um dispositivo intermediário está bloqueando o tráfego?

Se o DHCP no local remoto não funcionar, o RED pode entrar em um loop de reinicialização.

RED não alcança a Internet

Se o roteador ou gateway for acessível, mas o LED da Internet não ficar verde permanentemente, o problema geralmente está atrás do roteador local.

Verificar:

• A conexão de Internet funciona com um cliente normal?
• O DNS funciona?
• O NTP é acessível?
• TCP 3400, UDP 3410 ou NTP 123 estão bloqueados?
• Existe um proxy ou firewall entre o RED e a Internet?
• A conexão do provedor é estável o suficiente?
• O serviço de provisionamento está acessível por HTTPS em TCP 443?

Para o aprovisionamento RED, o dispositivo deve alcançar o Sophos Provisioning Service. A Sophos documenta *.astaro.com através de TCP 3400 e UDP 3410; os restantes destinos do fabricante e os limites de validação estão em Verificar serviços e portas de saída da Sophos Firewall.

Um cliente na mesma rede que a porta WAN do RED pode executar telnet red.astaro.com 3400 para testar a resolução DNS e o estabelecimento de uma ligação TCP. Uma ligação bem-sucedida confirma apenas que TCP 3400 está acessível; não informa sobre UDP 3410, provisionamento, autenticação ou o túnel RED.

Se a ligação TCP for bem-sucedida, mas o registo continuar a falhar, a Sophos também indica uma carga de rede elevada como possível causa. Depois de verificar o acesso à Internet, DNS e HTTPS de saída em TCP 443, pode voltar a tentar o registo mais tarde. Um teste TCP bem-sucedido não comprova nem uma carga de rede elevada nem um registo bem-sucedido; se os erros persistirem, continue a investigar as restantes causas.

RED não alcança a Sophos Firewall

Se a Internet for acessível, mas o túnel não for estabelecido, deve-se verificar o lado da firewall.

Verificar:

• O serviço RED está ativado na Sophos Firewall?
• O RED está corretamente configurado?
• A ID RED e o Código de Desbloqueio estão corretos?
• O IP público ou o FQDN da firewall é acessível?
• Administration > Device access para RED está permitido na zona WAN apropriada?
• Um Local Service ACL permite o acesso do local remoto?
• TCP 3400 e UDP 3410 chegam à firewall?
• A hora do RED está adequada para o TLS handshake no provisioning manual?
• Um RED offline alcança NTP ou a exceção Local Service ACL planeada?

Na Advanced Shell, pode-se verificar se o tráfego RED está chegando:

tcpdump -ni any port 3400 or port 3410

Se nada chegar, o problema geralmente está antes da firewall: roteador do provedor, NAT, firewall intermediária, IP público incorreto, FQDN ou bloqueio de porta.

RED reinicia continuamente

Um loop de reinicialização pode ter várias causas:

• fornecimento de energia instável
• fonte de alimentação defeituosa
• sem endereço IP por DHCP
• configuração IP estática incorreta
• portas bloqueadas
• padrão de firmware RED desatualizado
• Código de Desbloqueio incorreto
• configuração RED danificada ou incorreta

Primeiro, verifique a alimentação, os cabos e o DHCP. Depois, verifique o padrão de firmware RED, a acessibilidade das portas e a configuração. Considere um Factory Reset apenas se as verificações anteriores não revelarem a causa. Antes disso, guarde a ID RED, o Unlock Code e a configuração da interface. Se estes dados não estiverem disponíveis, poderá ser necessário contactar o Sophos Support para voltar a autorizar o dispositivo.

Túnel está verde, mas nenhum tráfego flui

Este caso é particularmente comum. O RED está conectado, mas os clientes não alcançam sistemas internos ou a Internet.

Possíveis causas:

• Falta de regra de firewall ou está muito baixa.
• Interface RED está na zona errada.
• DHCP distribui gateway ou servidores DNS incorretos.
• Falta de roteamento de retorno para a rede RED.
• NAT traduz o tráfego inesperadamente.
• Tagging VLAN não está correto.
• Recurso de segurança bloqueia o tráfego.

Ordem de verificação:

1. Verificar IP do cliente, gateway e DNS.
2. Filtrar no Log Viewer pelo IP de origem do cliente RED.
3. Verificar correspondência da regra de firewall.
4. Executar Packet Capture na interface RED e na interface de destino.
5. Verificar o caminho de retorno do sistema ou rede de destino.
6. Controlar NAT e roteamento.

Para correspondências de regras incertas, consulte Testar regra de firewall com Log Viewer, Policy Test e Packet Capture.

Se a falha ocorrer imediatamente após um reset seguido de novo provisionamento, NC-181808 também é relevante. Segundo as notas de versão, o SFOS 22.0 MR3 Build 576 de 16 de outubro de 2026 corrige um bloqueio de tráfego causado por entradas RED_DEVICE_DROP remanescentes. Isto não explica todos os túneis com estado verde sem tráfego útil. Guardar a hora do reset e do provisionamento, a build SFOS e os logs RED e de pacotes correspondentes ao teste e, perante indícios compatíveis, confirmá-los com o Sophos Support. Não eliminar entradas internas por iniciativa própria nem repetir resets; após uma correção controlada, testar novamente o mesmo percurso de ida e volta.

Os LEDs verdes não excluem um bloqueio do percurso de dados UDP. Neste caso, verifique especificamente o tráfego do túnel em 5. Device Management > 3. Advanced Shell:

tcpdump -ni any port 3410

Durante um teste controlado do cliente, utilize também Diagnostics > Packet capture e determine se o fornecedor ou um dispositivo a montante bloqueia UDP 3410. Um pacote visível numa direção ainda não confirma um percurso de ida e volta funcional; a ausência de pacotes, por si só, não identifica o ponto de bloqueio.

Tráfego VLAN não funciona

No SD-RED 60, cenários VLAN são possíveis, mas o modo de porta, ID VLAN e modo RED devem corresponder.

A ajuda de resolução de problemas da Sophos para SFOS 22 e 23 limita expressamente o tráfego VLAN a standard/unified. Além disso, as VLANs também têm de ser criadas no dispositivo RED e os modos das portas LAN da RED têm de ser definidos adequadamente. Por isso, não verifique a atribuição de VLAN apenas na firewall ou no switch. Não deduza as capacidades VLAN de outros modos de funcionamento a partir de um teste untagged bem-sucedido; verifique o modo de funcionamento concreto e o desenho das portas com base nos modos de funcionamento RED.

Verificar:

• IDs VLAN estão corretas na firewall, RED e switch.
• Porta RED está configurada como Access, Hybrid ou Tagged Trunk adequadamente.
• Porta do switch no local remoto está corretamente tagged ou untagged.
• DHCP e DNS estão planejados por VLAN.
• Regras de firewall existem para as respectivas redes VLAN.
• O modo RED escolhido suporta o cenário VLAN desejado.

Para a solução de problemas, uma rede de teste untagged simples é útil. Se esta funcionar, a causa geralmente está na ID VLAN, tagging, modo de porta ou configuração do switch.

Pontos de Acesso RED permanecem inativos

Se os Pontos de Acesso RED ou funções Wi-Fi em cenários VLAN permanecerem inativos, a opção DHCP 234 pode ser relevante. Isso é especialmente relevante em casos onde a comunicação RED ou Access Point ocorre através de interfaces VLAN. A Sophos indica SD-RED 20 e SD-RED 60 para este cenário de ponto de acesso.

Configure esta opção apenas quando o cenário se aplicar e for conhecido o endereço IP da interface da firewall que os dispositivos devem alcançar. Escolher corretamente os modos de funcionamento do Sophos RED explica a relação completa entre a zona Wi-Fi, a VLAN e a opção DHCP 234. A opção 234 não é a primeira verificação para problemas gerais de ligação RED.

Para este erro específico de VLAN, a Sophos também descreve uma recuperação retardada: Após 30 tentativas, a RED pode obter um IP de LAN do servidor DHCP e voltar a aparecer como Active. Isto não comprova que o percurso VLAN pretendido funcione. Por isso, não se limite a esperar por Active, mas verifique o IP na interface VLAN e a opção 234 guardada.

Solução no SFOS 23: Os passos seguintes aplicam-se a pontos de acesso RED configurados numa VLAN que aparecem como Inactive após um reinício e cuja VLAN não tem a opção DHCP 234 configurada:

1. Abra Network > DHCP e edite o servidor DHCP configurado para a VLAN do ponto de acesso RED.
2. Em DHCP options, procurar primeiro o código 234 e documentar o valor atual ou a ausência da opção. Não substituir cegamente uma opção existente funcional nem criar uma segunda opção concorrente. Se existir um valor, esclarecer primeiro a associação de VLAN e interface; os seguintes passos de adição aplicam-se apenas se a opção estiver em falta.
3. Em DHCP options, defina Options como Custom e introduza 234 em Code.
4. Em Value, introduza o endereço IP configurado para a interface do ponto de acesso RED ligada a esta VLAN. Este valor depende da configuração das interfaces no seu ambiente; não é o IP atribuído ao dispositivo ou a um cliente, nem um endereço público arbitrário da firewall.
5. Guarde as alterações.

Depois, verifique a opção guardada no servidor DHCP, incluindo o código e o IP da interface. O ponto de acesso RED deverá receber um endereço IP na sua interface VLAN após um curto período. Verifique esta atribuição e volte a verificar o estado do ponto de acesso RED. Se continuar como Inactive, confirme primeiro a correspondência entre o servidor DHCP, a VLAN e o IP da interface.

Solução em SFOS 22: O guia Sophos específico da versão utiliza a Device Console para o mesmo erro de VLAN, em vez da introdução no WebAdmin descrita acima. Na CLI, selecionar 4. Device Console e, antes de qualquer alteração, consultar sem modificar as associações do servidor DHCP de VLAN correto:

system dhcp dhcp-options binding show dhcpname <dhcp server name>

Substituir <dhcp server name> pelo nome do servidor DHCP na VLAN do ponto de acesso RED. Documentar a associação existente para a opção 234, incluindo o valor, ou a sua ausência. Não substituir cegamente uma associação funcional nem adicionar uma associação concorrente. Se existir um valor, esclarecer primeiro a associação de VLAN e interface. Antes de uma nova associação, esclarecer também o procedimento de gestão documentado para alterar ou remover associações de opções DHCP para a versão instalada. Se este procedimento de reversão não estiver claro, não alterar e recorrer ao Sophos Support. Adicionar especificamente a associação apenas se a opção estiver em falta:

system dhcp dhcp-options binding add dhcpname <dhcp server name> optionname dhcp_magic_ip(234) value <interface ip address>

Substituir <dhcp server name> como acima e <interface ip address> pelo IP configurado da interface do ponto de acesso RED ligada à VLAN. Não utilizar o IP do cliente. Após a alteração, executar novamente o mesmo comando de consulta system dhcp dhcp-options binding show dhcpname <dhcp server name> e verificar a associação guardada e o respetivo valor. Em seguida, verificar o IP na interface VLAN e o estado. Não aplicar em paralelo sem controlo a associação pela CLI de SFOS 22 e o procedimento WebAdmin de SFOS 23; escolher a variante adequada à versão instalada e verificar a opção guardada.

Reversão para ambas as variantes: Se a solução continuar sem efeito ou se a atribuição de endereços VLAN ou o estado piorar, restaurar o estado inicial documentado. Em SFOS 23, no mesmo servidor DHCP em Network > DHCP > DHCP options, repor o valor anterior ou remover apenas a opção 234 recém-adicionada e guardar. Em SFOS 22, utilizar para tal o procedimento de gestão de associações de opções DHCP previamente esclarecido e documentado para a versão instalada: restaurar a associação registada ou remover apenas a associação recém-criada. Não eliminar qualquer outra opção nem qualquer servidor DHCP; não experimentar sintaxe de eliminação não confirmada. Depois, voltar a verificar as opções ou associações guardadas, o IP na interface VLAN e o estado do ponto de acesso RED.

Provisionamento offline é sobrescrito

Se um RED foi provisionado online primeiro e depois provisionado offline via USB, uma configuração online antiga pode permanecer no Sophos Provisioning Server. Se o RED não alcançar a firewall, ele pode provisionar novamente online e sobrescrever a configuração USB.

Nesse caso, o RED deve ser provisionado offline novamente. Além disso, a configuração online antiga deve ser removida através do suporte da Sophos.

Diagnóstico e verificação operacional

Pontos de diagnóstico na Sophos Firewall

Para problemas RED, estes locais são úteis:

• Network > Interfaces para interface RED e status
• Administration > Device access para liberações de serviço RED
• Rules and policies > Firewall rules para tráfego da rede RED
• Diagnostics > Packet capture para verificação de caminho
• Log viewer com eventos RED, de firewall e de sistema
• Backup & firmware > Pattern updates para padrão de firmware RED
• Advanced Shell com tcpdump

Uma ligação bem-sucedida também pode ser confirmada nos logs específicos do dispositivo. Em /log/red.log surge uma mensagem como New connection from ... with ID <RED ID>. Em /log/red-<RED ID>.log aparecem depois connected OK, pushing config e, após uma nova ligação, is now re-connected. Estas linhas confirmam a ligação e a transferência da configuração, mas não um caminho de tráfego produtivo funcional. O log completo específico do dispositivo pode conter dados de provisionamento e configuração e deve ser limpo antes de ser partilhado.

Para arquivos de log e atribuição de serviços, consulte Solução de problemas da Sophos Firewall: Serviços e Logs.

Se, pelo contrário, toda a firewall iniciar no modo Failsafe com Failed to start Red server service, não se trata de um erro normal do túnel RED. O runbook de Failsafe explica a diferenciação do Build e a recolha de provas antes do recovery.

Lista de verificação operacional

Antes do lançamento:

• ID RED e Código de Desbloqueio documentados.
• Endereço público da firewall ou FQDN verificado.
• TCP 3400, UDP 3410 e NTP 123 verificados.
• Serviço RED e Device Access planejados na firewall.
• Zona, DHCP, roteamento e regras de firewall definidos.
• Modo VLAN testado antecipadamente, se necessário.

Após a conexão:

• LEDs indicam estabelecimento bem-sucedido do túnel.
• Interface RED está ativa.
• Cliente recebe IP, gateway e DNS.
• Log Viewer mostra a regra de firewall esperada.
• Sistemas de destino internos e caminho para a Internet funcionam conforme planejado.
• Padrão de firmware está atualizado.

Em operação:

• Verificar regularmente o padrão de firmware RED.
• Testar conexões do local após atualizações da firewall.
• Testar túneis RED entre firewalls separadamente dos locais SD-RED físicos.
• Após uma atualização para o SFOS 21.0 MR2 ou 21.5 MR1, verificar os efeitos da máscara /32 corrigida nos hosts do sistema RED.
• Comparar o débito RED com uma baseline local, um e quatro fluxos iPerf3 e ambas as direções.
• Manter 802.3az ou EEE desativado nas portas de switch diretamente ligadas e voltar a verificar após a substituição de switches.
• Alterar Tunnel compression e MTU apenas com um teste documentado antes e depois.
• Incluir locais RED em monitoramento, backup e planejamento de emergência.

FAQ