pfSense no Virtio: o TCP trava até o offload ser desligado

Um cliente relata que o túnel conecta, um ping responde, a página de login carrega e então a transferência congela no mesmo ponto em cada tentativa. Esse padrão já diz muito: a acessibilidade funciona e a taxa de transferência sustentada não. Antes de abrir o firewall, descubra se a VPN participa mesmo da falha. Faça passar TCP grande pelo mesmo gateway sem túnel no caminho; se também congelar, o OpenVPN nunca esteve envolvido.

Um convidado pfSense com placa de rede virtio tem ótima razão para falhar exatamente nesse formato.

Pacotes pequenos passam, TCP volumoso trava

Handshakes, respostas DNS e ecos ICMP são pequenos e normalmente passam. Transferências sustentadas forçam o convidado a segmentar, e é aí que um caminho de offload danificado aparece. A falha não precisa ser simétrica: o tráfego de saída pode estar limpo enquanto o de entrada se perde, ou o contrário, então um usuário pode entrar e depois travar na primeira resposta grande. Como o mesmo cliente funciona por outro gateway, a culpa recai no componente mais novo.

Então teste o gateway sem o túnel. Um download de LAN para WAN grande o suficiente para durar alguns segundos basta, e ele deve ser feito antes de qualquer mudança de configuração para que a comparação posterior signifique algo.

O que o offload realmente promete

virtio é paravirtual: host e convidado dividem o trabalho, o host anuncia capacidades de soma de verificação e segmentação e espera que o convidado termine o que começou. Se a pilha do convidado não faz isso, os quadros saem com somas de verificação incompletas ou são descartados pelo host. Uma E1000 emulada oferece um modelo mais simples e mais lento no qual o problema desaparece sem uma única mudança no pfSense. A negociação de capacidades ocorre por dispositivo, o que explica por que um convidado funciona por meses enquanto seu gêmeo reconstruído falha no primeiro dia.

O conjunto negociado depende da versão do hipervisor e do modelo de placa de rede escolhido, não apenas da configuração importada.

Uma caixa de seleção mantém o virtio

Na interface do pfSense, Sistema e depois Avançado e depois Rede contém uma caixa chamada Desativar o offload de soma de verificação por hardware. Ao marcá-la, o convidado calcula as somas de verificação em software, o que corresponde ao que a pilha FreeBSD atrás do pfSense espera de um dispositivo paravirtual. Duas opções relacionadas na mesma página cobrem o offload de segmentação TCP por hardware e o offload de recepção grande por hardware. Recorra a elas quando os handshakes funcionam mas as transferências volumosas não.

Deixe a placa de rede como virtio enquanto faz a mudança. Passar para E1000 queima CPU em cada pacote durante toda a vida da VM e esconde o problema de configuração de quem herdar o host, o que é uma troca pior do que um caminho de dados um pouco mais lento, mas previsível.

Meça o custo que você acabou de aceitar

O cálculo de somas de verificação em software move trabalho para o convidado, então meça a taxa de transferência depois em vez de supor que não custa nada. Numa VM pequena a penalidade é real, mas é visível e estável, ao contrário de uma perda silenciosa. Compare os contadores de erro da interface e o log do kernel do convidado antes e depois. Um hipervisor que filtra a ponte é uma falha separada com outras evidências, e nenhuma flag de offload a cura.

Mude uma coisa por teste e anote o caminho de menu, a caixa marcada e o número medido. Quem enfrentar o próximo convidado reconstruído vai querer as três.

Outros firewalls baseados em BSD oferecem um controle equivalente nas próprias configurações de interface, então o raciocínio viaja mesmo quando o caminho de menu não.