Problema Direccionamiento DIBA
Publicado: 22 Ene 2017, 15:30
Buenas tardes.
Estoy configurando un Fortigate 100D para conectar a un DIBA de telefónica.
El DIBA tiene 8 IPs públicas. El fortigate está conectado en la parte de la WAN al router del DIBA. El router tiene la IP 192.168.0.1 y el Fortigate tiene la IP 192.168.0.2 y como puerta de enlace la 192.168.0.1.
Las 8 Ips públicas las tengo configuradas cada una como un IP Pool, y desde las reglas defino que tráfico sale por una IP o por otra. Hasta ahí no tengo problema.
El problema viene con el tráfico generado por el propio fortigate, como por ejemplo el servidor DNS, o las conexiones al fortiguard. Estas salen desde la IP del fortigate, y no veo manera de indicar que salgan por una de las IPs públicas. El router del DIBA no lo saca a internet si no viene de una de las IPs públicas...
Por lo que vi por internet, se me ocurrió cambiar la ip de origen de los servicios, poniendo como IP de origen la de la DMZ o la de la LAN, pero el fortigate no lo saca con la IP pública de la regla para el tráfico de la DMZ a la WAN o de la LAN a la WAN.
He conseguido que medio funcione poniendo en la WAN como segunda IP una de las IPs públicas, y poniendo esa IP como ip de origen para el DNS, el NTP y el fortiguard, pero, aunque el DNS funciona, el fortiguard, por ejemplo, no lo hace.
El problema de configurarlo así, aunque funcionara, es que tengo una segunda wan de backup, y, en caso de que se cayera el DIBA, los servicios que tienen el source-ip cambiado no funcionarían.
Lo ideal para mi sería poder definir reglas en el tráfico del HOST hacia las demás redes, de esa manera podría indicar por qué IP quiero que salga en cada caso, que es como lo hacía en el PFSense que tenía en el lugar del Fortigate hasta ahora...
La otra opción que se me ocurre, pero que no he podido probar porque si la pruebo y no funciona pierdo la conexión con la oficina y tendría que ir allí a arreglarlo, es poner como IP en la WAN una de las IP's públicas, y como segunda IP en esa interfaz la 192.168.0.2, manteniendo la puerta de enlace en 192.168.0.1.
Un saludo,
Julio
Estoy configurando un Fortigate 100D para conectar a un DIBA de telefónica.
El DIBA tiene 8 IPs públicas. El fortigate está conectado en la parte de la WAN al router del DIBA. El router tiene la IP 192.168.0.1 y el Fortigate tiene la IP 192.168.0.2 y como puerta de enlace la 192.168.0.1.
Las 8 Ips públicas las tengo configuradas cada una como un IP Pool, y desde las reglas defino que tráfico sale por una IP o por otra. Hasta ahí no tengo problema.
El problema viene con el tráfico generado por el propio fortigate, como por ejemplo el servidor DNS, o las conexiones al fortiguard. Estas salen desde la IP del fortigate, y no veo manera de indicar que salgan por una de las IPs públicas. El router del DIBA no lo saca a internet si no viene de una de las IPs públicas...
Por lo que vi por internet, se me ocurrió cambiar la ip de origen de los servicios, poniendo como IP de origen la de la DMZ o la de la LAN, pero el fortigate no lo saca con la IP pública de la regla para el tráfico de la DMZ a la WAN o de la LAN a la WAN.
He conseguido que medio funcione poniendo en la WAN como segunda IP una de las IPs públicas, y poniendo esa IP como ip de origen para el DNS, el NTP y el fortiguard, pero, aunque el DNS funciona, el fortiguard, por ejemplo, no lo hace.
El problema de configurarlo así, aunque funcionara, es que tengo una segunda wan de backup, y, en caso de que se cayera el DIBA, los servicios que tienen el source-ip cambiado no funcionarían.
Lo ideal para mi sería poder definir reglas en el tráfico del HOST hacia las demás redes, de esa manera podría indicar por qué IP quiero que salga en cada caso, que es como lo hacía en el PFSense que tenía en el lugar del Fortigate hasta ahora...
La otra opción que se me ocurre, pero que no he podido probar porque si la pruebo y no funciona pierdo la conexión con la oficina y tendría que ir allí a arreglarlo, es poner como IP en la WAN una de las IP's públicas, y como segunda IP en esa interfaz la 192.168.0.2, manteniendo la puerta de enlace en 192.168.0.1.
Un saludo,
Julio