Síntoma
Al establecer rutas de servicio para DNS y NTP en diferentes interfaces, la ruta de servicio NTP no funciona cuando el servidor NTP y DNS es el mismo host como el servidor DNS/NTP secundario en el ejemplo siguiente;
Por ejemplo, consulte el siguiente diagrama de ejemplo y configuración:
PRI NTP SRV-+
.20 | +----------+
| (zona fiduciaria) | | (zona Untrust)
+-+ [Router] +-+---------+ (E1/2) + PA-2020 + (E1/1) +------------+ PRI DNS SRV
| .1.2 | | .2.20
| (172.16.100.0/24) +----------+ (192.168.100.0/24)
|
|
+----SEC DNS/NTP SRV
.20
(172.16.200.0/24)
Rutas de servicio:
Para DNS, la dirección de origen estableció como "192.168.100.2/24 (eth1/1, Untrust)"
Para NTP, la dirección de origen fijó como "172.16.100.2/24 (eth1/2, confianza)"
DNS primario: 192.168.100.20 (lado de zona no confiable)
NTP primario: 172.16.100.20 (lado de la zona de confianza)
DNS/NTP secundarios: 172.16.200.20 (lado de la zona fiduciaria)-el mismo host se utiliza para el servicio NTP y DNS
Configuración de la ruta de servicio:
<route></route>
<service></service>
<entry name="ntp"></entry>
<source-address>172.16.100.2/24</source-address>
<entry name="dns"></entry>
<source-address>192.168.100.2/24</source-address>
Como se muestra anteriormente, el cortafuegos de Palo Alto Networks está configurado para usar eth1/1 (Untrust) para DNS y eth1/2 (Trust) para el acceso a NTP. Sin embargo, el cortafuegos usó eth1/1 (no Trust) para el tráfico de NTP hacia 172.16.200.20, y el paquete podría ser descargado ya que no existe ninguna directiva de seguridad que permita el tráfico de NTP a origen desde la zona Untrust.
> Mostrar NTP
Estado NTP:
NTP sincronizar con LOCAL
Servidor NTP 172.16.200.020 conectado: false </ Not connected>
Servidor NTP 172.16.100.20 conectado: true
Causa
En la arquitectura actual, el cortafuegos de Palo Alto Networks inicia las transacciones de NTP desde la misma interfaz que la ruta de servicio DNS si el servidor NTP y DNS es el mismo host.
Propietario: kkondo