During the last few weeks I published a couple of blogposts concerning routing protocols such as BGP, OSPFv3, and EIGRP. (Use the “Cisco Router” tag on my blog to list all of them.) They are all part of my current Cisco lab that I am using for my CCNP TSHOOT exam preparation. While I depicted only the details of the routing protocols in those blogposts, I am showing my overall lab with all of its Cisco IOS configs here. Just to have the complete picture. There are a couple of not-yet-blogged configs such as VRRP, GLBP, NTP authentication, embedded event manager (EEM), or route-maps and distribute/prefix lists though.
Cisco’s IOS offers an easy to use feature for configuration versioning to an external server such as TFTP or SCP. Furthermore, you can use IOS commands to compare any two snapshots and to roll back to one of them.
And again: Here comes a pcapng capture taken for the dynamic routing protocol EIGRP. If you want to dig into EIGRP messages, download the trace file and browse around it with Wireshark. Since I used both Internet Protocols (IPv6 and legacy IP), MD5 authentication, route redistribution, etc., you can find many different messages in it.
Yet another routing protocol I played with in my lab. ;) This time: EIGRP, Enhanced Interior Gateway Routing Protocol, the
proprietary distance-vector routing protocol developed by Cisco, which is now public available (RFC 7868). However, no third-party products in here but only Cisco routers. I am using named EIGRP for both Internet Protocols, IPv6 and legacy IP, along with MD5 authentication and redistribution from OSPF.
Here comes a small lab consisting of three Cisco routers in which I used OSPFv3 for IPv6 with IPsec authentication. I am listing the configuration commands and some show commands. Furthermore, I am publishing a pcapng file so that you can have a look at it with Wireshark by yourself.
I already had an OSPFv2 for IPv4 lab on my blog. However, I missed capturing a pcap file in order to publish it. So, here it is. Feel free to have a look at another small lab with three Cisco routers and OSPFv2. Just another pcapng file to practise some protocol and Wireshark skills.
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.
In some situations you want to manage your firewall only from a dedicated management network and not through any of the data interfaces. For example, when you’re running an internal data center with no Internet access at all but your firewalls must still be able to get updates from the Internet. In those situations you need a real out-of-band (OoB) management interface from which all management traffic (DNS, NTP, Syslog, Updates, RADIUS, …) is sourced and to which the admins can connect to via SSH/HTTPS. Another example is a distinct separation of data and management traffic. For example, some customers want any kind of management traffic to traverse through some other routing/firewall devices than their production traffic.
Unfortunately the Fortinet FortiGate firewalls don’t have a reasonable management port. Their so-called “MGMT” port is only able to limit the access of incoming traffic but is not able to source outgoing traffic by default. Furthermore, in an HA environment you need multiple ports to access the firewalls independently. What a mess.
A functional workaround is to add another VDOM solely for management. From this VDOM, all management traffic is sourced. To have access to all firewalls in a high availability environment, a second (!) interface within this management VDOM is necessary. Here we go:
We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different…
I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What?
Just a quick note concerning the session sync on a Palo Alto Networks firewall cluster: Don’t trust the green HA2 bubble on the HA widget since it is always “Up” as long as the HA interface is up. It does NOT indicate whether the session sync is working or not. You MUST verify the session count on the passive unit to be sure. Here are some details:
I am using an almost hidden FTP server in my DMZ behind a Palo Alto Networks firewall. FTP is only allowed from a few static IP addresses, hence no brute-force attacks on my server. Furthermore, I have an “allow ping and traceroute from any to DMZ” policy since ping is no security flaw but really helpful while troubleshooting.
Now, here comes the point: My FTP server logfile showed dozens of connections from many different IP addresses from the Internet. WHAT? For the first moment I was really shocked. Have I accidentally exposed my FTP server to the Internet? Here is what happened:
In my previous blogpost I talked about the true random number generator (TRNG) within the Raspberry Pi. Now I am using it for a small online pre-shared key (PSK) generator at https://random.weberlab.de (IPv6-only) that you can use e.g. for site-to-site VPNs. Here are some details how I am reading the binary random data and how I built this small website.
Unpredictable random numbers are mandatory for cryptographic operations in many cases (ref). There are cryptographically secure pseudorandom number generators (CSPRNG) but the usage of a hardware random number generator (TRNG) is something I am especially interested in since many years. While there are many proprietary TRNGs (list) with different prices, I had a look at two cheap solutions: the Raspberry Pi’s hardware random number generator as well as an application that uses a DVB-T/RTL/SDR stick for gathering some noise.
I have tested both of them with various options and ran them against the dieharder test suite. In this post I am listing the CLI commands to get the random data from those source and I am listing the results of the tests.
Last but not least I was interested which “home-calling” connections my Yamaha R-N500 Network Receiver initiates. In my previous post I already analyzed the open ports within the network, while I showed a complete Apple AirPlay capture here. This time I was only interested in outgoing TCP/UDP connections to the Internet as well as how the Yamaha App “NP Controller” communicates with the receiver.
It turned out that it was not easy for me to fully analyze such a packet trace even though only a couple of connections were made. It consists of many protocols that I am not familiar with such as UPnP, MDNS, SSDP, and RTP. Anyway, ere we go: