Configurar e testar o DHCP Relay no Sophos Firewall

Um DHCP Relay encaminha pedidos DHCP de uma rede de clientes para um servidor noutra rede. No Sophos Firewall, abre-se Network > DHCP, cria-se em Relay um agente para a interface dos clientes e introduz-se o endereço IP do servidor DHCP.

Procedimento rápido: selecionar a interface dos clientes, introduzir o servidor DHCP, verificar no servidor o scope correto e o caminho de retorno, renovar o lease e capturar a comunicação com port 67 or port 68. Relay through IPsec só é ativado com IPsec policy-based, não com uma VPN route-based. Para uma VPN route-based, esclarecer primeiro com o Sophos Support as divergências entre as fontes descritas abaixo e o suporte para o build exato; este procedimento rápido não constitui uma aprovação dessa configuração.

O exemplo utiliza a rede de clientes 10.20.0.0/24, a interface relay 10.20.0.1 e o servidor DHCP 172.16.16.17. Este é um exemplo IPv4: adaptar todos os endereços, a interface dos clientes e o nome à própria rede. O scope é o intervalo de endereços, juntamente com os parâmetros de rede, a partir do qual o servidor atribui leases. O gateway deve estar na rede de clientes e ser acessível; um servidor DNS deve ser acessível a partir do cliente. Antes da alteração, guardar uma cópia dos scopes, agentes relay e rotas existentes e utilizar um cliente de teste que obtenha endereços automaticamente por DHCP.

Pré-requisitos e limites

O servidor DHCP deve ter um scope para 10.20.0.0/24. O Sophos Firewall não distribui o lease diretamente; utiliza o endereço da interface relay para que o servidor selecione o scope correto.

O relay precisa de uma rota para o servidor, e o servidor de um caminho de retorno para 10.20.0.1.

Se, em vez disso, o firewall tiver de distribuir endereços diretamente na rede de clientes ligada, consultar Configurar o Sophos Firewall como servidor DHCP.

As opções DHCP são configuradas no servidor que atribui o lease.

Também é possível ter um servidor DHCPv4 e um relay no mesmo Sophos Firewall:

• O servidor escuta noutra interface.
• Accept client request via relay está ativado.
• Existe um scope de servidor próprio para cada sub-rede de clientes, com intervalo de leases, máscara de sub-rede, gateway e DNS adequados.

O agente relay utiliza a respetiva interface dos clientes e, como destino, o endereço da interface do servidor. Para os clientes na sub-rede do servidor, mantém-se a atribuição direta sem relay.

Um servidor DHCPv6 e um DHCPv6 Relay não podem estar ativos simultaneamente. Se o firewall tiver de distribuir os próprios endereços IPv6, Configurar um servidor DHCPv6 no Sophos Firewall explica o procedimento separado com Router Advertisement, DUID e verificação do lease.

Aplicam-se os seguintes limites à configuração:

• A interface relay encontra-se na mesma sub-rede dos clientes e não pode ser a interface do servidor DHCP.
• Os agentes relay podem ser configurados em interfaces físicas e virtuais, como VLAN, Wireless ou Bridge, mas não num Interface Alias.
• Não se cria um agente relay na sub-rede do servidor DHCP.
• É criado um agente relay separado para cada sub-rede de clientes.
• Podem ser configurados até oito servidores DHCP por agente relay. O pedido é enviado a todos e o cliente utiliza o primeiro Offer.
• O servidor DHCPv4 e o DHCPv4 Relay podem funcionar em simultâneo no mesmo firewall, mas não na mesma interface.
• O servidor DHCPv6 e o DHCPv6 Relay não podem estar ativos em simultâneo no mesmo firewall.
• Entre o cliente e o relay são necessários UDP 67 e 68; relay e servidor comunicam através de UDP 67. O servidor necessita de um caminho de retorno para o IP do relay 10.20.0.1.

Vários destinos relay devem fornecer parâmetros de rede e opções consistentes ao mesmo cliente, mas com atribuição de endereços coordenada (failover dos servidores de acordo com a documentação dos servidores) ou intervalos de atribuição dinâmica sem sobreposição. Caso contrário, respostas diferentes provocam um comportamento difícil de reproduzir.

Configurar DHCP Relay sem VPN

