Planear corretamente zonas e interfaces no Sophos Firewall

Uma zona agrupa interfaces com um nível de confiança semelhante. A interface é a ligação física ou virtual, por exemplo Port1, uma VLAN, um LAG ou uma interface RED ou XFRM. Cada interface associada pertence exatamente a uma zona; as portas físicas também podem ficar sem associação.

Importante: uma zona não permite tráfego automaticamente. Mesmo entre duas interfaces na zona LAN, é necessária uma regra de firewall LAN-to-LAN adequada. O acesso à própria firewall, por exemplo ao WebAdmin, SSH ou DNS, é adicionalmente controlado através de Device Access.

Configurar diretamente zonas e interfaces

Criar uma zona

Uma zona personalizada é criada em quatro passos em Network > Zones > Add:

1. Atribuir um nome inequívoco, por exemplo Server, Management, Guest ou IoT.
2. Selecionar LAN ou DMZ como Type.
3. Em Device Access, permitir apenas os serviços locais da firewall que são realmente necessários a partir desta zona.
4. Guardar.

Em seguida, a zona deve aparecer em Network > Zones e estar disponível numa regra de firewall como Source zone ou Destination zone. O tráfego de produção só pode utilizar a zona depois de lhe ser atribuída pelo menos uma interface.

As zonas personalizadas só podem ser do tipo LAN ou DMZ. Não é possível criar zonas WAN ou VPN adicionais. O SFOS atribui automaticamente as interfaces VPN à zona VPN. O número máximo de zonas depende da versão: o SFOS 22.0 permite até 100 zonas e o SFOS 23.0 até 248 zonas.

Configurar uma interface física

O número de portas físicas disponíveis depende do modelo do appliance. Por isso, ao planear, deve verificar-se primeiro que ligações disponibiliza o equipamento concreto; as interfaces virtuais não substituem portas físicas adicionais necessárias.

Uma porta existente é editada através de Edit interface em Network > Interfaces:

1. Atribuir um Name descritivo com um máximo de 58 caracteres, por exemplo Core Switch Trunk ou MPLS Provider.
2. Selecionar a Network zone adequada.
3. Configurar IPv4 e, se necessário, IPv6.
4. Nas interfaces WAN, verificar Gateway e, se necessário, MTU e MSS.
5. Guardar e verificar depois o estado da ligação, o estado do gateway e o Log Viewer.

A zona WAN destina-se a ligações com Default Gateway. As interfaces internas são normalmente endereçadas de forma estática; as interfaces físicas disponibilizam os métodos Static, DHCP e PPPoE para IPv4. Os procedimentos de preenchimento dos campos apresentados abaixo distinguem estes métodos. Os campos de gateway aí indicados não justificam, por si só, atribuir uma interface interna à zona WAN: a zona, o endereçamento e o routing têm de corresponder ao desenho da rede e ao formulário efetivamente apresentado.

Se a interface física já tiver uma VLAN, o SFOS não permite alterar a atribuição IPv4 de Static para DHCP ou PPPoE. Em IPv6, a alteração de Static para DHCP ou Delegated também fica bloqueada. Antes desta alteração, devem registar-se as dependências das VLAN em Object usage. Em seguida, as interfaces VLAN afetadas devem ser movidas para outra Parent Interface ou removidas durante uma janela de manutenção. Só depois se altera o método de atribuição, se repõe a configuração das VLAN e se testa a conectividade.

IPv4 na porta física: Static ou DHCP

⚠️ Antes de alterar um endereço ou método, executar Object usage > Refresh, documentar o endereço, a máscara, a zona e o gateway atuais e preparar uma cópia de segurança, uma janela de manutenção e um acesso administrativo independente. A alteração pode interromper os caminhos atuais de gestão e de dados. Tratar primeiro as dependências de VLAN existentes, conforme descrito acima. O caminho de recovery pela consola descrito mais abaixo não substitui a configuração normal pelo WebAdmin.

Static: introduzir valores IPv4 fixos

1. Em Network > Interfaces, abrir a porta física correta através de Menu > Edit interface e verificar Hardware. Esta ligação física não pode ser alterada aqui.
2. Selecionar IPv4 configuration e escolher o método de atribuição Static.
3. Introduzir o endereço IPv4 previsto para esta interface. Se necessário, ajustar a máscara de sub-rede à rede planeada.
4. Preencher Gateway name e Gateway IP address de acordo com o formulário apresentado e os valores aprovados da rede ou do operador. O nome serve para identificar inequivocamente o gateway; o IP do gateway é o endereço do equipamento remoto previsto, não um endereço adicional da firewall.
5. Comparar novamente os valores e o ID da porta e guardar com Save. Depois, verificar o IP e a máscara guardados, a ligação, o estado do gateway, se aplicável, bem como routing, DNS, Device Access e os caminhos reais de dados e de gestão.

Uma ligação WAN estática meramente ilustrativa pode utilizar o endereço IPv4 192.0.2.2, a máscara 255.255.255.0, Gateway name ISP-Static e Gateway IP address 192.0.2.1. Estes endereços pertencem a uma rede reservada para documentação e não são valores de produção de um operador. Substituir o endereço, a máscara e o gateway pelos dados correspondentes fornecidos pelo próprio operador; escolher um nome que permita identificar a ligação durante a operação.

DHCP: distinguir a obtenção dinâmica dos campos documentados

1. Abrir a porta física em Network > Interfaces > Menu > Edit interface, verificar Hardware e a zona e selecionar IPv4 configuration.
2. Escolher DHCP. Este método obtém o endereço da interface a partir de um servidor DHCP; não configura um servidor DHCP para clientes.
3. O procedimento documentado de preenchimento dos campos DHCP indica também a introdução de um endereço IPv4, uma alteração opcional da máscara de sub-rede e os campos Gateway name e Gateway IP address. No entanto, a descrição não explica como estes dados interagem com o endereço obtido do servidor DHCP. Não se deve deduzir daí a existência de um endereço de substituição manual, de um fallback ou de uma substituição do lease DHCP.
4. Antes de guardar, verificar os campos efetivamente visíveis ou editáveis no build instalado e compará-los com a configuração DHCP ou do operador aprovada. Não copiar valores estáticos de exemplo para campos DHCP. Se a função de um campo obrigatório não estiver clara, não guardar a alteração; esclarecer primeiro a questão com o operador ou o suporte.
5. Depois de esclarecida a configuração, guardar com Save e verificar se é obtido um endereço adequado. Connecting significa que ainda está a ser obtido um lease; se este estado persistir, investigar primeiro a ligação, a acessibilidade do DHCP e os requisitos do operador. Em seguida, verificar IP, máscara, gateway, DNS, routing e os caminhos reais de gestão e de dados.

