A grande atualização do FreeBSD quebrou a conectividade do vpnc, o tráfego de entrada do ESP não parece não criptografado nas interfaces

4

Atualizei uma caixa FreeBSD de 10.4 para 11.2-RELEASE-p4 recentemente e parece que ela quebrou a conectividade vpnc VPN.

Aqui está o vpnc.conf :

IPSec gateway 10.1.0.1
IPSec ID vpnuser
IPSec secret su0hoh8liNgeiT8
Xauth username vpnuser
Xauth password miuthei3Niew2ee
Nat Traversal Mode none
Noninteractive

Seguindo a configuração da interface; em0 é a interface de hardware com endereço IP privado, tun0 a interface do vpnc com um endereço público.

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
  inet 10.2.2.1 netmask 0xfffffe00 broadcast 10.2.3.255
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect (100baseTX <full-duplex>)
  status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
  options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
  inet6 ::1 prefixlen 128
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
  inet 127.0.0.1 netmask 0xff000000
  nd6 options=21
  groups: lo
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1412
  options=80000<LINKSTATE>
  inet x.11.11.60 --> x.11.11.60 netmask 0xffffffff
  nd6 options=29
  groups: tun
  Opened by PID 90343

Até agora eu descobri:

  • O vpnc aparentemente consegue conectar a VPN, rodando o vpnc com --no-detach não mostra nenhum erro crítico. Eu estou usando a mesma configuração de antes com a versão FreeBSD anterior, onde funcionou perfeitamente. Eu também tentei algumas versões do vpnc-scripts . Eu também testei com regras de firewall pf liberadas com pfctl -F all .

  • pings enviados da máquina local ( ping 8.8.8.8 ) aparecem em tcpdump -ni tun0 como tráfego de saída:

    00:58:24.017976 IP x.11.11.60 > 8.8.8.8: ICMP echo request, id 42593, seq 4, length 64
    
  • pings enviados da máquina local mostram em tcpdump -ni em0 ; O interessante é que o pacote de VPN parece receber uma resposta adequada a cada vez e a resposta atinge a interface de hardware da máquina local:

    00:58:24.018029 IP 10.2.2.1 > 10.1.0.1: ESP(spi=0x1bcc60be,seq=0x3c), length 132
    00:58:24.078558 IP 10.1.0.1 > 10.2.2.1: ESP(spi=0xe48f7620,seq=0x6b), length 132
    
  • no entanto, o pacote de retorno não aparece em tcpdump .

  • os pacotes de ping de um host externo (Internet) aleatório para x.11.11.60 induzem um tráfego similar que pode ser visto em em0 , mas não em tun0 :

    01:35:32.612015 IP 10.1.0.1 > 10.2.2.1: ESP(spi=0xe48f7620,seq=0x124), length 132
    

A alteração do valor sysctl de net.inet.ip.forwarding parece não ter qualquer efeito.

A VPN (tun0) deve ser a rota padrão do host. Com base na descoberta de que o exemplo de ping obtém uma resposta de volta até em0 , isso não parece ser um problema de roteamento.

Você consegue identificar algo que me falta? Alguma idéia de como eu poderia fazer a conexão VPN funcionar novamente?

UPDATE - Novas descobertas:

Agora parece provável que este não seja um problema vpnc específico. Em vez disso, pode haver algo com manipulação de ESP em FreeBSD 11 .

  • Eu encontrei uma solução para o problema que é simplesmente forçar o modo NAT traversal com --natt-mode force-natt , apesar de não haver nenhum NAT entre os hosts. Por alguma razão, não há problema com o UDP encapsulado:

O que mostra em em0 ...

14:15:18.500251 IP 10.2.2.1.4500 > 10.1.0.1.4500: UDP-encap: ESP(spi=0x66842bb7,seq=0x3), length 132
14:15:18.527137 IP 10.1.0.1.4500 > 10.2.2.1.4500: UDP-encap: ESP(spi=0x3a4661f0,seq=0x3), length 132

... pode ser visto sem criptografia agora também em tun0 :

14:15:18.500200 IP x.11.11.60 > 172.217.21.142: ICMP echo request, id 64016, seq 2, length 64
14:15:18.527188 IP 172.217.21.142 > x.11.11.60: ICMP echo reply, id 64016, seq 2, length 64
  • Eu configurei uma solução separada com racoon usando o manual do FreeBSD e ele mostrou comportamento semelhante quando se trata de aparentemente não manipular pacotes ESP recebidos. Por algum motivo, recebo agora o erro vpnc[3372]: esp sendto: Invalid argument quando tento executar o ping se vpnc foi iniciado com --natt-mode none .

  • Parece que houve algumas alterações no IPsec, ESP e NAT-T em FreeBSD 11.0R e 11.1R . Talvez essas mudanças interfiram em algo agora.

Qualquer ajuda ainda é apreciada.

    
por alo 11.11.2018 / 02:03

0 respostas