Adding your NTP Server to the NTP Pool Project

NTP, Tutorial/Howto, ,

Do you have a running NTP server with a static IP address? What about joining the NTP Pool project by adding your server to the pool? You will give something back to the Internet community and feel good about it. ;)

It doesn’t matter if you’re running a Raspberry Pi with GPS/DCF77 on your home, or a fully-featured NTP appliance such as the ones from Meinberg on your enterprise DMZ. Just a few clicks and your server will be used by the NTP Pool’s round-robin DNS. Here’s a simple tutorial:

Continue reading Adding your NTP Server to the NTP Pool Project →

Using RIPE Atlas for NTP Measurements

NTP, RIPE Atlas,

If you are operating a public available NTP server, for example when you’re going to join the NTP Pool Project, you probably want to test whether your server is working correctly. Either with a one-off measurement from hundreds of clients or continuously to keep track of its performance. You can use the RIPE Atlas measurement platform (Wikipedia) for both use cases. Here’s how:

Continue reading Using RIPE Atlas for NTP Measurements →

Monitoring a Meinberg LANTIME NTP Server

Meinberg, Monitoring, NTP, Tutorial/Howto, , , , , , , , , ,

Monitoring a Meinberg LANTIME appliance is much easier than monitoring DIY NTP servers. Why? Because you can use the provided enterprise MIB and load it into your SNMP-based monitoring system. Great. The MIB serves many OIDs such as the firmware version, reference clock state, offset, client requests, and even more specific ones such as “correlation” and “field strength” in case of my phase-modulated DCF77 receiver (which is called “PZF” by Meinberg). And since the LANTIME is built upon Linux, you can use the well-known system and interfaces MIBs as well for basic coverage. Let’s dig into it:

Continue reading Monitoring a Meinberg LANTIME NTP Server →

Monitoring a GPS NTP Server

Monitoring, NTP, Tutorial/Howto, , , , , , , , , , ,

Beyond monitoring Linux OS and basic NTP statistics of your stratum 1 GPS NTP server, you can get some more values from the GPS receiver itself, namely the number of satellites (active & in view) as well as the GPS fix and dilution of precision aka DOP. This brings a few more graphs and details. Nice. Let’s go:

Continue reading Monitoring a GPS NTP Server →

Monitoring a DCF77 NTP Server

Monitoring, NTP, Tutorial/Howto, , , , , , ,

Now that you’re monitoring the Linux operating system as well as the NTP server basics, it’s interesting to have a look at some more details about the DCF77 receiver. Honestly, there is only one more variable that gives a few details, namely the Clock Status Word and its Event Field. At least you have one more graph in your monitoring system. ;)

Continue reading Monitoring a DCF77 NTP Server →

Counting NTP Clients

Monitoring, NTP, Syslog, Tutorial/Howto, , , , , , , , , , ,

Wherever you’re running an NTP server: It is really interesting to see how many clients are using it. Either at home, in your company or worldwide at the NTP Pool Project. The problem is that ntp itself does not give you this answer of how many clients it serves. There are the “monstats” and “mrulist” queries but they are not reliable at all since they are not made for this. Hence I had to take another path in order to count NTP clients for my stratum 1 NTP servers. Let’s dig in:

Continue reading Counting NTP Clients →

Basic NTP Server Monitoring

Monitoring, NTP, Tutorial/Howto, , , , , , , , , ,

Now that you have your own NTP servers up and running (such as some Raspberry Pis with external DCF77 or GPS times sources) you should monitor them appropriately, that is: at least their offset, jitter, and reach. From an operational/security perspective, it is always good to have some historical graphs that show how any service behaves under normal circumstances to easily get an idea about a problem in case one occurs. With this post I am showing how to monitor your NTP servers for offset, jitter, reach, and traffic aka “NTP packets sent/received”.

Continue reading Basic NTP Server Monitoring →

Basic NTP Client Test: ntpdate & sntp

Authentication, Linux, Monitoring, NTP, , , , , , ,