Se o caminho esperado não estiver disponível após uma destas alterações, restaurar o método original documentado e os respetivos valores através do acesso independente e voltar a testar. O PPPoE, por sua vez, utiliza as credenciais do operador; o procedimento completo encontra-se em Configurar e verificar uma WAN PPPoE.

IPv6 na porta física: método e modo de receção

Em IPv6 configuration, as interfaces WAN disponibilizam Static ou DHCP; as interfaces internas disponibilizam Static, DHCP ou Delegated. Delegated utiliza um prefixo delegado pelo operador para as interfaces internas. IPv6 Prefix Delegation na Sophos Firewall explica o procedimento completo com DHCP na WAN, Upstream Interface e distribuição interna. Trata-se de uma tarefa separada que não substitui a configuração estática nem a seleção do modo de receção descrita abaixo.

Static: endereço IPv6, prefixo e campos de gateway

1. Abrir a porta física em Network > Interfaces > Menu > Edit interface e selecionar IPv6 configuration.
2. Escolher Static. Os endereços IPv6 estáticos destinam-se tanto a interfaces WAN como a interfaces internas.
3. Introduzir o endereço IPv6 planeado e, se necessário, ajustar o prefixo à rede atribuída.
4. Preencher os campos Gateway name e Gateway IP address indicados no procedimento Static de acordo com o formulário efetivamente apresentado e o desenho da rede. As instruções gerais de Static também indicam estes campos na secção relativa às interfaces WAN e internas; não se deve deduzir daí que um Default Gateway interno é obrigatório ou que existe uma regra geral que limita estes campos à WAN. Esclarecer os campos obrigatórios pouco claros ou inesperados antes de uma alteração em produção.
5. Guardar com Save e verificar o endereço IPv6 e o prefixo guardados, o gateway, se aplicável, o routing IPv6, DNS e as ligações permitidas. Manter o acesso administrativo independente; se o caminho estiver incorreto, restaurar os valores IPv6 previamente documentados.

As precauções anteriores ao procedimento IPv4 também se aplicam ao IPv6: documentar o método e os valores anteriores, verificar as dependências de VLAN e não utilizar o caminho de gestão atual como única via de recuperação.

DHCPv6: Auto, Manual e Stateless

Depois de selecionar DHCP em IPv6 configuration, Mode determina como a própria firewall recebe o endereço da sua interface. Esta definição não é a mesma que a de um servidor Router Advertisement para clientes internos:

• Auto: o endereço da interface é atribuído automaticamente de acordo com o método de configuração utilizado, que pode ser DHCP only ou Stateless. Não se deve deduzir daí uma regra fixa de seleção que não esteja documentada aqui.
• Manual > DHCP only: a firewall atribui à interface o endereço e os restantes parâmetros fornecidos pelo servidor DHCPv6.
• Manual > Stateless: a firewall gera o endereço da interface através de Stateless Address Auto-Configuration (SLAAC), de acordo com os flags Managed ou Other (M/O) anunciados nos Router Advertisements. Accept other configuration from DHCP permite obter parâmetros adicionais do servidor DHCPv6. Isto não transforma o modo de receção em DHCP only.

A funcionalidade opcional DHCP rapid commit utiliza uma troca de duas mensagens (solicit e reply) em vez de quatro (solicit, advertise, request e reply). Ative-a apenas se Rapid Commit também estiver ativado no servidor DHCPv6 e for compatível com a configuração aprovada. Não utilizar esta opção como solução genérica para problemas de velocidade.

O procedimento DHCPv6 indica Gateway name e Gateway IP address. No entanto, quando Mode está definido como Manual e Stateless, não é possível definir Gateway IP address. Esta restrição pertence ao modo Stateless e não deve ser aplicada a Manual > DHCP only. Antes de guardar, comparar o modo de receção e os campos de gateway com o desenho RA/DHCPv6 previsto e o formulário visível; não forçar um IP de gateway se o modo selecionado não o permitir.

Após Save, verificar o endereço IPv6 efetivamente atribuído, o prefixo e os restantes parâmetros, bem como routing, DNS e um caminho de dados IPv6 permitido. Se o endereço estiver incorreto ou em falta, comparar primeiro com o equipamento remoto o modo selecionado, os flags RA recebidos e a acessibilidade do DHCPv6; não alternar entre modos sem estas verificações. Se o caminho de gestão for interrompido, restaurar a configuração anterior através do acesso independente.

Alinhar as definições de porta e de ligação

Em Advanced settings, deve alinhar-se Link mode, Auto-negotiation for media type, Forward Error Correction (FEC) dependente do modelo, MTU e MSS com o equipamento remoto. Para portas de 25, 50 e 100 Gbit/s, guarda-se primeiro o Link mode, volta-se a abrir a interface e carrega-se depois a configuração recomendada. Nos XGS 2100, 2300, 3100 e 3300, todas as portas SFP+ dos módulos FleXi Port têm de usar a mesma velocidade. Configurar interfaces breakout e definições de porta apresenta o procedimento completo com Show recommended settings, Load recommended configuration, ambos os passos de gravação e a apresentação diferente nas restantes portas, incluindo as de 40 Gbit/s.

O SFOS não suporta marcação DSCP para tráfego DHCP e ARP gerado pela própria firewall, mesmo quando esta funciona como cliente, relay ou servidor DHCP. Por isso, uma política não deve depender de priorização baseada em DSCP para estes pacotes. Esta restrição diz respeito ao DSCP; não significa que todas as outras formas possíveis de priorização estejam excluídas.

