To keep things as consistent as possible with the IPv4 security
module, I'm using the same diagram here except with updated types and
codes for IPv6. First, we want our Globomantics client to be able to
ping the Wired Brain Coffee server.
This uses ICMPv6 echo‑request messages. In reply, the server uses an
ICMPv6 echo‑reply message to signal success. Next, our client needs
traceroute capabilities, which means IPv6 UDP packets in the standard
traceroute port range must be permitted. In return, any devices past the
firewall need to send both hop limit exceeded messages and port
unreachables back towards the client.
We should also add the ICMPv6 packet too big message for MTU
discovery across the network. Last, our firewall may be
configured to send administratively prohibited messages using
type 1, code 1 back to the client.
This would signal that traffic was denied by the
firewall, a useful troubleshooting feature.
We haven't seen this packet in a capture yet, but we will shortly. One caveat
worth mentioning is that when doing IPv6 security, don't neglect the IPv6 ND
messages or other important link‑local traffic. In IPv4, ARP messages just work
as they are not IP packets and aren't subject to IP traffic filters. With IPv6,
you will often have to be explicit.
Will this new IPv6 security policy function as designed? Only one way to
find out. Now that we've configured our IPv6 security policy on the
Globomantics R3 router facing Wired Brain Coffee company, we can test
some flows across it. Before we do, I'll show you the configuration. I
won't examine every line here since it's almost identical to the IPv4
policy, but I will point out our explicit permitting of all IPv6
link‑local traffic,
both unicast and multicast. This ensures IPv6 ND will function correctly.
Now I'll switch to the client console. I'm sending traffic from our
client to the remote server at fc00:10:2:5::5.
I'll run through these tests in a checklist format. ICMPv6 ping using
echo‑request messages, check. Traceroute using IPv6 UDP probes,
hop limit exceeded messages, and port unreachable messages, good to
go. Telnet using IPv6 TCP packets looks good too.
I can see the server's shell prompt.
Let's ensure the firewall is allowing packet too big
messages to pass back through it.
I've reduced the MTU on the Wired Brain Coffee server LAN,
which is on the far side of the firewall.
Let's use debugging temporarily to ensure the client sees the correct MTU.
Great. We see the MTU is 1400 via the packet too big message.
Now let's test an unauthorized flow using Telnet to
mimic an HTTP packet on TCP port 80.
We are immediately rejected, as expected.
We've just revealed our final ICMPv6 message, the
administratively prohibited unreachable.
Let's take a look deeper into this packet. Next.