During my work with a couple of NTP servers, I had many situations in which I just wanted to know whether an NTP server is up and running or not. For this purpose, I used two small Linux tools that fulfil almost the same: single CLI command while not actually updating any clock but only displaying the result. That is: ntpdate & sntp. Of course, the usage of IPv6 is mandatory as well as the possibility to test NTP authentication.

Continue reading Basic NTP Client Test: ntpdate & sntp →

DNS Capture: UDP, TCP, IP-Fragmentation, EDNS, ECS, Cookie

DNS/DNSSEC, , , , , , , , , , , ,

It’s not always this simple DNS thing such as “single query – single answer, both via UDP”. Sometimes you have some more options or bigger messages that look and behave differently on the network. For example: IP fragmentation for larger DNS answers that do not fit into a single UDP datagram (hopefully not after the DNS flag day 2020 anymore), or DNS via TCP, or some newer options within the EDNS space such as “EDNS Client Subnet” (ECS) or DNS cookies.

I won’t explain any details about those options, but I am publishing a pcap with that kind of packets along with some Wireshark screenshots. Feel free to dig into it.

Continue reading DNS Capture: UDP, TCP, IP-Fragmentation, EDNS, ECS, Cookie →

6in4 Traffic Capture

IPv6, , , , , , ,

Since my last blogposts covered many 6in4 IPv6 tunnel setups (1, 2, 3) I took a packet capture of some tunneled IPv6 sessions to get an idea how these packets look like on the wire. Feel free to download this small pcap and to have a look at it by yourself.

A couple of spontaneous challenges from the pcap round things up. ;)

Continue reading 6in4 Traffic Capture →

Juniper ScreenOS with a 6in4 Tunnel

IPv6, Juniper Networks, , , , ,

Yes, I know I know, the Juniper ScreenOS devices are Out-of-Everything (OoE), but I am still using them for a couple of labs. They simply work as a router and VPN gateway as well as a port-based firewall. Perfect for labs.

For some reasons I had another lab without native IPv6 Internet. Hence I used the IPv6 Tunnel Broker one more time. Quite easy with the SSGs, since HE offers a sample config. But even through the GUI it’s just a few steps:

Continue reading Juniper ScreenOS with a 6in4 Tunnel →

Workaround for Not Using a Palo Alto with a 6in4 Tunnel

Cisco Systems, IPv6, Palo Alto Networks, , , , , ,

Of course, you should use dual-stack networks for almost everything on the Internet. Or even better: IPv6-only with DNS64/NAT64 and so on. ;) Unfortunately, still not every site has native IPv6 support. However, we can simply use the IPv6 Tunnel Broker from Hurricane Electric to overcome this time-based issue.

Well, wait… Not when using a Palo Alto Networks firewall which lacks 6in4 tunnel support. Sigh. Here’s my workaround:

Continue reading Workaround for Not Using a Palo Alto with a 6in4 Tunnel →

Using a FortiGate with a 6in4 Tunnel

Fortinet, IPv6, , , , ,

For some reason, I am currently using a FortiGate on a location that has no native IPv6 support. Uh, I don’t want to talk about that. ;) However, at least the FortiGate firewalls are capable of 6in4 tunnels. Hence I am using the IPv6 Tunnel Broker from Hurricane Electric again. Quite easy so far.

But note, as always: Though FortiGate supports these IPv6 features such as a 6in4 tunnel or stateful/-less DHCPv6 server, those features are NOT stable or well designed at all. I had many bugs and outages during my last years. Having “NAT enabled” on every new IPv6 policy is ridiculous. Furthermore, having independent security policies for legacy IP and IPv6 is obviously a really bad design. One single policy responsible for both Internet protocols is a MUST. Anyway, let’s look at the 6in4 tunnel:

Continue reading Using a FortiGate with a 6in4 Tunnel →

PAN Blocking Details

Design/Policy, Palo Alto Networks, , , , ,

One of my readers sent me this question:

We have an internal discussion about whether it is possible to block the 3 way hanshake TCP but allow the JDBC application protocol. In other words we would like to block the test of the port with the command “telent address port” but we would like that the connections via JDBC continue to work. is it possible to do this theoretically? Is it possibile to do it with paloalto firewall?

Let’s have a look:

Continue reading PAN Blocking Details →