Em Advanced settings > Interface settings, Use default MAC address utiliza o endereço MAC predefinido da interface. No contexto de uma interface com portas membro, a primeira porta adicionada como membro fornece esse endereço MAC predefinido. Override default MAC address permite utilizar outro endereço MAC; uma reposição de fábrica restaura o endereço MAC predefinido. Isto não é uma recomendação para efetuar uma reposição nem um requisito para uma porta física PPPoE autónoma. Antes de um override justificado, verificar as dependências descritas abaixo e o caminho de recuperação.

As velocidades das portas na firewall e no equipamento remoto têm de ser compatíveis. Por exemplo, uma porta de 25 Gbit/s não pode ser ligada a uma porta de 40 Gbit/s através de cabos breakout sem uma conversão adequada. As portas de 40 e 100 Gbit/s da firewall que suportam breakout podem ser divididas em duas ou quatro portas com cabos breakout adequados. Isto não constitui uma garantia para todos os appliances ou todas as combinações de cabos; antes de planear, deve verificar-se o suporte das portas, dos transceivers e do equipamento remoto concretos.

Definir um endereço IPv4 no menu de recovery interativo

Em 1. Network Configuration > Interface Configuration, a CLI apresenta endereço IPv4 e netmask, endereço IPv6 e prefixo, zona, gateways e aliases configurados das portas físicas. Interfaces VLAN e WLAN não aparecem nesta vista.

y inicia uma alteração IPv4. O SFOS mostra sequencialmente endereço, netmask e zona atuais de cada porta; Enter sem novo valor mantém o campo. Este caminho aplica-se apenas ao Gateway mode e a valores IPv4 estáticos. Não permite configurar VLAN, DHCP, PPPoE, WLAN ou WWAN, e o diálogo IPv6 é diferente.

Antes da alteração, guardar todos os valores, ID da porta, zona, gateway, aliases e um caminho de gestão independente. Depois, verificar link, novo IP e netmask, gateway, Device Access, routing, DNS e o caminho de gestão real. Se o acesso for interrompido ou o caminho de dados estiver incorreto, restaurar os valores originais pela consola ou acesso independente.

Corrigir valores de link e MAC na Device Console

O WebAdmin continua a ser o caminho normal de configuração. A Device Console destina-se a uma correção ou recovery documentada, porque um valor de link incorreto pode interromper imediatamente o único caminho de gestão. Primeiro registam-se Port ID, peer, Link mode atual, autonegotiation, FEC, acesso administrativo independente e rollback.

A sintaxe oficial do SFOS 22 aceita 1000fd, 100fd, 100hd, 10fd, 10hd ou auto para os valores copper indicados:

Os exemplos seguintes são alternativas, não uma sequência de comandos. Substituir Port2 pela porta física verificada e escolher exatamente uma opção que corresponda à configuração aprovada da porta e do equipamento remoto; não executar ambas consecutivamente. Registar primeiro em ambos os lados os valores originais de Link mode, autonegotiation e, se aplicável, FEC, bem como o estado da ligação, a velocidade e o duplex efetivos. Garantir o acesso independente e esclarecer a restauração exata através do WebAdmin ou de um procedimento confirmado pelo suporte para o build instalado. Se os valores originais ou o caminho de recovery forem desconhecidos, parar antes da alteração CLI e contactar o suporte.

Alternativa 1: velocidade e duplex automáticos, com autonegotiation adicional ativada:

set network interface-link Port2 linkmode auto autoneg on

Alternativa 2: 1000 Mbps full-duplex, com autonegotiation adicional desativada:

set network interface-link Port2 linkmode 1000fd autoneg off

autoneg controla parâmetros de link adicionais à velocidade e duplex. Os modos FEC dependem do modelo e a Sophos não fornece uma lista universal neste comando CLI. Para portas de 25, 50 ou 100 Gbit/s, utiliza-se a configuração recomendada para o appliance e transceiver exatos, não um valor copiado de outro modelo.

Imediatamente após a alteração escolhida, comparar os valores guardados de Link mode, autonegotiation e, se aplicável, FEC no WebAdmin e no equipamento remoto com os valores de destino aprovados. Verificar em ambos os lados o estado da ligação, a velocidade e o duplex efetivos, assim como o acesso normal de gestão e os caminhos reais de dados necessários. Se um caminho estiver indisponível, instável ou degradado, restaurar através do acesso independente os valores originais exatos registados da porta e todas as definições do equipamento remoto ajustadas para a alteração, incluindo FEC se tiver sido alterado. Utilizar o caminho de restauração esclarecido previamente e repetir as mesmas verificações; a configuração de cada lado deve voltar a corresponder ao seu próprio estado inicial. Nenhum dos exemplos, nem mesmo auto com autoneg on, constitui uma reversão universal.

Um endereço MAC só é substituído por uma dependência de design comprovada. Antes de qualquer alteração, registar como estado inicial o MAC efetivo e o modo configurado (default ou override, incluindo qualquer endereço personalizado preexistente). Verificar Port Security, bindings DHCP, allowlists do operador, HA, LAG e as associações MAC/ARP do equipamento remoto. Devem estar disponíveis um acesso administrativo independente e uma janela de manutenção.

As descrições CLI do SFOS 22.0 e 23.0 indicam que default mantém o MAC existente. Isto não comprova a interpretação de que restaura o MAC predefinido após um override. default não é um comando inverso confirmado nem uma via universal de reversão; esclarecer o retorno ao estado anterior antes da alteração. Antes do override, verificar como restaurar exatamente tanto o endereço como o modo no build instalado. Se não for possível verificar o estado inicial ou a restauração, não efetuar a alteração e esclarecer com Sophos Support.

O exemplo seguinte altera o MAC e pode interromper as ligações de administração e de dados. Substituir Port2 pela porta verificada e o endereço de exemplo, administrado localmente, pelo endereço de destino aprovado e único na própria rede. Não é um valor de restauração:

set network macaddr Port2 override 02:00:5e:10:00:02

Para a restauração verificada:

