Durante a semana precisei estabelecer uma VPN site-to-site entre um firewall Linux (na matriz, onde trabalho) e outro firewall Sonicwall (em uma filial). Nas versões de kernel mais atuais, o suporte nativo ao IPSec é oferecido pelo conjunto de ferramentas ipsec-tools – portado do projeto KAME (implementação Unix  BSD). Para negociação automática de chaves é utilizado o serviço Racoon (IKE Daemon). Como parte da documentação, disponível na Internet, trata a integração com soluções alternativas (como Openswan / Strongswan), resolvi documentar o processo via Racoon.

Confiram um diagrama que exemplifica o tunelamento que abordaremos:

                    ========= ESP =========
                    |                     |
REDE-MATRIZ     FW-MATRIZ             FW-FILIAL         REDE-FILIAL
10.1.0.0/16 --- 200.200.100.1 ------- 200.200.200.2 --- 10.2.0.0/16

Em REDE-MATRIZ e REDE-FILIAL podemos identificar os segmentos internos da rede local (LAN). Mas, nada impede identificar blocos de rede.

“Neste exemplo, optamos por blocos ‘/16’ para sumarizar as diferentes redes previstas em cada local. Logicamente, estamos apenas definindo que endereços iniciados por ‘10.1.’ representam as diferentes redes da matriz  e ‘10.2.’ as redes da filial. “

Ao optar por este layout de rede (sumarizando rotas), na aba “Network” (em VPN) do Sonicwall, não utilize LAN Subnets na identificação de Local Networks. Ou seja, defina um novo “objeto de rede” que represente exatamente o segmento de rede que será configurado em ambos os firewalls.

O método de autenticação configurado será o “pre_shared_key“, com a chave definida como “vpns3nh@2002” (sem aspas).

 

– NA FILIAL a configuração da VPN foi realizada da seguinte maneira:

1. Configuração da aba “General” (IP da matriz e senha PSK – Shared Secret):

2. Configuração da aba “Proposals” (Main Mode em Exchange):

 

– NA MATRIZ a configuração foi definida da seguinte maneira:

1. Instalação e configuração do serviço Racoon:

– Instalação (o pacote ipsec-tools será instalado como dependência automática)

root@linux-server:~# apt-get install racoon

– Configuração

root@linux-server:~# vim /etc/racoon/racoon.conf

log notify;
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

#listen {
#        isakmp          200.200.100.1 [500];
#        isakmp_natt     200.200.100.1 [4500];
#}

remote 200.200.200.2 {
        exchange_mode main;
#        my_identifier          address 200.200.100.1;
#        peers_identifier       address 200.200.200.2;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                lifetime time 28800 seconds;
                dh_group 2;
        }
        generate_policy on;
}

sainfo address 10.1.0.0/16 any address 10.2.0.0/16 any {
#        pfs_group 2;
        lifetime time 28800 seconds;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

“Não configure a opção pfs_group caso a opção ‘Perfect Forward Secrecy‘ esteja  desabilitada no Sonicwall – perdi um belo tempo até perceber isto (risos). Mas, por questões de segurança, o ideal é habilitar a opção nos dois lados.“

“Para obter informações de depuração, modifique a opção log de notify para debug e acompanhe as atualizações de syslog (/var/log/syslog).“

2. Configuração da chave PSK

root@linux-server:~# vim /etc/racoon/psk.txt

200.200.200.2   vpns3nh@2002

“A chave PSK deve ser definida no arquivo identificado pela opção ‘path pre_shared_key‘ em racoon.conf. Certifique-se de ter configurado a mesma PSK em ambos os firewalls.“

3. Para autorizar o tunelamento, precisamos configurar as regras SPD (Security Policy Database):

root@linux-server:~# vim /etc/ipsec-tools.conf

#!/usr/sbin/setkey -f

## Flush the SAD and SPD
#
flush;
spdflush;

## Some sample SPDs for use racoon
#

spdadd 10.1.0.0/16 10.2.0.0/16 any -P out ipsec
        esp/tunnel/200.200.100.1-200.200.200.2/require;

spdadd 10.2.0.0/16 10.1.0.0/16 any -P in ipsec
        esp/tunnel/200.200.200.2-200.200.100.1/require;

“Fiquem atentos com a sequência das redes e gateways em cada linha. Na primeira, informe na sequência matriz para filial (-P out) e, na linha seguinte, inverta o sentido (-P in).“

4. Reiniciando os serviços:

root@linux-server:~# service setkey restart
root@linux-server:~# service racoon restart

5. Iniciando ou finalizando o túnel manualmente:

– Processo de conexão

root@linux-server:~# racoonctl vpn-connect 200.200.200.2

– Processo de desconexão

root@linux-server:~# racoonctl vpn-disconnect 200.200.200.2

Observações:

O encaminhamento será tratado automaticamente pelo kernel do Linux, sem precisar adicionar rotas manualmente. Neste cenário, não é preciso ativar o recurso proxy_arp porque não precisamos tratar tráfego em layer2.

Como a interface de saída é responsável pelo tráfego de Internet, deveremos garantir que os pacotes destinados a filial não serão submetidos as regras de NAT (SNAT ou MASQUERADE), por exemplo:

iptables -t nat -I POSTROUTING -d 10.2.0.0/16 -j RETURN

Outra fonte interessante sobre as opções do KAME:
http://www.kame.net/newsletter/20001119/

Confiram também um artigo para integração com Checkpoint:
https://viniciusbueno.com.br/vpn-ipsec-linux-racoon-checkpoint/