VPN Ipsec entre OpenBSD e Juniper Netscreen
Há alguns dias precisei configurar uma VPN Ipsec entre um Juniper Netscreen e um OpenBSD. Como o protocolo é Ipsec, o OpenBSD tem tudo nativo :). Nele você pode configurar uma VPN Ipsec utilizando 2 caminhos:
- ipsec: A configuração é definida em um único arquivo (/etc/ipsec.conf). Configuração bastante simples. - isakmpd: Além do arquivo de configuração (/etc/isakmpd/isakmpd.conf), você precisa configurar o arquivo de policy (/etc/isakmpd/isakmpd.policy). Configuração um pouco complexa de entender no inicio.
Não vou entrar em detalhes sobre o ipsec e isakmpd, caso precise leia a documentação do mesmo, nada como um man arquivo não resolva, ou então clique nos respectivos links :).
Deixando a teoria de lado, vamos a pratica. As informações do Netscreen são praticamente iguais as utilizadas nas VPNs Cisco e no CheckPoint. Então esta documentação serve para os 3 produtos. O que pode mudar é o group, hash, encryption algorithm e é claro, a shared-key:
IP Netscreen: 201.56.120.125 Lan Netscreen: 192.168.1.0/24 Shared Key: fGrkApZlrNf@uR0@zlr#!4ka Fase 1: Hashing Algorithm: MD5 Diffie-Hellman Group: Group-2 Transform (IPSec Protocol): ESP Perfect Forward Secrecy: PFS Encryption Algorithm: 3DES Fase 2: Diffie-Hellman Group: Group-0 Encryption Algorithm: 3DES Hashing Algorithm: MD5 Perfect Forward Secrecy: noPfs
No meu servidor OpenBSD tenho os seguintes IPs:
IP OpenBSD: 187.10.223.67 Lan OpenBSD: 10.10.1.0/24
Consultando a documentação do ipsec.conf (man ipsec.conf), listei as opções que recebi do Netscreen e criei uma lista compatível que será usada no arquivo /etc/ipsec.conf:
Fase 1 = main mode Hashing Algorithm: hmac-md5 Diffie-Hellman Group: modp1024 Transform (IPSec Protocol): esp Encryption Algorithm: 3des Fase 2 = quick mode Diffie-Hellman Group: none Encryption Algorithm: 3des Hashing Algorithm: hmac-md5
Baseado nas informações anteriores, gerei o esqueleto da configuração para um melhor entendimento:
ike [Transform (IPSec Protocol)] from src to dst \ main auth [Hashing Algorithm] enc [Encryption Algorithm] group [Diffie-Hellman Group] \ quick auth [Hashing Algorithm] enc [Encryption Algorithm] group [Diffie-Hellman Group] \ psk [shared-key]
Depois de entender a lógica da configuração, vamos criar o arquivo final. Renomeie o /etc/ipsec.conf para /etc/ipsec.conf.default:
mv /etc/ipsec.conf /etc/ipsec.conf.default
Crie o /etc/ipsec.conf com o seguinte conteúdo:
# /etc/ipsec.conf # ext_if = "fxp0" openbsd_lan = "10.10.1.0/24" netscreen_lan = "192.168.1.0/24" netscreen_gw = "201.56.120.125" ike esp from $openbsd_lan to $netscreen_lan peer $netscreen_gw \ main auth hmac-md5 enc 3des group modp1024 \ quick auth hmac-md5 enc 3des group none \ psk "fGrkApZlrNf@uR0@zlr#!4ka"
Antes de iniciar a VPN, é preciso criar o arquivo de policy do isakmpd. Este procedimento torna-se necessário para o isakmpd não ficar gerando log dizendo que o arquivo de policy não foi encontrado:
touch /etc/isakmpd/isakmpd.policy
Repara que o arquivo acima foi criado sem nenhum conteúdo.
Adicione a variável netscreen_gw = “201.56.120.125” no seu /etc/pf.conf, depois adicione as linhas abaixo para permitir o tráfego entre o OpenBSD e o GW Netscreen:
pass in on $ext_if proto udp from $netscreen_gw to $ext_if port { 500, 4500 } pass out on $ext_if proto udp from $ext_if to $netscreen_gw port { 500, 4500 } pass in on $ext_if proto esp from $netscreen_gw to $ext_if pass out on $ext_if proto esp from $ext_if to $netscreen_gw
Dê um reload nas suas regras e start a VPN:
pfctl -f /etc/pf.conf isakmpd -K ipsecctl -f /etc/ipsec.conf
Caso não tenha recebido nenhuma mensagem de erro, verifique se o túnel subiu:
netstat -nr
Nas últimas linhas você verá as seguintes informações:
Encap: Source Port Destination Port Proto SA(Address/Proto/Type/Direction) 192.168.1.0/24 0 10.10.1.0/24 0 0 201.56.120.125/esp/use/in 10.10.1.0/24 0 192.168.1.0/24 0 0 201.56.120.125/esp/require/out
Utilizamos o ipsecctl para verificar as regras de policy do ipsec:
FLOWS: flow esp in from 192.168.1.0/24 to 10.10.1.0/24 peer 201.56.120.125 srcid 187.10.223.67/32 dstid 201.56.120.125/32 type use flow esp out from 10.10.1.0/24 to 192.168.1.0/24 peer 201.56.120.125 srcid 187.10.223.67/32 dstid 201.56.120.125/32 type require SAD: esp tunnel from 187.10.223.67 to 201.56.120.125 spi 0x097a93d3 auth hmac-md5 enc 3des-cbc esp tunnel from 201.56.120.125 to 187.10.223.67 spi 0x6f5c0fef auth hmac-md5 enc 3des-cbc
Adicione as seguintes linhas no /etc/rc.conf.local para que a VPN suba se o servidor reiniciar:
isakmpd_flags="-K" # enabled isamkpd ipsec=YES # enabled ipsec
Para visualizar o tráfego utilize o tcpdump na interface externa filtrando tudo que entra e sai para o IP do Netscreen:
tcpdump -i fxp0 -netttvvv src or dst 201.56.120.125
Chegamos ao final, VPN pronta, tunel no ar e clientes felizes :).
Prezado,
teria como nos ajudar?
Nossa realidade é a seguinte:
O nosso cliente possui o aparelho Juniper e provê as informações eles seriam o sever e eu seria o client. Para não precisar comprar um Juniper para fazer o VPN achamos seu artigo.
Instalamos um VMWare e nele colocamos o OpenBSD fiz tudo o que seu artigo fala…
pfctl -f /etc/pf.conf
isakmpd -K
ipsecctl -f /etc/ipsec.conf
Não deu nenhuma mensagem de erro
Após o comando “netstat -nr”
o resultado deu completamente diferente do seu… mas nao soube identificar a saída desse comando teria como vc nos ajudar???
olha a saída que deu
Routing tables
Internet:
Destination Gateway Flags Refs Use Mtu Prio Iface
default 192.168.2.100 UGS 2 22 – 8 vic0
127/8 127.0.0.1 UGRS 0 0 33200 8 lo0
127.0.0.1 127.0.0.1 UH 2 0 33200 4 lo0
192.168.2.0/25 link#1 UC 2 0 – 4 vic0
192.168.2.1 a4:ba:db:05:2f:d3 UHLc 2 332 – 4 vic0
192.168.2.9 127.0.0.1 UGHS 0 0 33200 8 lo0
192.168.2.100 00:23:69:15:6b:74 UHLc 1 0 – 4 vic0
224/4 127.0.0.1 URS 0 0 33200 8 lo0
Internet6:
Destination Gateway Flags Refs Use Mtu Prio Iface
::/104 ::1 UGRS 0 0 – 8 lo0
::/96 ::1 UGRS 0 0 – 8 lo0
::1 ::1 UH 14 0 33200 4 lo0
::127.0.0.0/104 ::1 UGRS 0 0 – 8 lo0
::224.0.0.0/100 ::1 UGRS 0 0 – 8 lo0
::255.0.0.0/104 ::1 UGRS 0 0 – 8 lo0
::ffff:0.0.0.0/96 ::1 UGRS 0 0 – 8 lo0
2002::/24 ::1 UGRS 0 0 – 8 lo0
2002:7f00::/24 ::1 UGRS 0 0 – 8 lo0
2002:e000::/20 ::1 UGRS 0 0 – 8 lo0
2002:ff00::/24 ::1 UGRS 0 0 – 8 lo0
fe80::/10 ::1 UGRS 0 0 – 8 lo0
fe80::%vic0/64 link#1 UC 0 0 – 4 vic0
fe80::20c:29ff:fef7:66d8%vic0 00:0c:29:f7:66:d8 UHL 0 0 – 4 lo0
fe80::%lo0/64 fe80::1%lo0 U 0 0 – 4 lo0
fe80::1%lo0 link#4 UHL 0 0 – 4 lo0
fec0::/10 ::1 UGRS 0 0 – 8 lo0
ff01::/16 ::1 UGRS 0 0 – 8 lo0
ff01::%vic0/32 link#1 UC 0 0 – 4 vic0
ff01::%lo0/32 ::1 UC 0 0 – 4 lo0
ff02::/16 ::1 UGRS 0 0 – 8 lo0
ff02::%vic0/32 link#1 UC 0 0 – 4 vic0
ff02::%lo0/32 ::1 UC 0 0 – 4 lo0
Grato, Alexandre
Alexandre
6 Jul 10 at edit_comment_link(__('Edit', 'sandbox'), ' ', ''); ?>
Se não mostrou igual no meu post, creio que o tunnel não foi estabelecido, ou seja, o juniper não está aceitando a comunicação. Aqui vai algumas perguntas:
1 – O a porta do ipsec está liberada no seu juniper aceitar conexão do seu OpenBSD? -netttvvv src or dst e verifica se o pacote volta. Tenta fazer a mesma coisa no firewall do juniper.
2- Roda um tcpdump -i
but3k4
15 Jul 10 at edit_comment_link(__('Edit', 'sandbox'), ' ', ''); ?>