• Se antes estava configurado override com um MAC personalizado, voltar a definir o endereço exato registado através do ramo override documentado, não o endereço de exemplo. O procedimento deve estar confirmado para o build instalado.
• Se antes estava configurado default, utilizar Use default MAC address em Network > Interfaces > Edit interface > Advanced settings > Interface settings apenas se esse controlo e a restauração do estado inicial registado estiverem confirmados no build instalado. Caso contrário, obter um procedimento específico do build confirmado por Sophos Support; não tentar CLI default nem uma reposição de fábrica como substitutos.

Após a alteração e após a restauração, comparar o modo configurado e o endereço efetivo com os valores previstos; na reversão, ambos devem corresponder ao estado inicial registado. Verificar também o acesso administrativo normal, a aprendizagem MAC/ARP do equipamento remoto e o fluxo de dados real afetado. Perante diferenças, interromper o procedimento através do acesso independente e esclarecer com o suporte, sem experimentar outros valores MAC.

A Sophos documenta MTU 1500 e MSS 1460 como valores predefinidos; só devem ser alterados com o processo controlado de Verificar MTU e MSS em problemas VPN.

Para IPv6, DAD attempts determina quantas mensagens Neighbor Solicitation consecutivas a firewall envia durante Duplicate Address Detection num endereço provisório (tentative). Em Allowed RA servers, introduzem-se os endereços MAC ou IPv6 dos servidores Router Advertisement dos quais esta interface pode aceitar uma configuração stateless. IPv6 Prefix Delegation na Sophos Firewall explica o prefixo do operador e a distribuição interna; Configurar IPv6 Router Advertisement descreve os flags dos clientes e a apresentação dos prefixos.

Para tarefas concretas, estão disponíveis instruções mais específicas:

• Configurar e testar uma interface VLAN
• Configurar e testar Wi-Fi gerido pelo SFOS
• Ligar APX existentes com Wireless Mesh
• Configurar uma interface LAG
• Configurar e testar um túnel GRE
• Transportar IPv6 sobre IPv4 ou IPv4 sobre IPv6 com um túnel IP
• Configurar e verificar uma WAN PPPoE
• Configurar o failover WAN com uma segunda ligação à Internet
• Configurar o Sophos SD-RED
• Proteger o Device Access
• Encaminhar Multicast entre interfaces com uma rota Multicast estática
• Planear e verificar Multicast Routing dinâmico com PIM-SM
• Configurar uma Site-to-Site IPsec VPN

Planear o modelo de zonas

Distinguir zona, interface e objeto de rede

Estes três elementos têm funções diferentes:

• Zona: descreve a área de segurança de onde vem o tráfego ou para onde se dirige.
• Interface: liga a firewall física ou virtualmente a uma rede.
• Objeto de rede: descreve o endereço IP ou a sub-rede concreta numa regra.

Uma regra só é precisa quando a zona e o objeto de rede estão corretos. Source zone: LAN em conjunto com Source networks: Any é muitas vezes desnecessariamente abrangente. Por outro lado, um objeto de rede correto não ajuda se o pacote entrar por uma zona diferente da indicada na regra.

As zonas predefinidas têm funções fixas:

• LAN para redes internas
• WAN para ligações ao fornecedor e à internet
• DMZ para sistemas expostos ou especialmente isolados
• WiFi para ambientes WLAN
• VPN para túneis Remote Access e Site-to-Site

A zona WiFi aplica-se a redes sem fios que utilizam uma zona própria. No entanto, com Bridge to AP LAN e Bridge to VLAN não é criada uma interface WiFi dedicada; o percurso do tráfego segue a associação de bridge selecionada.

Uma Wireless Network define as configurações comuns para os clientes WLAN: SSID, modo de segurança e tratamento do tráfego dos clientes. Com o Traffic Mode Separate zone, a firewall cria um túnel VXLAN associado. A seleção do Traffic Mode determina, assim, também a forma como a WLAN é ligada à firewall; não é apenas uma designação para a rede.

As zonas LAN personalizadas são adequadas, por exemplo, para Client, Server, Management, Guest, IoT, VoIP, Backup ou OT. Uma zona DMZ personalizada é adequada para servidores publicados, Reverse Proxy ou outros sistemas cujo acesso à rede interna deve ser estritamente limitado.

Nem todas as VLAN precisam de uma zona própria. É possível agrupar várias VLAN se tiverem o mesmo nível de confiança, as mesmas regras de firewall e o mesmo Device Access. Se os destinos permitidos, os acessos de gestão ou as funções de proteção forem diferentes, uma zona própria é geralmente mais clara.

Não se criam tipos de zona VPN próprios para utilizadores VPN ou túneis entre localizações. A separação é feita na zona VPN através de objetos de rede, utilizadores e regras de firewall precisos.

Definir as direções de acesso antes das regras

Antes da configuração, basta uma lista curta das direções permitidas. Por exemplo:

• Client para WAN: serviços web, DNS, NTP e aplicações necessários
• Client para Server: apenas portas de aplicações definidas
• Guest para WAN: acesso à internet, mas sem acesso às redes internas
• IoT para Server: apenas destinos necessários, como DNS, NTP ou uma plataforma de gestão
• Management para zonas internas: serviços administrativos estritamente limitados e registados
• DMZ para LAN: bloqueado por predefinição, apenas ligações explicitamente necessárias
• VPN para Server: apenas destinos e serviços autorizados

Para cada direção permitida devem ser conhecidos o destino, os serviços, a necessidade de NAT, o logging e a pessoa responsável. A partir daí são criadas as regras propriamente ditas. A estrutura, a ordem e o matching são explicados em Configurar corretamente regras no Sophos Firewall.

Verificar antes de uma alteração

Antes de criar ou mover uma interface, devem ser esclarecidos pelo menos os seguintes pontos:

• zona e nível de confiança da rede
• endereço IP, sub-rede e Default Gateway
• origem do DHCP e servidores DNS
• serviços locais da firewall necessários
• regras de firewall e NAT
• routing e SD-WAN
• cliente de teste, acesso esperado e entrada de log esperada

