Ik probeer een NTPdaemon op een server thuis te laten draaien.
Ik kan prima alle pool.ntp.org enz. bereiken via ping en ntp enz..
Probeer ik de daemon te laten draaien..dan krijg -init bij mn update!
Ik zie ook geen terugkomend verkeer op mn firewall...
Blokkeert Ziggo mijn return NTP traffic>
Dit topic is gesloten. Staat je antwoord hier niet bij, stel dan je vraag in een nieuw topic.
Page 1 / 2
Ik heb via WIFI en mijn mobiele KPN telefoon de daemon laten draaien...en dan werkt het gelijk!!
dit moet bij ZIGGO zitten!!!
dit moet bij ZIGGO zitten!!!
Vreemde situatie, Lars! Wij blokkeren dit verkeer niet. Maar hier zal ik wel even verder in moeten duiken!
Ik kom hier later op terug, oké?
Ik kom hier later op terug, oké?
Beste LarsvZ,
Check even de firewall tab van de EPC3928, aan de rechterkant, uit mijn hoofd staat wat er toegestaan wordt en wat niet op welke niveaus.
MVG
Check even de firewall tab van de EPC3928, aan de rechterkant, uit mijn hoofd staat wat er toegestaan wordt en wat niet op welke niveaus.
MVG
Ik heb mn eigen vaste ip adres op mn firewall zitten.Ziggo router staat op bridge modus...denk niet dat er op die doos iets gefiltert gaat worden!
Beste LarsvZ,
Klopt.
Dan zult u even response moeten afwachten van Jesse, aangezien de firewall niks zien neem ik ook aan dat hij niks blokkeerd.
MVG
Klopt.
Dan zult u even response moeten afwachten van Jesse, aangezien de firewall niks zien neem ik ook aan dat hij niks blokkeerd.
MVG
Zojuist heb ik een ntp daemon succesvol kunnen laten syncen met pool.ntp.org. Hiervoor heb ik wel UDP poort 123 moeten forwarden naar de PC waar ik de ntpd op draai. Dit heb ik getest in voormalig UPC gebied op een Ziggo Mediabox XL als modem.
Misschien kan je wat meer vertellen over de situatie? Hoe zien de firewall rules er precies uit?
En je geeft aan dat het via Wi-Fi wel goed gaat. Via wat voor internet verbinding loopt die Wi-Fi verbinding dan? Is dat ook over dezelfde router?
Met wat meer informatie denken we hier graag verder met je mee. 🙂
Misschien kan je wat meer vertellen over de situatie? Hoe zien de firewall rules er precies uit?
En je geeft aan dat het via Wi-Fi wel goed gaat. Via wat voor internet verbinding loopt die Wi-Fi verbinding dan? Is dat ook over dezelfde router?
Met wat meer informatie denken we hier graag verder met je mee. 🙂
Heb NTP in pfSense in gebruik werkt prima met pool.ntp.org en ik heb nog mijn oude NTP in een oud Debian systeem lopen ook met pool.ntp.org waar ook nog mijn oude DNS server op loopt die gaat binnenkort vervangen worden maar op die werkt NTP ook nog steeds gewoon.
Uiteraard niet bereikbaar vanaf Internet.
NTP in pfSense vervangt de NTP die ik nog in een lokaal Debian vps heb lopen. In dit Debian system loopt ook mijn lokale caching en authoritative DNS (voor mijn lokale domein) daar had ik ook ooit de NTP op ondergebracht. Dit oude Debian systeem word binnenkort vervangen en dan vervalt die NTP in Debian daar komt een authoritative only dns voor in de plaats in een nieuw Debian Jessie vps systeem. Unbound in pfSense vervangt al de caching dns server. Dit is allemaal lokaal. Aan de buitenkant heb ik ddns bij een dns registrar/dns provider.
NTP in pfSense vervangt de NTP die ik nog in een lokaal Debian vps heb lopen. In dit Debian system loopt ook mijn lokale caching en authoritative DNS (voor mijn lokale domein) daar had ik ook ooit de NTP op ondergebracht. Dit oude Debian systeem word binnenkort vervangen en dan vervalt die NTP in Debian daar komt een authoritative only dns voor in de plaats in een nieuw Debian Jessie vps systeem. Unbound in pfSense vervangt al de caching dns server. Dit is allemaal lokaal. Aan de buitenkant heb ik ddns bij een dns registrar/dns provider.
Beste LarsvZ,
Heeft u dit inmiddels kunnen oplossen? zo ja, deel dan uw oplossing zodat andere in de toekomst hier ook wat aan hebben.
MVG
Heeft u dit inmiddels kunnen oplossen? zo ja, deel dan uw oplossing zodat andere in de toekomst hier ook wat aan hebben.
MVG
Ik heb hetzelfde probleem.
Via mobiele communicatie (vodafone) gaat het prima. Via Ziggo niet.
En nu verwacht je een oplossing, met die "overvloed" aan informatie? 🙁
En nu verwacht je een oplossing, met die "overvloed" aan informatie? 🙁
Ach de informatie is er toch al? Waarom hetzelfde schrijven wat LarsvZ al geschreven heeft? En blijkbaar is de oplossing nog steeds niet bekend, of heb jij de oplossing wel beste Gusto en houd je deze achter.😲
Waarom een eigen NTP-server?
- Begrijp je de impact van een eigen NTP-server.
- Welk besturings systeem.
- Welke NTP-server.
- Welke Instellingen.
- Wat werkt er niet.
🤔
- Begrijp je de impact van een eigen NTP-server.
- Welk besturings systeem.
- Welke NTP-server.
- Welke Instellingen.
- Wat werkt er niet.
🤔
Het feit dat ik een eigen NTP server nodig heb heeft te maken met een functionele eis die gesteld wordt vanuit een virtuele omgeving, namelijk Cisco VIRL. Op mijn laptop (met zware specificaties) draai in Ubuntu 14.04.1 met Cisco VIRL 1.2.83 op VM Workstation 12. En ja, ik begrijp de impact van NTPD.
Dit werkte tot een paar maanden geleden prima. Nu werkt het nog steeds prima als ik maar gebruik maak van mijn mobiele hotspot, dus niet ZIGGO. Dit alles is dus precies hetzelfde verhaal als van LarsvZ.
Maar volgens mij heeft ZIGGO tot op heden geen antwoord gegeven die tot tevredenheid stemt. Voor de goede orde, ik heb geen aanpassingen gedaan aan het ZIGGO modem of Firewall instellingen (ACL's), ook het forwarden van udp/123 heeft niet tot het gewenste resultaat geleid en heb ik intussen weer ongedaan gemaakt.
Het probleem zit dus werkelijk bij ZIGGO, want waarom moet Jesse (de moderator) trucjes uithalen (forwarding udp/123 in het "oude" UPC domein) om ntpd werkend te krijgen?
Dit werkte tot een paar maanden geleden prima. Nu werkt het nog steeds prima als ik maar gebruik maak van mijn mobiele hotspot, dus niet ZIGGO. Dit alles is dus precies hetzelfde verhaal als van LarsvZ.
Maar volgens mij heeft ZIGGO tot op heden geen antwoord gegeven die tot tevredenheid stemt. Voor de goede orde, ik heb geen aanpassingen gedaan aan het ZIGGO modem of Firewall instellingen (ACL's), ook het forwarden van udp/123 heeft niet tot het gewenste resultaat geleid en heb ik intussen weer ongedaan gemaakt.
Het probleem zit dus werkelijk bij ZIGGO, want waarom moet Jesse (de moderator) trucjes uithalen (forwarding udp/123 in het "oude" UPC domein) om ntpd werkend te krijgen?
Vertel het me maar! Bij mij iig niets en ik denk bij LarsvZ ook niets.
Ik denk dat Jesse eens antwoord moet geven, zeker over het feit dat hij en moet forwarden en het oude UPC domein moet gebruiken.
Vooralsnog heb ik geen probleem omdat ik mijn virtuele cisco lab kan gebruiken door een work-around. Word ik er blij van? Nou nee, maar het blijft wel stil aan de kant van Ziggo.
Persoonlijk denk ik dat het ACL is aan de kant van ZIGGO waarschijnlijk op een regionale of stedelijke router.
Ik denk dat Jesse eens antwoord moet geven, zeker over het feit dat hij en moet forwarden en het oude UPC domein moet gebruiken.
Vooralsnog heb ik geen probleem omdat ik mijn virtuele cisco lab kan gebruiken door een work-around. Word ik er blij van? Nou nee, maar het blijft wel stil aan de kant van Ziggo.
Persoonlijk denk ik dat het ACL is aan de kant van ZIGGO waarschijnlijk op een regionale of stedelijke router.
Er is wel iets veranderd, omdat het niet meer werkt. 😉
Wat meld ntpstat?
gusto@fx8150:~$ ntpstat
synchronised to NTP server (193.67.79.202) at stratum 2
time correct to within 30 ms
polling server every 1024 s
Wat meld ntpstat?
gusto@fx8150:~$ ntpstat
synchronised to NTP server (193.67.79.202) at stratum 2
time correct to within 30 ms
polling server every 1024 s
Reputatie 1
Volgens mij liep ik tegen hetzelfde probleem aan (Modem Ziggo in bridge modus gezet en aan mijn Fortigate FW gekoppeld). NTP deed het het niet meer. Met "ntpdate -u" werkte het wel, dus ik verdacht mijn FW. Na het maken van netwerk traces tussen de Fortigate en het Ziggo modem zag ik dat de fortigate de source port vertaalde van 123 naar 634 (een andere privileged port):
2018-01-11 15:05:37.062039 SYN-bit_HOME in 10.0.1.32.123 -> 17.253.52.253.123: udp 48
2018-01-11 15:05:37.062115 INTERNET out .634 -> 17.253.52.253.123: udp 48
2018-01-11 15:05:37.062145 wan1 out .634 -> 17.253.52.253.123: udp 48
En daar komt geen verkeer op terug vanuit Ziggo.
Met een high port werkt het wel (ntpdate -u):
2018-01-11 15:05:34.218166 SYN-bit_OFFICE in 10.0.0.8.38756 -> 95.211.160.148.123: udp 48
2018-01-11 15:05:34.218257 INTERNET out .PUBLIC-IP38756 -> 95.211.160.148.123: udp 48
2018-01-11 15:05:34.218285 wan1 out PUBLIC-IP.38756 -> 95.211.160.148.123: udp 48
2018-01-11 15:05:34.228807 wan1 in 95.211.160.148.123 -> PUBLIC-IP.38756: udp 48
2018-01-11 15:05:34.228807 INTERNET in 95.211.160.148.123 -> PUBLIC-IP.38756: udp 48
2018-01-11 15:05:34.228888 SYN-bit_OFFICE out 95.211.160.148.123 -> 10.0.0.8.38756: udp 48
Ik heb daarna mijn firewall rule voor het NTP verkeer aangepast zodat hij de source poort niet transleert en dan werkt het oook zonder -u:
2018-01-11 15:21:51.509456 SYN-bit_OFFICE in 10.0.0.8.123 -> 95.211.160.148.123: udp 48
2018-01-11 15:21:51.509540 INTERNET out PUBLIC-IP.123 -> 95.211.160.148.123: udp 48
2018-01-11 15:21:51.509567 wan1 out .PUBLIC-IP123 -> 95.211.160.148.123: udp 48
2018-01-11 15:21:51.516922 wan1 in 95.211.160.148.123 -> PUBLIC-IP.123: udp 48
2018-01-11 15:21:51.516922 INTERNET in 95.211.160.148.123 -> PUBLIC-IP.123: udp 48
2018-01-11 15:21:51.517003 SYN-bit_OFFICE out 95.211.160.148.123 -> 10.0.0.8.123: udp 48
En nu werkt mijn NTP daemon ook weer:
$ ntpq -c lpeers
remote refid st t when poll reach delay offset jitter
==============================================================================
alphyn.canonica 132.246.11.231 2 u 19 64 1 99.992 32.443 0.001
ntp1.nl.uu.net .GPS. 1 u 18 64 1 7.788 45.799 0.001
excalibur.proli 200.98.196.212 2 u 17 64 1 107.470 38.600 0.001
$
Grote vraag is waarom Ziggo NTP verkeer vanaf een source poort onder de 1024 (anders dan 123) blokkeert?
2018-01-11 15:05:37.062039 SYN-bit_HOME in 10.0.1.32.123 -> 17.253.52.253.123: udp 48
2018-01-11 15:05:37.062115 INTERNET out .634 -> 17.253.52.253.123: udp 48
2018-01-11 15:05:37.062145 wan1 out .634 -> 17.253.52.253.123: udp 48
En daar komt geen verkeer op terug vanuit Ziggo.
Met een high port werkt het wel (ntpdate -u):
2018-01-11 15:05:34.218166 SYN-bit_OFFICE in 10.0.0.8.38756 -> 95.211.160.148.123: udp 48
2018-01-11 15:05:34.218257 INTERNET out .PUBLIC-IP38756 -> 95.211.160.148.123: udp 48
2018-01-11 15:05:34.218285 wan1 out PUBLIC-IP.38756 -> 95.211.160.148.123: udp 48
2018-01-11 15:05:34.228807 wan1 in 95.211.160.148.123 -> PUBLIC-IP.38756: udp 48
2018-01-11 15:05:34.228807 INTERNET in 95.211.160.148.123 -> PUBLIC-IP.38756: udp 48
2018-01-11 15:05:34.228888 SYN-bit_OFFICE out 95.211.160.148.123 -> 10.0.0.8.38756: udp 48
Ik heb daarna mijn firewall rule voor het NTP verkeer aangepast zodat hij de source poort niet transleert en dan werkt het oook zonder -u:
2018-01-11 15:21:51.509456 SYN-bit_OFFICE in 10.0.0.8.123 -> 95.211.160.148.123: udp 48
2018-01-11 15:21:51.509540 INTERNET out PUBLIC-IP.123 -> 95.211.160.148.123: udp 48
2018-01-11 15:21:51.509567 wan1 out .PUBLIC-IP123 -> 95.211.160.148.123: udp 48
2018-01-11 15:21:51.516922 wan1 in 95.211.160.148.123 -> PUBLIC-IP.123: udp 48
2018-01-11 15:21:51.516922 INTERNET in 95.211.160.148.123 -> PUBLIC-IP.123: udp 48
2018-01-11 15:21:51.517003 SYN-bit_OFFICE out 95.211.160.148.123 -> 10.0.0.8.123: udp 48
En nu werkt mijn NTP daemon ook weer:
$ ntpq -c lpeers
remote refid st t when poll reach delay offset jitter
==============================================================================
alphyn.canonica 132.246.11.231 2 u 19 64 1 99.992 32.443 0.001
ntp1.nl.uu.net .GPS. 1 u 18 64 1 7.788 45.799 0.001
excalibur.proli 200.98.196.212 2 u 17 64 1 107.470 38.600 0.001
$
Grote vraag is waarom Ziggo NTP verkeer vanaf een source poort onder de 1024 (anders dan 123) blokkeert?
Reputatie 1
Hoi @Gusto
mischien om NTP amplification attacks tegen te gaan?
Op welke wijze zou x.x.x.x:634->y.y.y.y:123 meer kunnen bijdragen aan een NTP amplification attack dan x.x.x.x:123->y.y.y.y:123 of x.x.x.x:34567->y.y.y.y:123?
Groet,
Sake
Op welke wijze zou x.x.x.x:634->y.y.y.y:123 meer kunnen bijdragen aan een NTP amplification attack dan x.x.x.x:123->y.y.y.y:123 of x.x.x.x:34567->y.y.y.y:123?
Groet,
Sake
Reputatie 1
Maar ik stelde ook mischien. ;)
En van mijn kant was het ook een oprechte vraag 😉
Hopelijk kan iemand van Ziggo hier antwoord op geven...
Page 1 / 2
Registreren
Heb je al een account? Inloggen
Inloggen
Nog geen account? Eerste keer? Registreer
Inloggen met sociaal netwerk
Mijn Ziggo Account Inloggen met Facebookof
Voer je Ziggo-gebruikersnaam in, of het e-mailadres waarmee je je hebt aangemeld. We sturen je een e-mail met je gebruikersnaam en een link om je wachtwoord opnieuw in te stellen.