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 →
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 →
IPv6 brings us enough addresses until the end of the world. Really? Well… No. There was an interesting talk at RIPE77 called “The Art of Running Out of IPv6 Addresses” by Benedikt Stockebrand that concludes that we will run out of IPv6 addresses some day.
Luckily Palo Alto Networks has already added one feature to expand the IPv6 address space by making them case sensitive. That is: you can now differentiate between upper and lower case values “a..f” and “A..F”. Instead of 16 different hexadecimal values you now have 22 which increases the IPv6 space from to about . Here is how it works on the Palo Alto Networks firewall:
Continue reading Using Case Sensitive IPv6 Addressing on a Palo Alto →
What’s the first step in a networker’s life if he wants to work with an unknown protocol: he captures and wiresharks it. ;) Following is a downloadable pcap in which I am showing the most common NTP packets such as basic client-server messages, as well as control and authenticated packets. I am also showing how to analyze the delta time with Wireshark, that is: how long an NTP server needs to respond to a request.
Continue reading Packet Capture: Network Time Protocol (NTP) →
I got an email where someone asked whether I know how to change the link-local IPv6 addresses on a FortiGate similar to any other network/firewall devices. He could not find anything about this on the Fortinet documentation nor on Google.
Well, I could not find anything either. What’s up? It’s not new to me that you cannot really configure IPv6 on the FortiGate GUI, but even on the CLI I couldn’t find anything about changing this link-local IPv6 address from the default EUI-64 based one to a manually assigned one. Hence I opened a ticket at Fortinet. It turned out that you cannot *change* this address at all, but that you must *add* another LL address which will be used for the router advertisements (RA) after a reboot (!) of the firewall. Stupid design!
Continue reading Trying to change an IPv6 Link-Local Address on a FortiGate →
I did a session at SharkFest’18 Europe in Vienna with the title of “Crash Course: IPv6 and Network Protocols“. Since the presentation slides + audio were recorded you can listen to the talk, too. Here are some notes about the motivation for this session as well as feedback from the attendees.
Continue reading SharkFest’18 Europe: Crash Course: IPv6 and Network Protocols →
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.
Continue reading My CCNP TSHOOT Lab: The Overall Picture →
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.
Continue reading EIGRP Capture →
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.
Continue reading Dual-Stack EIGRP Lab →
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.
Continue reading OSPFv3 with IPsec Authentication →
For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blog post for details about the lab, that is: MP-BGP with IPv6 and legacy IP, neighbouring via both protocols as well, with and without password. The involved routers were 2x Cisco routers, one Palo Alto Networks firewall, and one Fortinet FortiGate firewall.
Continue reading MP-BGP Capture →
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.
Continue reading Basic MP-BGP Lab: Cisco Router, Palo Alto, Fortinet →
If you have ever read some docs or RFCs about IPv6 you should be quite familiar with the
2001:db8::/32 “IPv6 Address Prefix Reserved for Documentation”, RFC 3849. This RFC clearly states how you should handle addresses within this range: “This assignment implies that IPv6 network operators should add this address prefix to the list of non-routeable IPv6 address space, and if packet filters are deployed, then this address prefix should be added to packet filters.”
I was interested whether those addresses are actually used in the Internet. For this purpose I analyzed my firewall logs for 6 months to get an idea. Though it was not that much, I actually got a couple of connections inbound and outbound (!) sourced or destined to those reserved IPv6 addresses.
Continue reading 2001:db8::/32 in the Wild →
While there are many approaches on how to structure your IPv6 prefix into /64 subnets (blogposts, books, talks) there are only a few hints what you can do with the other 64 bits of the addresses, namely the IPv6 interface identifier or IID. To my mind you can put some (but not too much) logic into those IIDs to a) have some structure for your addresses that b) helps you identifying those addresses when seeing them in logs or anywhere else. Hence it is easier for you to remember the IPv6 address behind a name (forward DNS) as well as the host when seeing the address (reverse DNS).
This post just shows the approach I am using in my lab. You might find it useful or you might disagree completely. Anyhow, feel free to comment your experiences or solutions for that. :D I am wondering why there isn’t much discussion about these IIDs at all. Maybe for some good reasons I am not seeing yet?
Continue reading IPv6 Interface ID Structure →
If you’re following my blog you probably know that I am using IPv6 everywhere. Everything in my lab is dual-stacked if not already IPv6-only. Great so far.
A few months ago my lab moved to another ISP which required to change all IP addresses (since I don’t have PI space yet). Oh boy! While it was almost no problem to change the legacy IPv4 addresses (only a few NATs), it was a huge pain in the … to change the complete infrastructure with its global unicast IPv6 addresses. It turned out that changing the interface IPv6 addresses was merely the first step, while many modifications at different services were the actual problem. And this was *only* my lab and not a complex company or the like.
Following you find a list of changes I made for IPv6 and for legacy IP. Just an overview to get an idea of differences and stumbling blocks.
Continue reading IPv6 Renumbering: A Pain in the … →