As alterações em produção exigem uma cópia de segurança atual, um plano de reversão e uma verificação em Object usage.

Criar e validar uma VLAN

Uma VLAN constitui um domínio de broadcast isolado: os broadcasts permanecem dentro dessa VLAN. A atribuição de várias VLAN à mesma zona de segurança não elimina esta separação de Layer 2; a zona determina o contexto das regras de firewall e do Device Access.

Uma VLAN é criada em Network > Interfaces > Add interface > Add VLAN. Os seguintes campos são decisivos:

• Interface: interface física, RED, Bridge ou LAG onde chega a VLAN tagged
• Network zone: área de segurança da VLAN
• VLAN ID: tem de corresponder à configuração do switch e, se aplicável, do Access Point
• IPv4/IPv6 configuration: em VLAN internas, normalmente um endereço de gateway estático

Por exemplo, uma VLAN de convidados pode utilizar Port3 com VLAN ID 20, zona Guest e endereço de gateway 192.168.20.1/24. No switch, a VLAN 20 tem de estar tagged no uplink para Port3; uma porta de cliente ou o SSID de convidados atribui os equipamentos finais a esta VLAN.

A firewall pode mostrar corretamente a interface mesmo que o switch envie a VLAN pela porta errada, untagged ou com outro VLAN ID. Por isso, uma VLAN só está concluída depois de todo o caminho ter sido testado:

1. Verificar VLAN ID, Parent Interface, zona, endereço IP e máscara na firewall.
2. Configurar o uplink para a firewall como Trunk com a VLAN tagged.
3. Atribuir a Access Port ou o SSID à VLAN correta.
4. Verificar DHCP, Gateway e DNS com um cliente de teste.
5. Testar um acesso interno permitido e uma ligação deliberadamente bloqueada.
6. Verificar o acesso à internet e confirmar o Firewall Rule ID esperado no Log Viewer.

Normalmente, o NAT não é necessário para tráfego interno. Se o cliente obtiver um endereço, mas não conseguir utilizar a firewall como servidor DNS nem alcançá-la por Ping, deve verificar-se primeiro o Device Access. O processo completo com tagging no switch e DHCP encontra-se em Configurar e testar uma VLAN no Sophos Firewall.

A Sophos não especifica um limite máximo fixo de VLAN por Parent Port físico para XGS Appliances. Ainda assim, com carga elevada, muitas VLAN ou desenhos HA, vários uplinks ou um LAG podem simplificar a operação e a resolução de problemas.

Escolher o tipo de interface adequado

As interfaces virtuais e os aliases são criados em Network > Interfaces através de Add interface. Aí, deve selecionar-se o tipo pretendido e abrir a respetiva configuração. As secções seguintes ajudam a escolher o tipo; um alias complementa uma interface existente, enquanto, por exemplo, VLAN, Bridge e LAG representam diferentes ligações lógicas.

Alias

Um Alias adiciona outro endereço IP a uma interface existente. É especialmente útil quando um fornecedor disponibiliza vários endereços IP públicos na mesma sub-rede.

Configurar e testar um IP alias na Sophos Firewall explica como associar o endereço adicional, utilizá-lo como objeto host em regras e NAT e verificar ARP e o tráfego do sistema.

Várias interfaces WAN separadas na mesma sub-rede podem causar problemas de ARP e gateways inacessíveis. Neste caso, um Alias na interface WAN existente ou um LAG devidamente planeado é normalmente a melhor solução. Um Alias acompanha o estado da respetiva Parent Interface e não pode ser desativado de forma independente.

Bridge

Uma Bridge liga várias interfaces em Layer 2. Pode funcionar com um endereço IP para tráfego encaminhado ou de forma transparente sem endereço IP. Para novas redes segmentadas, as VLAN são geralmente mais claras; uma Bridge é mais adequada para migrações ou desenhos deliberadamente transparentes.

O procedimento completo com Bridge Members, STP, filtros VLAN e EtherType, regras e validação está em Configurar uma interface Bridge no Sophos Firewall.

Aplicam-se restrições importantes:

• Uma Bridge não suporta Dynamic DNS, DHCP Client, PPPoE nem IPsec VPN.
• O tráfego entre Bridge Members pode continuar a exigir regras de firewall, por exemplo LAN-to-LAN.
• O HA não pode ser ativado enquanto o STP estiver ativo numa Bridge.
• Se o VLAN Filter estiver ativado, mas nenhuma VLAN for permitida, a firewall descarta todos os frames tagged; o tráfego untagged não é afetado.
• O tráfego através de uma Bridge sem endereço IP pode ser descartado sem uma entrada de log se corresponder a uma regra Web Proxy ou NAT.

Numa Bridge transparente, deve verificar-se se Web Proxy Filtering ou Source Translation são realmente necessários.

A Sophos documenta o NC-177630 para o SFOS 22.0.0 GA-Respin Build 411. O erro pode ocorrer quando o tráfego encaminhado através de uma Bridge é traduzido com SNAT ou MASQ e o tráfego de entrada e de saída utiliza o mesmo Bridge Member físico. Os pacotes de resposta são então descartados pelo Hairpin Filter sem aparecerem em drppkt. Isto também se aplica quando apenas um Bridge Member está ativo. O tráfego através de Bridge Members físicos diferentes ou sem SNAT/MASQ não é afetado.

A Sophos indica o SFOS 22.0.1 MR1 Build 490 como a versão que contém a correção. No GA-Respin Build 411, o SNAT ou MASQ do fluxo afetado só pode ser removido se a tradução não for necessária e existir um caminho de retorno para o endereço IP original do cliente. Como alternativa, o tráfego é encaminhado através de uma interface física dedicada em vez da Bridge. Se faltar um dos fatores descritos ou se o problema ocorrer no MR1 Build 490 ou numa versão posterior, deve procurar-se outra causa. O caso separado do SFOS 22 relativo a tráfego VLAN para a firewall é descrito em Verificar Bridge VLAN após o SFOS 22.

Uma Bridge através de RED pode prolongar uma rede Layer 2 entre localizações, mas deve continuar a ser uma exceção devidamente justificada.

