Symptom
Wenn die Service Routen für DNS und NTP auf verschiedenen Schnittstellen festgelegt werden, funktioniert die NTP-Service-Route nicht, wenn NTP und DNS-Server der gleiche Host wie der sekundäre DNS/NTP-Server im folgenden Beispiel ist;
Sehen Sie zum Beispiel das folgende Beispiel Diagramm und die Konfiguration:
PRI NTP SRV-+
.20 | +----------+
| (Trust Zone) | | (Untrust Zone)
+-+ [Router] +-+---------+ (E1/2) + PA-2020 + (E1/1) +------------+ PRI DNS SRV
| .1.2 | |.. 20
| (172.16.100.0/24) +----------+ (192.168.100.0/24)
|
|
+----SEC DNS/NTP SRV
.20
(172.16.200.0/24)
Service Routen:
Für DNS, Quelladresse gesetzt als "192.168.100.2/24 (eth1/1, Untrust)"
Für NTP, Quelladresse gesetzt als "172.16.100.2/24 (eth1/2, Trust)"
Primäre DNS: 192.168.100.20 (Untrust Zone Seite)
Primäre NTP: 172.16.100.20 (Trust Zone Seite)
Sekundäre DNS/NTP: 172.16.200.20 (Trust Zone Side)-der gleiche Host wird für NTP und DNS-Dienst verwendet
Service Route Einstellung:
<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>
Wie oben gezeigt, ist die Palo Alto Networks Firewall so konfiguriert, dass eth1/1 (Untrust) für DNS und eth1/2 (Trust) für NTP-Zugriff verwendet wird. AllerDings benutzte die Firewall eth1/1 (Untrust) für NTP-Traffic in Richtung 172.16.200.20, und das Paket könnte fallen gelassen werden, da es keine Sicherheitsrichtlinien gibt, die es NTP-Traffic erlauben, aus der Untrust-Zone zu beziehen.
> Show NTP
NTP-Status:
NTP synchronisiert zu lokalen
NTP-Server 172.16.200.020 Connected: </ Not connected> false
NTP-Server 172.16.100.20 verbunden: true
Ursache
Unter aktueller Architektur initiiert die Palo Alto Networks Firewall NTP-Transaktionen von der gleichen Schnittstelle wie die DNS-Service-Route, wenn NTP und DNS-Server der gleiche Host sind.
Besitzer: Kkondo