Until now I generated all SSHFP resource records on the SSH destination server itself via ssh-keygen -r <name>. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found a way to generate SSHFP resource records remotely. Here we go:
This is actually a bad user experience problem: To generally omit the manual verification of SSH key fingerprints I am using SSHFP. With fully qualified domain names (FQDN) as the hostname for SSH connections such as ssh nb10.weberlab.de this works perfectly. However, admins are lazy and only use the hostname without the domain suffix to connect to their servers since the domain search does the rest: ssh nb10. Not so for SSHFP which fails since the default OpenSSH client does not use canonicalization for its DNS queries. Hence you must explicitly enable canonicalization for OpenSSH.
If you’re running your own DNS resolver you’re probably interested in some benchmark tests against it, such as: how fast does my own server (read: Raspberry Pi) answer to common DNS queries compared to 18.104.22.168.
In this blogpost I am showing how to use two tools for testing/benchmarking DNS resolvers: namebench & dnseval. I am listing the defaults, giving some hints about them and showing examples in which I tested some private and public DNS resolvers: a Fritzbox router, a Raspberry Pi with Unbound, Quad9, OpenDNS, and Google Public DNS.
I was interested in how Apple AirPlay works in my network. I am using an iPad to stream music to a Yamaha R-N500 network receiver. There is a great Unofficial AirPlay Protocol Specification which already shows many details about the used protocols. But since I am a networking guy I captured the whole process in order to analyze it with Wireshark.
I am using Nmap every time I installed a new server/appliance/whatever in order to check some unknown open ports from the outside. In most situations I am only doing a very basic run of Nmap without additional options or NSE scripts.
Likewise I am interested in how the Nmap connections appear on the wire. Hence I captured a complete Nmap run (TCP and UDP) and had a look at it with Wireshark. If you’re interested too, feel free to download the following pcap and have a look at it by yourself. At least I took some Wireshark screenshots to give a first glance about the scan.
As a network administrator I know that there are SSH fingerprints. And of course I know that I must verify the fingerprints for every new connection. ;) But I did not know that there are so many different kinds of fingerprints such as md5- or sha-hashed, represented in base64 or hex, and of course for each public key pair such as RSA, DSA, ECDSA, and Ed25519. Uh, a bit too complicated at a first glance. Hence I draw a picture.
And one more IPsec VPN post, again between the Palo Alto Networks firewall and a Fortinet FortiGate, again over IPv6 but this time with IKEv2. It was no problem at all to change from IKEv1 to IKEv2 for this already configured VPN connection between the two different firewall vendors. Hence I am only showing the differences within the configuration and some listings from common CLI outputs for both firewalls.
Towards the global IPv6-only strategy ;) VPN tunnels will be used over IPv6, too. I configured a static IPsec site-to-site VPN between a Palo Alto Networks and a Fortinet FortiGate firewall via IPv6 only. I am using it for tunneling both Internet Protocols: IPv6 and legacy IP.
While it was quite easy to bring the tunnel “up”, I had some problems tunneling both Internet Protocols over the single phase 2 session. The reason was some kind of differences within the IPsec tunnel handling between those two firewall vendors. Here are the details along with more than 20 screenshots and some CLI listings.
With PAN-OS version 8.0 Palo Alto Networks introduced another IPv6 feature, namely “NDP Monitoring for Fast Device Location“. It basically adds a few information to the existing neighbor cache such as the User-ID (if present) and a “last reported” timestamp. That is: the admin has a new reporting window within the Palo Alto GUI that shows the reported IPv6 addresses along with its MAC addresses. This is really helpful for two reasons: 1) a single IPv6 node can have multiple IPv6 addresses which makes it much more difficult to track them back to the MAC address and 2) if SLAAC is used you now have a central point where you can look up the MAC-IPv6 bindings (comparable to the DHCP server lease for legacy IPv4).
Haha, do you like acronyms as much as I do? This article is about the feature from Palo Alto Networks’ Next-Generation Firewall for Internet Protocol version 6 Neighbor Discovery Protocol Router Advertisements with Recursive Domain Name System Server and Domain Name System Search List options. ;) I am showing how to use it and how Windows and Linux react on it.
And finally the throughput comparison of IPv6 and legacy IP on a Juniper ScreenOS firewall. Nobody needs this anymore since they are all gone. ;) But since I did the same speedtests for Palo Alto and FortiGates I was interested in the results here as well.
Just for fun some more VPN throughput tests, this time for the late Juniper ScreenOS firewalls. I did the same Iperf TCP tests as in my labs for Fortinet and Palo Alto, while I was using six different phase1/2 proposals = crypto algorithms. The results were as expected with one exception.