Broadcast, ARP e tráfego Unicast desconhecido passam então pela ligação WAN. Um desenho encaminhado com sub-redes próprias por localização e regras de firewall específicas é mais estável, escalável e fácil de diagnosticar.

LAG

Um Link Aggregation Group combina duas a quatro interfaces físicas num uplink lógico. As VLAN podem depois ser configuradas sobre esse uplink.

Os modos de funcionamento habituais são:

• Active-Backup: uma ligação está ativa e outra assume o tráfego em caso de falha.
• LACP (802.3ad): várias ligações podem ser utilizadas em paralelo; a firewall e o switch têm de estar configurados de forma idêntica.

Podem ser utilizadas como membros interfaces físicas não associadas com configuração estática. As interfaces PPPoE, Cellular WAN e WLAN estão excluídas. Com LACP, as portas têm de ser do mesmo tipo e ter a mesma velocidade.

A xmit-hash-policy distribui as ligações pelos links. Uma única ligação TCP normalmente não fica mais rápida, porque permanece num só link. O LAG oferece sobretudo redundância e maior largura de banda total para várias ligações paralelas.

O LAG e o failover WAN têm funções diferentes: um LAG agrega links físicos numa ligação lógica. As ligações à Internet independentes são, por sua vez, utilizadas através dos respetivos gateways WAN em Network > WAN link manager. Vários gateways ativos permitem distribuir a carga pelas ligações disponíveis; um gateway de backup pode assumir o tráfego quando é detetada uma falha. Isto não garante nem a continuidade sem interrupções das sessões existentes nem mais largura de banda para uma única ligação. Configurar o failover WAN com uma segunda ligação à Internet explica o procedimento e como verificar o seu funcionamento.

WAN móvel e WWAN1

Ao ativar o Cellular WAN, o SFOS cria a interface WWAN1. Esta faz parte da ligação móvel e não é equivalente a uma VLAN ou a um alias criado livremente. Devem continuar a respeitar-se as restrições de HA descritas abaixo e a exclusão como membro de um LAG.

No SFOS 23.0, Network > Interfaces disponibiliza, no Menu da interface WWAN, as ações Connect e Disconnect para ligar ou desligar o modem Cellular WAN. Reset reinicia o modem e só está disponível para modelos 5G da Quectel e da Sierra Wireless, não para outros modelos ou dongles USB. Não se deve pressupor que estas ações descritas para o SFOS 23.0 têm um caminho de cliques idêntico no SFOS 22.0.

Antes de utilizar Disconnect ou Reset, deve garantir-se um acesso administrativo independente e uma janela de manutenção, caso a ligação móvel transporte tráfego de produção ou o acesso de gestão. Um reinício do hardware que implique encerrar a firewall interrompe todo o tráfego da firewall; também neste caso, deve planear-se um acesso administrativo independente e uma janela de manutenção. Para reiniciar o hardware de um modelo não suportado, deve primeiro encerrar-se a firewall, retirar e voltar a ligar fisicamente o modem e, em seguida, voltar a iniciar a firewall; não se deve efetuar qualquer alteração física ao hardware WWAN enquanto a firewall estiver em funcionamento. Depois, deve verificar-se o estado da interface e os caminhos reais de dados e de gestão necessários. Reiniciar o modem não é uma solução garantida para uma falha de ligação cuja causa não foi esclarecida.

TAP / Discover Mode

Uma porta física em Discover Mode recebe uma cópia de tráfego espelhada pelo switch. Não está inline e não pode bloquear o tráfego observado nem controlá-lo com políticas de segurança. É útil para um inventário ou uma prova de conceito, mas não constitui um caminho de proteção em produção.

Na vista de interfaces, esta porta aparece como Discover, physical (TAP). Isto permite distingui-la de uma interface normal no caminho de dados de produção.

Configurar o Discover Mode com TAP e SPAN explica a configuração completa com porta SPAN, comandos da Device Console, Packet Capture, Security Audit Report e limites de HA.

XFRM para route-based IPsec

No IPsec route-based, distingue-se entre ligações Any-to-any e ligações com Traffic Selectors específicos. Quando ambas as sub-redes estão definidas como Any, o SFOS cria automaticamente uma interface XFRM na zona VPN:

• Any-to-any: é necessário atribuir um endereço IP à interface XFRM criada automaticamente em Network > Interfaces. Em seguida, as rotas estáticas, SD-WAN ou dinâmicas determinam o tráfego enviado pelo túnel.
• Traffic Selectors: o SFOS cria automaticamente uma rota estática quando o túnel é estabelecido. Se for apresentada uma interface XFRM, não lhe atribuir um endereço IP nem rotas manuais.

A documentação oficial do SFOS 22 e do SFOS 23 contradiz-se quanto à criação de XFRM para sub-redes específicas: «Configure an XFRM interface» indica que não é criada nenhuma XFRM, enquanto «Route-based VPN» descreve a criação de uma por configuração. Não se deve, por isso, pressupor que a interface está sempre presente ou sempre ausente. Expandir a Listening interface em Network > Interfaces e verificar a visibilidade real no build instalado. A secção Traffic Selectors de Configurar uma Site-to-Site IPsec VPN explica as verificações existentes de visibilidade e tráfego.

Em ambos os casos, o tráfego VPN precisa de regras de firewall adequadas. Em Administration > Device access, o serviço IPsec na zona WAN permite pedidos de ligação IPsec recebidos. O Ping para um endereço local da firewall a partir da zona VPN é permitido separadamente através de Ping/Ping6 em Administration > Device access. O Ping entre hosts através do túnel VPN é, por sua vez, tráfego de passagem e requer rotas e regras de firewall adequadas; a permissão em Device Access não autoriza este tráfego.

Uma XFRM não é desativada diretamente em Network > Interfaces, mas através da respetiva ligação em Site-to-site VPN > IPsec. Se a SSL/TLS Decryption for aplicada ao tráfego IPsec, a Sophos exige que a MTU da XFRM seja pelo menos 113 bytes inferior à MTU da Listening Interface. Com uma MTU de 1400 na Listening Interface, a MTU da XFRM não pode exceder 1287. Este limite específico do produto aplica-se ao FastPath Offload e não é um valor geral para todos os túneis. O processo completo é descrito em Verificar MTU e MSS em problemas de VPN.

