Following is a list of the most common Cisco device configuration commands that I am using when setting up a router or switch from scratch, such as hostname, username, logging, vty access, ntp, snmp, syslog. For a router I am also listing some basic layer 3 interface commands, while for a switch I am listing STP and VTP examples as well as the interface settings for access and trunk ports.
This is not a detailed best practice list which can be used completely without thinking about it, but a list with the most common configurations from which to pick out the once required for the current scenario. Kind of a template. Of course with IPv6 and legacy IP.
Continue reading Basic Cisco Configuration
When using a multilayer firewall design it is not directly clear on which of these firewalls remote site-to-site VPNs should terminate. What must be considered in such scenarios? Differentiate between partners and own remote offices? Or between static and dynamic peer IPs? What about the default routes on the remote sites?
Following is a discussion about different approaches and some best practices. Since not all concepts work with all firewall vendors, the following strategies are separated by common firewalls, i.e., Cisco ASA, Fortinet FortiGate, Juniper ScreenOS, Palo Alto.
Continue reading Where to terminate Site-to-Site VPN Tunnels?
I am lucky to have a full dual-stack ISP connection at home. However, the ISP only offers a dynamic IPv6 prefix with all of its disadvantages (while no single advantage). In this post, I am summarizing the limitations of a dynamic prefix and some of the ideas on how to overcome them. I am always comparing the “IPv6 dynamic prefix” state with the legacy “dynamic IPv4 address” situation. I suppose that some of these problems will hit many small office / home office locations during the next years.
Of course, IPv6 ISP connections with dynamic prefixes should only be purchased at private home sites. It is no problem to have new IPv6 addresses there because all connections are outbound. However, many small remote offices (SOHO) might rely on such cheap ISP connections, too. If they provide some servers in a DMZ or other components such as network cameras, building components with IPv6 connections, etc., they will run into these kind of problems. (The remote office could even tunnel every outbound IPv6 traffic through a VPN to the headquarter. But if it wants to use a local breakout, this won’t be an alternative.)
Continue reading IPv6 Dyn Prefix Problems
With global IPv6 routing, every single host has its own global unicast IPv6 address (GUA). No NAT anymore. No dirty tricks between hosts and routers. Great. Security is made merely by firewalls and policies. Site-to-site VPNs between partners can be build without address conflicts. Great again!
However, one problem to consider is the proper IPv6 routing via site-to-site VPNs since both sides now can reach each other even without a VPN. This was (mostly) not true with IPv4 in which both partners heavily relied on private RFC 1918 addresses that were not routable in the Internet. If specific IPv6 traffic should flow through a VPN but does actually traverse the Internet, it would be easy for a hacker to eavesdrop this traffic, leading to a security issue!
The following principles should be realized properly to assure that IPv6 traffic is never routed through the mere Internet when a site-to-site VPN tunnel is in place. Even in a failure of that tunnel. The principles can be applied to any IPv6 tunnels between partners, remote sites, home offices, etc., as long as the other site has its own global unicast IPv6 address space. (For VPNs in which a sub-prefix from the headquarters prefix is routed to a remote site, the situation behaves different. This article focuses on the routing between different IPv6 adress spaces.)
Continue reading IPv6 Site-to-Site VPN Recommendations
One core topic when designing firewall policies is the following question: Is ping a security attack? Should ICMP echo-request messages be blocked in almost any directions?
My short answer: Ping is your friend. :) You won’t block hackers if you block ping. Instead, ping is quite useful for network administrators checking basic network connectivity. That is: I suggest to allow ping anywhere around, accept incoming connections from the Internet to the trusted networks.
Here comes a discussion:
Continue reading Why Ping is no Security Flaw! (But your Friend)
The Palo Alto firewall supports policy entries that refer to multiple source and destination zones. This is useful especially when there are branch offices with multiple zones and a site-to-site VPN to the main office. In this scenario, every zone in the branch office might have a “permit any any” to the main office and vice versa, while the zones on the branch office should not have a permit among themselves. (Of course, the traffic on the main office is restricted and not permitted generally.) Here are two ways to accomplish that scenario.
Continue reading Bidirectional Policy Rules on a Palo Alto Firewall
During my job I am frequently discussing with people why they use NAT or why they believe that NAT adds any security to their networks, mainly some obscurity as NAT (PAT) hides the internal network structure. However, NAT does not add any real security to a network while it breaks almost any good concepts of a structured network design. To emphasize this thesis, here is a discussion:
Continue reading Why NAT has nothing to do with Security!