1. Abrir Network > DHCP.
2. Em Relay, clicar em Add.
3. Introduzir um nome único, como relay-clients-vlan20.
4. Para este exemplo, selecionar IPv4 em IP version. Para IPv6, não utilizar os endereços IPv4 nem as portas UDP deste guia.
5. Em Interface, selecionar a interface dos clientes VLAN20 - 10.20.0.1.
6. Em DHCP server IP, introduzir o servidor 172.16.16.17, adicioná-lo à lista com o botão de mais e confirmar que aparece na lista.
7. Manter Relay through IPsec desativado e guardar.

Em seguida, renovar um lease com um cliente de teste. Os pedidos relay são tráfego gerado pelo sistema, pelo que este procedimento não precisa de uma regra dedicada no firewall relay. Os dispositivos entre o relay e o servidor têm, ainda assim, de permitir UDP 67 nos dois sentidos; o segmento dos clientes utiliza UDP 67/68. Se o cliente não receber um endereço, verificar primeiro se o servidor tem um scope para 10.20.0.0/24 e conhece uma rota para a interface relay. Em caso de problemas com VLAN, consultar Configurar uma interface VLAN no Sophos Firewall.

API XML: identidade e limite de validação IPv6

Na automatização, a mesma configuração corresponde ao objeto DHCPRelay: Name identifica o agente relay, Interface a interface dos clientes, IPFamily a família escolhida deliberadamente, IPv4 ou IPv6, e DHCPServerIP a lista de servidores. A documentação de adição/edição do SFOS 22 e 23 assinala estes quatro campos como obrigatórios; o valor predefinido documentado para IPFamily é IPv4. DHCPServerIP é descrito como um ARRAY com IPADDRESS e IPADDRESS6: são permitidos vários valores, os duplicados são ignorados e LINKLOCAL está excluído. Assim, continuam a ser possíveis vários destinos relay; o único campo de exemplo com um marcador de posição não comprova nem a serialização da lista nem uma codificação IPv6. Manter deliberadamente o estado de Relay through IPsec adequado à variante VPN explicada abaixo, sem o deduzir de um exemplo da API.

A tabela de parâmetros indica também um máximo de 15 caracteres para DHCPServerIP. Este limite não é, em geral, compatível com a representação de endereços IPv6 permitida por IPADDRESS6: a documentação é inconsistente neste ponto e não comprova como o validador do build específico processa IPv6. Daqui não se pode concluir que o produto não suporta DHCPv6 Relay, nem deduzir uma codificação alternativa ou uma autorização para encurtar endereços.

Para IPv6, utilizar primeiro a configuração manual no WebAdmin e, antes de automatizar IPv6, esclarecer com o Sophos Support o esquema, a validação de endereços e o formato da lista de servidores para a versão e o build exatos do SFOS. Uma configuração guardada na GUI ou a obtenção bem-sucedida de um lease por um cliente não confirma a validade de um pedido XML IPv6. As verificações do cliente e do fluxo de pacotes, bem como o rollback em função do estado anterior descritos abaixo, continuam a ser necessários; os endereços IPv4 e as portas UDP deste exemplo não devem ser utilizados para IPv6.

Alterar o intervalo de atualização do Relay apenas de forma controlada

A Device Console apresenta o intervalo global dos pacotes de atualização do DHCP Relay com:

system dhcp dhcp-relay-refresh-interval show

O valor predefinido documentado é 10 segundos. A Sophos indica dois limites superiores diferentes na mesma página do SFOS 22: a sintaxe mostra 10000, enquanto a descrição da opção indica 1000 segundos. Por isso, não se utiliza um valor superior a 1000 apenas com base na linha de sintaxe. Qualquer necessidade excecional deve ser confirmada primeiro com o Sophos Support.

A alteração utiliza este modelo:

system dhcp dhcp-relay-refresh-interval set seconds <seconds>

O marcador é substituído por um valor verificado. O intervalo não é alterado como tuning geral e não corrige um scope de servidor em falta, routing, IPsec ou regras de firewall. Primeiro, registar o valor atual; depois, utilizar show, obter um novo lease de cliente e verificar o fluxo UDP 67/68. O rollback repõe o valor consultado anteriormente.

DHCP Relay através de IPsec route-based

A ajuda de SFOS 22 e SFOS 23 documenta o DHCP Relay através de XFRM para um servidor DHCP externo situado atrás do firewall central. A configuração descrita utiliza um túnel route-based Any-to-Any. Os Traffic Selectors route-based não estão confirmados para este procedimento.