RED

Uma interface RED liga uma localização remota através de um túnel encriptado. O modo de funcionamento determina quanto tráfego passa pela central:

• Standard/Unified: a firewall central gere e filtra todo o tráfego da localização. Se o túnel falhar, o acesso à internet também pode ficar indisponível.
• Standard/Split: apenas as redes de destino definidas passam pelo túnel; o tráfego de internet sai localmente e não é filtrado de forma central.
• Transparent/Split: o RED funciona de forma transparente numa rede existente. É flexível, mas mais difícil de planear e diagnosticar.
• Manual/Split: a configuração da rede é feita de forma mais manual e pode proporcionar autonomia local.

O serviço RED tem de estar ativo em System services > RED. A ligação requer normalmente TCP 3400, UDP 3410 e NTP através de UDP 123. O DNS, a hora correta do sistema e o acesso de saída à internet também têm de funcionar.

O comportamento das VLAN depende do modelo RED, do modo de funcionamento, do modo das portas LAN e da configuração WLAN. A Sophos recomenda Standard/Unified quando são utilizadas VLAN atrás do RED; numa SD-RED 60, o VLAN tagging só é possível neste modo. A WLAN com Bridge to VLAN segue regras próprias. Escolher o modo de funcionamento correto do Sophos RED explica DHCP, gateway, caminho da internet e comportamento em caso de falha nos quatro modos. O provisioning, o estado dos LED e a resolução de problemas são explicados em Configurar o Sophos SD-RED.

Verificar o estado e o Device Access

Estado da interface

Os estados em Network > Interfaces indicam se deve ser verificada primeiro a ligação ou a política:

• Not configured: nenhuma zona atribuída
• Connected: configurada e ligada
• Connecting: a obter um endereço, por exemplo através de DHCP
• Disconnected: o endereço foi libertado
• Disconnecting: o endereço está a ser libertado
• Unplugged: sem ligação física; no caso de WiFi, pode não existir Access Point ou Wireless Network
• Not available: FleXi Port configurada sem um módulo FleXi Port instalado

Com o estado Not configured ou Unplugged, as regras de firewall não são o primeiro ponto de diagnóstico. Devem verificar-se primeiro Zone Binding, cabo, SFP, velocidade da porta, porta do switch e DHCP ou PPPoE.

Serviços locais da firewall

Em Administration > Device access, define-se por zona se serviços locais como HTTPS, SSH, User Portal, VPN Portal, DNS, Ping/Ping6, Captive Portal, RADIUS SSO ou Wireless Protection estão acessíveis.

Estas permissões aplicam-se à própria firewall. O tráfego de passagem entre redes é controlado por regras de firewall. HTTPS e SSH só devem ser permitidos a partir de uma rede de gestão ou através de uma Local service ACL exception rule específica. O serviço DNS é necessário quando os clientes utilizam a firewall como servidor DNS.

⚠️ Se os clientes puderem utilizar o Web Proxy da firewall, o SFOS trata os pedidos HTTP e HTTPS como pedidos Proxy internos. Assim, WebAdmin, Captive Portal, VPN Portal ou User Portal podem ficar acessíveis mesmo que o respetivo serviço esteja desativado para a zona dos clientes. Neste desenho, o acesso ao Proxy e aos portais locais tem de ser verificado separadamente.

Tratar dependências e alterações com segurança

Object Usage antes de editar ou eliminar

Zone Binding, DNS, Gateways, SD-WAN, Interface Hosts, VLAN, Dynamic DNS, DHCP, regras de firewall, NAT e VPN podem depender da mesma interface. Object usage mostra estas referências.

O contador apresentado só é atualizado automaticamente uma vez por dia. Antes de alterar ou eliminar, deve clicar-se em Refresh e documentar as dependências importantes. Nem todas as referências podem ser editadas na janela pop-up. Os gateways WAN e as configurações CLI têm de ser alterados na respetiva página de configuração ou na CLI.

Para as referências editáveis em regras ou políticas, o contador permite aceder à configuração concreta:

1. Na coluna Usage, clicar no número de utilizações do objeto em causa. A janela pop-up mostra as configurações que utilizam esse objeto.
2. Expandir a categoria correspondente através do ícone de mais para apresentar as respetivas regras ou políticas.
3. Clicar na regra ou política em causa para a editar. Remover aí a referência ao objeto ou substituí-la pelo objeto de substituição pretendido.

Após a verificação das dependências, a ativação ou desativação é feita em Network > Interfaces, no Menu da interface em causa, através de on ou off, respetivamente. Antes de utilizar off, deve garantir-se um acesso administrativo independente e um caminho de recuperação; a ação pode interromper o caminho de dados que está a ser utilizado. Alias e XFRM não podem ser desativados aqui de forma independente.

Ao desativar uma interface, a respetiva configuração é mantida. Os túneis IPsec em que a firewall é o iniciador são desligados imediatamente. Os túneis em que a firewall responde e as ligações Remote Access terminam, no máximo, por inatividade ou Dead Peer Detection.

Uma interface virtual é eliminada em Network > Interfaces através de Menu > Delete interface. Esta ação só deve ser executada após Refresh em Object usage, uma verificação documentada das dependências e a preparação de uma cópia de segurança e de um caminho de recuperação; não remove apenas a entrada visível da interface.

Ao eliminar uma interface virtual, o SFOS elimina todas as regras de firewall que a utilizam, mesmo que a regra contenha outras interfaces. Também remove os Zone Bindings dependentes, os servidores ou relays DHCP, as entradas ARP estáticas e de proxy ARP, os Protected Servers e as regras de firewall baseadas neles, os Interface Hosts e as respetivas referências em grupos, assim como as rotas unicast e multicast. As interfaces Alias acompanham a respetiva interface principal; as interfaces XFRM são geridas através da ligação IPsec.

