Alta disponibilidad tunel IPsec
-
Hola.
Yo implemetaria un script, ya sea en bash o en php-cli con un algoritmo similar a
Sí ping No Ok a destinoX vía tunel1 entonces túnel1 down y túnel 2 up
Sí ping No Ok a destinoY vía tunel2 entonces tunel2 down y túnel 1 upY definiría un Cron para el script a ejecutarse cada x intervalo
Salu2
-
Hola
Aunque si no te gusta liarte con scripting, probaría a tener los dos túneles up y usar fail over (load balancing no creo que funcione con túneles IPSEC ), creando un gateway para cada túnel en system > routing, y luego un gateway groups, y definiendo el disparador del evento trigger level como member down, dando prioridad tier1 al gw del túnel mpls y tier5 al de la wan
Salu2
– añadido ---
Aunque parece que no es tan sencillo lo de fail over con IPSEC
https://forum.pfsense.org/index.php?topic=111294.msg621622#msg621622
-
Hola
Un script para comprobar si IPSEC no presenta conexiones de tuneles (none) y si es así relanzar IPSEC
#!/bin/bash ######################### # MonitorIPSEC.sh # Crear cron con # /bin/sh /scripts/MonitorIPSEC.sh ######################### ISDOWN=$(/usr/local/sbin/ipsec status | grep -c none) if [ $ISDOWN -eq 1 ]; then # reiniciamos ipsec /usr/local/sbin/pfSsh.php playback svc stop ipsec /usr/local/sbin/pfSsh.php playback svc start ipsec fiNo lo he probado, pero puedes investiga el comando:
/usr/local/sbin/ipsec/usr/local/sbin/ipsec –help
ipsec command [arguments]Commands:
start|restart [arguments]
update|reload|stop
up|down|route|unroute <connectionname>down-srcip <start>[<end>]
status|statusall [<connectionname>]
listalgs|listpubkeys|listcerts [–utc]
listcacerts|listaacerts|listocspcerts [–utc]
listacerts|listgroups|listcainfos [–utc]
listcrls|listocsp|listplugins|listall [–utc]
listcounters|resetcounters [name]
leases [ <poolname>[<address>]]
rereadsecrets|rereadcacerts|rereadaacerts
rereadocspcerts|rereadacerts|rereadcrls|rereadall
purgecerts|purgecrls|purgeike|purgeocsp
scepclient|pki
starter|stroke
version
</address></poolname></connectionname></end></start></connectionname>Para implementar script.
Salu2
-
No creo que un scrip sea una buena solución, he notado que cuando el servicio php-fms.. creo que se llama así toda la configuración web deja de funcionar y sólo quedaba funcionado los servicios que están cargados en la ram, pfsnede depende totalmente de php y ngix y si algo le pasa a ellos la soluciones es ir a la consola a reiniciarlo, esos errores son poco habituales pero afectan bastante,
He tenido problemas en los que estas en alta disponibilidad configurados con carp y pfsyns, pero los que está en modo stonealone no he visto este comportamiento
Sugiero humildemente quitar una vpn q viaja en un mpls y enrutaarla atravez de rutas estéticas y que en las reglas de cada fw se configures gateway con prioridad para que sea una confirmación más transparente
-
Hola
No he entendido muy bién que no es confiable un script en pfSense.
pfSense se basa en scripting en php, sh y bash. Y una webGUI… y por debajo corriendo la potencia de FreeBSD y pf e ipfw...
Por ejemplo, el menú que te aparece en consola es /etc/rc.initial
Y para reiniciar el webconfigurartor y php-fm vía shell o scripting las ordenes o invocaciones a los cripts que lo hacen son:
/etc/rc.restart_webgui
/etc/rc.php-fpm_restartRespecto a lo de los túneles IPSEC, controlarlos vía scripting, se puede hacer, otra cosa es hacer un script óptimo y crear su cron y que funcione… :)
A mi personalomente en scripting me basta con que funcione, jaja. De todas formas solo daba ideas, no me he puesto a "currarme" un monitor de IPSEC con varios túneles y según un tunel esté down levantar otro... imagino que hasta nos pagarian si nos lo encargasen ;)
Salu2
-
Hola
Por cierto, muy interesante la doc de pfSense sobre el tema IPSEC Multi-Wan:
IPSEC Multi-WAN Environments
When using Multi-WAN (Multiple WAN Connections), pick the appropriate Interface choice for the WAN-type in-
terface to which the tunnel will connect. If the connection will enter via WAN, pick WAN. If the tunnel will use a
different WAN, choose whichever OPT WAN interface is needed. A static route will automatically be added to ensure
that the traffic to the Remote Gateway routes through the appropriate WAN.
A gateway group may also be chosen from this list. A gateway group to be used with IPsec must only have one gateway
per tier. When using a gateway group, if the first gateway goes down, the tunnel will move to the next available WAN
in the group. When the first WAN comes back up, the tunnel will be rebuilt there again. If the far side router is one
that does not support multiple peer addresses, such as another pfSense unit, this must be combined with a DynDNS
host set using the same gateway group for failover. The DynDNS host will update the IP address as seen by the far
side, so that the remote router will know to accept traffic from the newly activated WAN.Salu2
-
Gracias por las respuestas!!
La realidad es que necesito encontrar la manera de poder monitorear los túneles ya sea IPSEC o OPENVPN.
Hoy en día cuando se cae un túnel debo cambiarlo hacer el cambio manualmente.
El problema es que no entiendo mucho de scripting como para hacerlo de esa manera.
Saludos
-
Hola
La solución ya te la da la doc de pfSense:
IPSEC Multi-WAN Environments
When using Multi-WAN (Multiple WAN Connections), pick the appropriate Interface choice for the WAN-type in-
terface to which the tunnel will connect. If the connection will enter via WAN, pick WAN. If the tunnel will use a
different WAN, choose whichever OPT WAN interface is needed. A static route will automatically be added to ensure
that the traffic to the Remote Gateway routes through the appropriate WAN.
A gateway group may also be chosen from this list. A gateway group to be used with IPsec must only have one gateway
per tier. When using a gateway group, if the first gateway goes down, the tunnel will move to the next available WAN
in the group. When the first WAN comes back up, the tunnel will be rebuilt there again. If the far side router is one
that does not support multiple peer addresses, such as another pfSense unit, this must be combined with a DynDNS
host set using the same gateway group for failover. The DynDNS host will update the IP address as seen by the far
side, so that the remote router will know to accept traffic from the newly activated WAN.Fail over.
Salu2
-
Claro esa solución seria ideal si yo tuviera los dos túneles configurados por interfaces WAN ya que en ese caso si no sale por una sale por la otra.
Pero no es mi escenario, yo tengo un túnel vía WAN to WAN y el otro vía MPLS to MPLS. no tengo forma de configurar un gateway group con la WAN y la MPLS
Saludos
-
Hola
Con túneles IPSEC wan/mpls failover no encuentro un caso práctico.
Pero sí con openVPN:
MPLS failover / same destination via different gateways
https://forum.pfsense.org/index.php?topic=110414.msg621276#msg621276
Y aquí parece que alguien sabe como, con IPSEC:
https://forum.pfsense.org/index.php?topic=73063.msg398501#msg398501
@marcelloc:Yes I do. Do you have experience with setting this up?
I've did some failover scripts to enable ipsec while mpls is offline and change gateway to link B while gateway A is offline.
Is something like that you need?
I can also assist you to configure instructions jimp post about it on the other thread of yours.
Salu2
-
Nunca hice esto con pfsense, pero lo mas logico seria ruteo dinamico, se que pfsense tiene los demonios de BGP y OSPF.
Dejas que las dos puntas del tunel manejen por donde van, si un tunel se cae, cambian los ruteos automatico.
-
Gracias por las respuestas pero la realidad es que no tengo tantos conocimientos como para configurar eso.
Alguno de ustedes puede darme una mano con este tema? Estamos dispuestos a pagar un soporte para solucionar esto de la manera que sea.
Saludos
-