⚠️ A ajuda oficial é contraditória em SFOS 22 e SFOS 23: tanto a visão geral DHCP como Routing and NAT for IPsec tunnels negam a possibilidade de DHCP Relay através de uma VPN route-based. Por outro lado, Add a DHCP relay e o guia específico para route-based descrevem a configuração Any-to-Any apresentada a seguir. Não se pode concluir daí que exista suporte confirmado do produto. Se os campos forem diferentes, não recorrer às opções policy-based; esclarecer antes a topologia e o build exato com o Sophos Support.

⚠️ O conflito entre as fontes continua por resolver; a arquitetura está documentada, mas não foi confirmada nem testada como capacidade do produto. Antes da implementação, o Sophos Support tem de esclarecer o suporte para o build exato do SFOS e a topologia Any-to-Any com um servidor DHCP externo. Essa confirmação é um pré-requisito, não uma prova já disponível neste artigo. Até haver esclarecimento, não efetuar alterações à configuração route-based segundo este procedimento.

A configuração documentada inclui os seguintes pré-requisitos. Até ao esclarecimento com o Sophos Support, estes detalhes servem apenas para planeamento; as alterações à configuração só devem ser efetuadas após confirmação:

1. Ligações IPsec Any-to-Any em ambos os firewalls.
2. Interfaces XFRM endereçadas com gateway.
3. Rotas estáticas, SD-WAN ou dinâmicas em ambos os firewalls: do relay para o servidor DHCP e, para a resposta, de volta ao IP do relay 10.20.0.1.
4. Acesso IPsec permitido em Administration > Device access para as interfaces WAN envolvidas.
5. Uma regra na sede central de VPN para a zona do servidor com Source 10.20.0.1, Destination 172.16.16.17 e Service DHCP.

Na localização remota, a interface dos clientes é configurada como agente relay; Relay through IPsec permanece desativado.

O pedido relay é tráfego gerado pelo sistema nessa localização e não necessita de uma regra de firewall própria para DHCP.

Uma rota SD-WAN utiliza:

• Any como Source.
• O host 172.16.16.17 como Destination.
• DHCP como Service.
• O gateway XFRM remoto.

Na localização central, a rota de retorno do servidor DHCP para o IP do relay 10.20.0.1 passa pelo gateway XFRM.

Para impedir que este tráfego seja encaminhado por outro gateway em caso de falha do túnel, ativar Route only through specified gateways nas duas rotas SD-WAN dedicadas.

Para configurar as rotas SD-WAN dedicadas, após a confirmação:

1. Abrir Routing > SD-WAN routes.
2. Selecionar IPv4 > Add e atribuir um nome único.
3. Em Link selection settings, selecionar Primary and backup gateways.
4. Em Primary gateway, introduzir o gateway XFRM adequado do respetivo firewall.
5. Guardar.

A regra de firewall na localização central é criada em Rules and policies > Firewall rules > Add firewall rule > New firewall rule, com os hosts e o serviço indicados acima.

A Destination zone corresponde à rede real do servidor, por exemplo, DMZ, e não é automaticamente LAN.

A opção fail-closed impede o encaminhamento por uma rota alternativa, mas também significa que, em caso de falha do túnel, não é possível obter novos leases por este caminho.

As regras VPN gerais do túnel Any-to-Any também têm de existir. A configuração do túnel e das rotas XFRM é descrita em detalhe em Configurar IPsec Site-to-Site no Sophos Firewall.

⚠️ Este procedimento route-based aplica-se a um servidor DHCP externo atrás do firewall central. Uma interface do Sophos Firewall como servidor DHCP central não é suportada neste cenário.

DHCP Relay através de IPsec policy-based

Com IPsec policy-based, Relay through IPsec é ativado na localização remota.

As sub-redes locais e remotas da ligação IPsec devem abranger a interface relay e o servidor DHCP. Se um servidor DHCP externo estiver atrás do firewall central, são necessárias duas regras nesse firewall.

É necessário que exista um túnel funcional. Se ainda for preciso criá-lo, fazê-lo em Site-to-site VPN > IPsec > IPsec connections > Add com Connection type: Policy-based:

• Na localização remota, Gateway type: Initiate the connection.
• Na localização central, Respond only.

Listening interface é a interface WAN do próprio firewall e Gateway address é o endereço WAN do outro lado.

A autenticação e o Preshared key devem coincidir; as redes locais e remotas são configuradas de forma inversa no outro lado. No exemplo com servidor externo, são 10.20.0.0/24 e a rede do servidor efetivamente utilizada.

Permitir o acesso IPsec a partir de WAN em Administration > Device access.

Na localização remota, o tráfego relay gerado pelo sistema não necessita de uma regra de firewall criada automaticamente.