Mesmo uma simples edição pode afetar Zone Binding, DNS, gateways, rotas e perfis SD-WAN, Interface Hosts, VLANs e Dynamic DNS. Após a edição ou eliminação, as ligações podem deixar temporariamente de responder ou falhar. Por isso, após cada alteração, verificar os caminhos reais de dados e de gestão, e não apenas a entrada da interface guardada.

Remover deliberadamente a configuração de uma porta física

Uma porta física permanece no equipamento; apenas a sua configuração pode ser removida. off e Network zone None não são equivalentes: off mantém a configuração, enquanto None remove a configuração IP. Esta ação destina-se a libertar deliberadamente uma porta que já não é necessária, não a servir de primeiro passo de reparação em caso de Unplugged ou de um gateway inacessível.

⚠️ Antes da remoção, executar Object usage > Refresh, documentar e migrar as dependências e testar a cópia de segurança e o acesso administrativo independente. Registar os endereços IP, as máscaras ou prefixos, a zona, os gateways e os aliases para reverter a alteração. Não repor a porta através do único caminho de acesso de gestão.

1. Em Network > Interfaces, abrir a porta física em causa.
2. Definir Network zone como None. A configuração IP desaparece logo no formulário; verificar novamente o ID da porta antes do passo seguinte.
3. Guardar com Save.
4. Na vista geral devem aparecer Unbound, o estado Disabled e o endereço IP N/A. Em seguida, verificar através do acesso independente se os outros caminhos de dados e de gestão necessários continuam a funcionar.

Se tiver sido reposta a porta errada, restaurar a sua zona e configuração IP anteriores através do acesso independente ou da consola. Restaurar as configurações dependentes removidas com base no inventário anterior ou na cópia de segurança; voltar a atribuir uma zona não substitui esta operação. Por fim, testar novamente a ligação, o gateway, DHCP, DNS, o encaminhamento, as regras e Device Access.

HA e alterações remotas

As interfaces HA Link dedicadas pertencem a uma zona DMZ. Outras interfaces monitorizadas ou utilizadas para administração podem estar noutras zonas.

O Active-Active HA requer interfaces configuradas estaticamente. O Cellular WAN é desativado com HA. O Active-Passive pode utilizar interfaces WAN com endereçamento dinâmico, mas ligações como PPPoE não são necessariamente transferidas com a respetiva sessão durante um Failover.

Antes de uma alteração em produção:

1. Documentar a configuração e as dependências.
2. Preparar a janela de manutenção, o momento de reversão, a cópia de segurança e um plano de reversão concreto.
3. Testar um acesso administrativo independente, por exemplo Sophos Fusion (anteriormente Sophos Central), uma segunda WAN, uma rede de gestão separada ou uma pessoa no local.
4. Preparar um cliente de teste ou tráfego de teste inequívoco e, em seguida, adicionar e testar a nova zona ou o novo caminho.
5. Verificar ligação, IP, Gateway, DHCP, DNS, regras de firewall, NAT e Device Access.
6. Eliminar os objetos antigos apenas quando o novo caminho estiver estável.

Para um VLAN Trunk, o plano de reversão deve incluir o VLAN ID anterior, a Native VLAN e o perfil da porta do switch. Nas alterações WAN são importantes os valores do fornecedor e as rotas SD-WAN; com XFRM, também o túnel, o routing e ambas as direções das regras de firewall.

Diagnosticar sistematicamente

Normalmente, a causa pode ser isolada mais depressa começando pelo sintoma:

• A interface está unbound ou disabled: Verificar primeiro se a porta foi deliberadamente deixada sem uma zona atribuída ou se a interface foi desativada. Se a porta estava anteriormente em produção, comparar a zona e a configuração IP esperadas com a configuração documentada e restaurá-las através de um acesso independente. None não é uma reparação, mas remove a configuração IP; o procedimento deliberado é explicado acima em Remover deliberadamente a configuração de uma porta física.
• A VLAN não funciona: comparar VLAN ID, Parent Interface, Trunk, Tagged/Untagged e Native VLAN.
• A firewall não está acessível por Ping, HTTPS ou DNS: verificar primeiro Device Access e Local Service ACL, não uma regra de firewall normal.
• O tráfego interno está bloqueado: verificar Source zone, Destination zone, objetos de rede, routing, Services e ordem das regras.
• O WAN Gateway permanece inativo: verificar ligação, IP, Gateway, dados de acesso PPPoE e WAN Link Manager.
• Várias portas WAN estão na mesma sub-rede: evitar problemas de ARP e considerar Alias ou LAG.
• SFP ou Port Speed não correspondem: Diagnosticar SFP e SFP+ de forma sistemática explica como comparar transceiver, cabo, breakout e velocidade nos dois lados.
• VPN ou PPPoE estão instáveis: verificar MTU e MSS.

Para o diagnóstico propriamente dito, recomenda-se esta sequência:

1. Network > Interfaces: ligação, IP, Zone e Gateway
2. Network > Zones: tipo de zona e Device Access
3. Hosts and services: objetos de rede e Service Objects
4. Firewall rules: direção, ordem, Services e Logging
5. NAT rules: Original e Translation
6. Log viewer: Rule ID ou motivo do descarte
7. Diagnostics > Tools > Packet capture: entrada e encaminhamento do pacote

Se a regra parecer correta, mas não fizer matching, consulte A regra de firewall não faz matching. O fluxo dos pacotes é explicado em Utilizar Packet Capture no WebAdmin.

Lista de verificação operacional

• zonas planeadas e documentadas por nível de confiança
• zona, interface e objeto de rede não confundidos
• VLAN ID, Parent, Trunk e Gateway verificados
• Device Access limitado, especialmente para HTTPS, SSH, DNS, Ping e portais
• regras de firewall criadas com zonas, redes, serviços e Logging específicos
• Alias verificado para endereços IP adicionais do fornecedor na mesma sub-rede
• DHCP, DNS, NTP, routing e, se necessário, NAT testados
• Object Usage atualizado e verificado antes de alterações
• acesso administrativo independente e plano de reversão preparados
• estado da ligação, Log Viewer e Packet Capture verificados após a alteração

FAQ