pfsense peer-to-peer OpenVPN não conectando

4

Estou tentando configurar um OpenVPN ponto a ponto entre dois servidores pfsense executando o 2.0.1-RELEASE, mas o cliente continua recebendo a conexão, com um status de "reconectando; ping-restart" e nada aparece para ser roteamento entre eles. Esses dois firewalls também estão executando VPNs PPTP que estão funcionando corretamente.

FW01 ("server")
=======================
LAN: 10.1.1.2/24
WAN: xx.xx.126.34/27
ServerMode: Peer to Peer (Shared Key)
Protocol: UDP
DeviceMode: tun
Interface: WAN
Port 1194
Tunnel: 10.0.8.1/30
Local Network: 10.1.1.0/24
Remote Network: 192.168.1.0/24
Firewall Rule in OpenVPN tab: UDP   *   *   *   *   *   none      

FW03 (client)
LAN: 192.168.1.2/24
WAN: xx.xx.9.66/27
ServerMode: Peer to Peer (Shared Key)
Protocol: UDP
DeviceMode: tun
Interface: WAN
Server Host: xx.xx.126.34
Tunnel:  -- also tried 10.1.8.0/24
Remote Network: 10.1.1.0/24

Registros do cliente:

System Log
Apr 6 18:00:08  kernel:  ... Restarting packages.
Apr 6 18:00:13  check_reload_status: Starting packages
Apr 6 18:00:19  php: : Restarting/Starting all packages.
Apr 6 18:00:56  kernel: ovpnc1: link state changed to DOWN
Apr 6 18:00:56  check_reload_status: Reloading filter
Apr 6 18:00:57  check_reload_status: Reloading filter
Apr 6 18:00:57  kernel: ovpnc1: link state changed to UP
Apr 6 18:00:57  check_reload_status: rc.newwanip starting ovpnc1
Apr 6 18:00:57  check_reload_status: Syncing firewall
Apr 6 18:01:02  php: : rc.newwanip: Informational is starting ovpnc1.
Apr 6 18:01:02  php: : rc.newwanip: on (IP address: ) (interface: ) (real interface: ovpnc1).
Apr 6 18:01:02  php: : rc.newwanip: Failed to update IP, restarting...
Apr 6 18:01:02  php: : send_event: sent interface reconfigure got ERROR: incomplete command. all  reload  reconfigure  restart  newip  linkup  sync 
Client OpenVPN log
Apr 6 18:39:14  openvpn[12177]: Inactivity timeout (--ping-restart), restarting
Apr 6 18:39:14  openvpn[12177]: SIGUSR1[soft,ping-restart] received, process restarting
Apr 6 18:39:16  openvpn[12177]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 6 18:39:16  openvpn[12177]: Re-using pre-shared static key
Apr 6 18:39:16  openvpn[12177]: Preserving previous TUN/TAP instance: ovpnc1
Apr 6 18:39:16  openvpn[12177]: UDPv4 link local (bound): [AF_INET]64.94.9.66
Apr 6 18:39:16  openvpn[12177]: UDPv4 link remote: [AF_INET]64.74.126.34:1194
Server OpenVPN log
Apr 6 14:40:36  openvpn[22117]: UDPv4 link remote: [undef]
Apr 6 14:40:36  openvpn[22117]: UDPv4 link local (bound): [AF_INET]xx.xx.126.34:1194
Apr 6 14:40:36  openvpn[21006]: /usr/local/sbin/ovpn-linkup ovpns1 1500 1557 10.1.8.1 10.1.8.2 init
Apr 6 14:40:36  openvpn[21006]: /sbin/ifconfig ovpns1 10.1.8.1 10.1.8.2 mtu 1500 netmask 255.255.255.255 up
Apr 6 14:40:36  openvpn[21006]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Apr 6 14:40:36  openvpn[21006]: TUN/TAP device /dev/tun1 opened
Apr 6 14:40:36  openvpn[21006]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file
Apr 6 14:40:36  openvpn[21006]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Apr 6 14:40:36  openvpn[21006]: OpenVPN 2.2.0 amd64-portbld-freebsd8.1 [SSL] [LZO2] [eurephia] [MH] [PF_INET6] [IPv6 payload 20110424-2 (2.2RC2)] built on Aug 11 2011
Apr 6 14:40:36  openvpn[17171]: SIGTERM[hard,] received, process exiting
Apr 6 14:40:36  openvpn[17171]: /usr/local/sbin/ovpn-linkdown ovpns1 1500 1557 10.1.8.1 10.1.8.2 init
Apr 6 14:40:36  openvpn[17171]: ERROR: FreeBSD route delete command failed: external program exited with error status: 1
Apr 6 14:40:36  openvpn[17171]: event_wait : Interrupted system call (code=4)
Apr 6 14:06:32  openvpn[17171]: Initialization Sequence Completed
Apr 6 14:06:32  openvpn[17171]: UDPv4 link remote: [undef]
Apr 6 14:06:32  openvpn[17171]: UDPv4 link local (bound): [AF_INET]xx.xx.126.34:1194
    
por John P 06.04.2012 / 21:01

1 resposta

5

O mais provável é que o cliente não possa se comunicar com o servidor no UDP 1194. Por que, há várias possibilidades a serem verificadas, duas mais comuns:

  • nenhuma regra de firewall que permite o tráfego
  • 1: 1 NAT ou porta encaminhando esse tráfego para outro lugar
por 07.04.2012 / 00:18