Na localização central, as regras criadas automaticamente podem ser limitadas aos hosts, zonas e serviços DHCP indicados abaixo. Não remover as regras existentes para outro tráfego VPN.

• De VPN para a zona do servidor: rede relay para servidor DHCP, Service DHCP.
• Da zona do servidor para VPN: servidor DHCP para rede de clientes, Service DHCP.

Para o procedimento policy-based documentado, o endereço de origem do tráfego relay gerado pelo sistema deve ser definido como o IP do relay através de sys-traffic-nat.

Os comandos seguintes são executados na Device Console após o acesso por SSH.

A ajuda específica de Routing/NAT para SFOS 22 e 23 distingue o tráfego encaminhado do tráfego gerado pelo sistema: para este último, não é necessária uma system ipsec_route adicional.

No entanto, a visão geral de DHCP ainda indica um passo de criação de uma rota IPsec. Esta diferença não justifica a criação sistemática de uma rota adicional: verificar primeiro a rota existente e o fluxo de pacotes e, se o comportamento do build for diferente, contactar o Sophos Support.

NAT não substitui uma rota.

• destination continua a ser o endereço do servidor.
• snatip é o endereço de origem do relay, não o endereço do servidor.
• Uma regra WAN-MASQ normal não substitui sys-traffic-nat.

Antes da alteração, guardar o estado atual:

show advanced-firewall

⚠️ sys-traffic-nat add altera a configuração NAT global para o tráfego gerado pelo sistema. Destination e endereço de origem têm de corresponder ao túnel IPsec e ao caminho de retorno.

No exemplo, o endereço de origem da interface relay é definido para o tráfego destinado ao servidor DHCP:

set advanced-firewall sys-traffic-nat add destination 172.16.16.17 snatip 10.20.0.1

Em seguida, executar novamente show advanced-firewall e verificar se existe exatamente esta entrada. O servidor tem de conseguir alcançar 10.20.0.1 através do túnel. Se a mesma entrada já existia antes da alteração, não faz parte do rollback deste procedimento.

Para uma entrada criada por este procedimento, o rollback é:

set advanced-firewall sys-traffic-nat delete destination 172.16.16.17 snatip 10.20.0.1

Outros casos específicos de routing policy-based e procedimentos de versões SFOS anteriores são explicados em Criar uma IPsec Route no Sophos Firewall.

Quando a sede central é o servidor DHCP

Apenas neste cenário policy-based, em que o Sophos Firewall da sede central é o próprio servidor DHCP, manter Create firewall rule desmarcado nas ligações IPsec de ambos os firewalls. A comunicação DHCP com o servidor integrado no firewall não equivale ao encaminhamento para um servidor externo; as regras de encaminhamento da sede descritas anteriormente pertencem ao cenário com servidor externo. Manter o acesso IPsec a partir de WAN em Administration > Device access e as regras necessárias para o restante tráfego de utilizadores da VPN.

Se o próprio Sophos Firewall central funcionar como servidor DHCP com IPsec policy-based:

1. Criar ou editar um scope de servidor em Network > DHCP > Server.
2. Ativar Accept client request via relay.
3. Introduzir um intervalo de leases de 10.20.0.0/24 e definir 10.20.0.1 como gateway.

No agente relay, introduzir a interface do servidor do firewall central em DHCP server IP. No exemplo NAT anterior, o endereço dessa interface substitui, de forma correspondente, 172.16.16.17.

Um exemplo adaptável para Dynamic IP lease é de 10.20.0.10 a 10.20.0.30, com a máscara de sub-rede 255.255.255.0. O gateway 10.20.0.1 e os endereços fixos da infraestrutura ficam fora do pool.

Escolher o pool em função do número de clientes e dos endereços já reservados.

Utilizar Use device’s DNS settings apenas se os servidores DNS aí configurados forem acessíveis a partir da filial.

Para este servidor interno do firewall, os seletores policy-based na localização central utilizam o endereço da interface do servidor e a rede de clientes; na filial, aplica-se a associação inversa.

⚠️ Verificar a versão antes de uma alteração global: O procedimento de ativação seguinte aplica-se apenas ao cenário documentado do SFOS 22. As páginas de ajuda disponíveis do SFOS 23 são contraditórias: HO firewall as DHCP server and BO firewall as relay agent descreve os leases DHCP através de IPsec como ativados por predefinição e sem configuração adicional; a visão geral DHCP continua a indicar a ativação através da CLI. O conflito continua por resolver. Não confirma o estado real após uma atualização nem demonstra que o comando tenha sido removido. No SFOS 23, não ativar rotineiramente a definição global: registar o build exato e o estado atual e confirmar primeiro com o Sophos Support se é necessária uma alteração. Se o estado não for claro ou o comando de estado não estiver disponível, parar antes de efetuar alterações.

