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.
It is probably one of the most used protocols in my daily business but I have never captured it in detail: IKE and IPsec/ESP. And since IKEv2 is coming I gave it a try and tcpdumped two VPN session initiations with IKEv1 main mode as well as with IKEv2 to see some basic differences.
Of course I know that all VPN protocols are encrypted – hence you won’t see that much data. But at least you can see the basic message flow such as “only 4 messages with IKEv2” while some more for legacy IKEv1. I won’t go into the protocol details at all. I am merely publishing two pcap files so that anyone can have a look at a VPN session initiation. A few Wireshark screenshots complete the blogpost.
A few month ago I published many Layer 2/3 challenges on my blog. Beside the happy feedback I got some remarks that the challenges were to easy at all because you only needed the display filter at Wireshark while no deep protocol knowledge.
Ok, “challenge excepted” ;) here I have some more protocol related challenges for you: With this post I am publishing a pcap which has four site-to-site IPsec VPN connections inside. On the first half of the pcap all four of them are wrongly configured, hence, not working. –> What are the reasons for that? <–
While preparing for my CCNP SWITCH exam I built a laboratory with 4 switches, 3 routers and 2 workstations in order to test almost all layer 2/3 protocols that are related to network management traffic. And because “PCAP or it didn’t happen” I captured 22 of these protocols to further investigate them with Wireshark. Oh oh, I remember the good old times where I merely used unmanaged layer 2 switches. ;)
In this blogpost I am publishing the captured pcap file with all of these 22 protocols. I am further listing 46 CHALLENGES as an exercise for the reader. Feel free to download the pcap and to test your protocol skills with Wireshark! Use the comment section below for posting your answers.
Of course I am running my lab fully dual-stacked, i.e., with IPv6 and legacy IP. On some switches the SDM template must be changed to be IPv6 capable such as sdm prefer dual-ipv4-and-ipv6 default .
I really love ping! It is easy to use and directly reveals whether the network works or not. Refer to Why Ping is no Security Flaw! (But your Friend) and Advanced Tracerouting. At least outgoing pings (from trust to untrust) should be allowed without any security concerns. However, many companies are denying these ICMP echo-requests from untrust into the DMZ which makes it difficult to test whether all servers are up and running.
I was sitting at the customer’s site replacing the DMZ firewall. Of course I wanted to know (from the outside) whether all servers are connected correctly (NAT) and whether the firewall permits the connections (policy). However, ping was not allowed. Therefore I used several layer 7 ping tools that generate HTTP, DNS, or SMTP sessions (instead of ICMP echo-requests) and revealed whether the services (and not only the servers) were running. Great!
This post shows the installation and usage of httping, dnsping, and smtpping on a Linux machine, in my case a Ubuntu server 14.04.4 LTS, as well as some Wireshark screenshots from captured sessions. Finally, a pcap file can be downloaded that shows the sample runs of all three tools.
Similar to my test lab for OSPFv2, I am testing OSPFv3 for IPv6 with the following devices: Cisco ASA, Cisco Router, Fortinet FortiGate, Juniper SSG, Palo Alto, and Quagga Router. I am showing my lab network diagram and the configuration commands/screenshots for all devices. Furthermore, I am listing some basic troubleshooting commands. In the last section, I provide a Tcpdump/Wireshark capture of an initial OSPFv3 run.
I am not going into deep details of OSPFv3 at all. But this lab should give basic hints/examples for configuring OSPFv3 for all of the listed devices.
When explaining IPv6 I am always showing a few Wireshark screenshots to give a feeling on how IPv6 looks like. Basically the stateless autoconfiguration feature (SLAAC), DHCPv6, Neighbor Discovery, and a simple ping should be seen/understood by any network administrator before using the new protocol.
Therefore I captured the basic IPv6 autoconfiguration with a Knoppix Linux behind a Telekom Speedport router (German ISP, dual-stack) and publish this capture file here. I am using this capture to explain the basic IPv6 features.
A commonly misunderstanding of traceroute is that it fully relies on ping. “If I block ping at my firewall, no one can use traceroute to reveal my internal routing path”. Unfortunately this is not true. If traceroute is used with TCP SYN packets on permitted TCP/UDP ports, all intermediary firewalls will handle the IP packets with TTL = 0 corresponding to the RFCs and will reply with an ICMP time exceeded packet to the source.
In this post I am listing an example that uses traceroute with TCP port 25 (SMTP) to traverse a firewall. A sample pcap file can be downloaded while some Wireshark screenshots show a few details.