Registar o build exato do SFOS e, antes de qualquer alteração, apresentar e guardar o estado atual na Device Console do firewall central que atribui os leases:

system dhcp lease-over-IPSec show

⚠️ A definição seguinte afeta globalmente os leases DHCP através de IPsec. Ativá-la apenas no firewall que atribui os leases. Registe o estado inicial apresentado para que o rollback não desative uma configuração preexistente.

Apenas no SFOS 22, se o estado registado for desativado, ativar e depois verificar com o comando show anterior. Se já estiver ativado, não efetuar alterações:

system dhcp lease-over-IPSec enable

Só se a função estava desativada no firewall central que atribui os leases e foi efetivamente ativada durante o procedimento autorizado, o rollback é:

system dhcp lease-over-IPSec disable

Se já estava ativada, deixe-a ativada. Em ambos os casos, system dhcp lease-over-IPSec show confirma o estado restaurado.

Testar o funcionamento e resolver problemas

Um agente relay guardado não comprova que a configuração funciona. Renovar o lease num cliente de teste e definir em Diagnostics > Packet capture > Configure, no campo Enter BPF string, um filtro restrito:

port 67 or port 68

No fluxo de pacotes, devem ser visíveis, por esta ordem:

1. O pedido do cliente.
2. O pedido encaminhado.
3. O Offer do servidor.
4. O caminho de retorno.

As colunas In interface, Out interface, Source IP, Destination IP, Ports [src, dst] e Status mostram em que ponto a comunicação termina.

Os pacotes relay podem aparecer como Generated ou Forwarded. Em caso de Violation, Reason fornece a indicação seguinte para a verificação.

A utilização e os campos são explicados em Packet Capture no WebAdmin do Sophos Firewall.

Um Offer, por si só, não basta: o cliente deve pedir o endereço e receber um ACK.

Em seguida:

1. Verificar no cliente o endereço IP do pool previsto, a máscara de sub-rede, o gateway e o DNS.
2. Confirmar o registo do lease no servidor que o atribuiu.

Uma resposta a ping do servidor não comprova a acessibilidade por UDP nem uma comunicação DHCP bem-sucedida.

Estas verificações devem ser efetuadas pelo administrador.

Os erros típicos podem ser isolados da seguinte forma:

• Não é visível nenhum pedido do cliente: verificar a VLAN, a porta do switch, a interface dos clientes ou o cliente DHCP local.
• O pedido chega ao firewall, mas não é encaminhado: verificar a interface relay, o IP do servidor, a rota e, com IPsec policy-based, Relay through IPsec.
• O servidor recebe o pedido, mas não responde: verificar o scope da sub-rede do relay, a autorização do servidor e o firewall local do servidor.
• O Offer chega à localização central, mas não ao cliente: verificar a rota de retorno, as regras do firewall central, as sub-redes IPsec e a entrada NAT.
• O cliente recebe uma configuração incorreta: identificar o servidor que responde primeiro e comparar os scopes e as opções DHCP em todos os destinos relay.
• Policy rule denied com Source 0.0.0.0: um cliente sem endereço começa por utilizar este endereço de origem. Verificar se existe um servidor DHCP ou um relay responsável na interface correta dos clientes; não criar uma regra Allow genérica para 0.0.0.0 ou Any para ocultar o sintoma. A visão geral descreve o Drop quando não existe um servidor; num cenário relay, verificar o percurso real dos pacotes, em vez de concluir que existe um bloqueio geral do relay.

Reverter a configuração

Para um rollback planeado, confirme primeiro que os clientes conseguem alcançar outro servidor DHCP. Depois, elimine o agente relay em Network > DHCP > Relay. Remova rotas, objetos host e regras dedicados apenas quando Packet Capture deixar de mostrar pedidos relay; mantenha objetos partilhados com outro tráfego VPN. Com IPsec policy-based, eliminar também apenas a entrada sys-traffic-nat criada por este procedimento. Restaurar lease-over-IPSec apenas no firewall central que atribui os leases e só se o estado tiver sido efetivamente alterado durante o procedimento autorizado; repor o estado registado previamente. Isto não faz parte do rollback de um relay para um servidor DHCP externo nem de um estado que tenha permanecido inalterado.

Perguntas frequentes