Site-to-site VPNs part IV: Vyatta

A free version of the new Vyatta 6.4 with a remarkable straight-forward configuration for VPN if you’re getting familiar with the concepts (which, if you’ve read the first three parts of this series, should be the case now). Just like the previous example, this will use 3DES, MD5, PFS, DH Group 2, and some default lifetimes. Vyatta also supports SHA and AES-128 and AES-256. Strange but true: AES-192 does not seem to be an option. If anything is unclear, Part I may have the answer.

On to the config. To cover it completely, first the interface configuration and a default route, as the VPN relies on routes to decide where to route traffic before encryption (just like the Cisco devices).

set interfaces ethernet eth0 address ip-address/netmask
set protocols static route 0.0.0.0/0 next-hop gateway-address

Phase 1 parameters:

set vpn ipsec ike-group IKE lifetime 86400
set vpn ipsec ike-group IKE proposal 1 encryption 3des
set vpn ipsec ike-group IKE proposal 1 hash md5
set vpn ipsec ike-group IKE proposal 1 dh-group 2

Just like with Cisco, the proposal number is for the order in which the different proposals are examined. Phase 2 is no different from that:

set vpn ipsec esp-group ESP lifetime 3600
set vpn ipsec esp-group ESP mode tunnel
set vpn ipsec esp-group ESP proposal 1 encryption 3des
set vpn ipsec esp-group ESP proposal 1 hash md5
set vpn ipsec esp-group ESP pfs dh-group2

PFS is optional, of course. Now, IPsec has to be activated on a per-interface basis. Again, a simple command for the outgoing interface:

set vpn ipsec ipsec-interfaces interface eth0

Finally, the definition of a VPN peer, it’s parameters, shared key, local and remote subnets, and Phase 1 and Phase 2 proposals:

set vpn ipsec site-to-site peer peer-ip-address
set vpn ipsec site-to-site peer peer-ip-address local-ip local-address
set vpn ipsec site-to-site peer peer-ip-address authentication pre-shared-secret key
set vpn ipsec site-to-site peer peer-ip-address ike-group IKE
set vpn ipsec site-to-site peer peer-ip-address tunnel 1 esp-group ESP
set vpn ipsec site-to-site peer peer-ip-address tunnel 1 local subnet source-network/mask
set vpn ipsec site-to-site peer peer-ip-address tunnel 1 remote subnet destination-network/mask

That’s it. In fact, I’ve found this to be one of the most simply CLI-based VPN configurations I’ve come across so far. The only thing slightly different from most configurations is the requirement of the local-ip parameter. Usually, this is set to the IP address of the outgoing interface, but it can be interesting to set this to a loopback address for which a route is known, so failure of a physical interface does not terminate the VPN connection.

Advertisement

Site-to-site VPNs part III: Cisco ASA

Third part of the S2S VPN series. Again with Cisco, but this time on an ASA. Since the ASA can be managed in GUI with ASDM, configuration is quite straightforward.

The S2S VPN configuration menu can be found under ‘Configuration’, ‘Site-to-Site VPN’. There you can add a new VPN connection, or edit an existing one.

The configuration menu needs little explanation, as it nicely covers everything a S2S VPN needs (see part I). Only worth noting is IKEv2, which isn’t used a lot these days and can safely be disabled. The IKE and IPsec proposals are already filled in with all supported combinations. The VPN will work this way but it can be easier to troubleshoot and understand to just allow the proposals that are needed for a VPN.

If you want to use PFS, it can be found under ‘Advanced’, ‘Crypto Map Entry’, together with some more options.

Unfortunately, seeing whether a VPN is up or not in the GUI isn’t possible. But the GUI does have logging, which can show the buildup and even reasons for failure in real-time. The CLI, just like with a Cisco IOS, uses the commands ‘show crypto isakmp sa’ for Phase 1 and ‘show crypto ipsec sa’ for Phase 2. Straightforward, isn’t it?

Site-to-site VPNs part II: Cisco IOS

Now that the theory has been explained, on to the first S2S VPN configuration. This example will use 3DES and MD5, DH Group 2, and some default lifetimes.

In Cisco terminology, ‘isakmp’ is used for Phase 1, and ‘ipsec’ for Phase 2 (many systems refer to it this way). VPN uses encryption, so most commands are done using the ‘crypto’ engine. The config for the first Phase is logical:

Router(config)#crypto isakmp policy 1
Router(config-isakmp)#encryption 3des
Router(config-isakmp)#hash md5
Router(config-isakmp)#group 2
Router(config-isakmp)#authentication pre-share
Router(config-isakmp)#lifetime 86400
Router(config-isakmp)#exit

The policy number does not have to match with the rest of the upcoming configuration. In fact, the IOS tries to use all Phase 1 proposals configured for all VPN peers until a matching one is found, e.g. if policy 1 matches, then it will be used, if it doesn’t, policy 2 will be tried, and so on.

This is not a complete Phase 1 configuration: though pre-shared key authentication is specified, no key is entered. A key needs to be entered on a per-peer basis using the following command:

Router(config)#crypto isakmp key 0 key address peer-ip-address

For Phase 2, some more parameters are required. First the ‘transform set’, which is how the packets will actually be encrypted.

Router(config)#crypto ipsec transform-set VPN-1 esp-3des esp-md5-hmac
Router(cfg-crypto-trans)#exit

This needs some more explaining:

• The name is free to choose. Try to keep it consistent, I usually start the name with ‘VPN-‘ here.
• The ‘esp’ in ‘esp-3des’ means the use of the Encapsulating Security Payload (ESP) header. The other option, Authentication Header (AH) is rarely, if ever, used.
• HMAC, or Hash-based message authentication code, specifies the mathematics for the encryption, and it’s the only available option.
• You can set transport or tunnel mode in the configuration. It defaults to tunnel mode and unless transport mode is needed for a specific reason, it’s the best way.

Next the encryption domain. Not surprisingly, IOS uses an extended access-list for this.

Router(config)#ip access-list extended AL4-VPN-1
Router(config-ext-nacl)#number permit ip source-network wildcardmask destination-network wildcardmask
Router(config-ext-nacl)#exit

I like to use naming conventions and best practices. My encryption domain access-lists are usually named ‘AL4-VPN-…’ and use sequence numbers for clarity. Also, it’s perfectly possible to use single hosts in an accesslist (wildcard 0.0.0.0 or ‘host’ keyword), and you can use multiple lines to send multiple subnets through the tunnel. Of course, the remote peer should have the same encryption domain, but his source subnets should be your destination subnets, and vice versa.

The above two parts of the Phase 2 now need to be connected together, and the remaining parameters (lifetime, peer IP, optionally PFS with a DH group) need to be added. Then, an interface has to be selected that will form the VPN. This is the final step, and it’s all done inside a crypto map:

Router(config)#crypto map VPNMAP 1 ipsec-isakmp
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
Router(config-crypto-map)# set security-association lifetime seconds 3600
Router(config-crypto-map)# set transform-set VPN-1
Router(config-crypto-map)# set pfs group2
Router(config-crypto-map)# set peer peer-ip-address
Router(config-crypto-map)# match address AL4-VPN-1
Router(config-crypto-map)# exit
Router(config)#interface interface
Router(config-if)#crypto map VPNMAP
Router(config-if)#exit

The ‘1’ used above is the sequence number. You can only assign one crypto map name per interface. To have multiple VPNs through the same interface, create crypto maps with the same name, but different sequence numbers.

Also, depending on the platform, sometimes a (static) route out of the VPN enabled interface for the remote subnet is needed, although usually a default route will do. Either add the static routes manually, or issue ‘reverse-route static’ under the crypto map configuration, after which the routes will automatically be created.

The VPN is now configured but will not come up until it is triggered by ‘interesting traffic’, traffic matching the access list that needs to be encrypted. Troubleshooting is done using ‘show crypto isakmp sa’ for Phase 1 and ‘show crypto ipsec sa’ for Phase 2. These commands and their subcommands give an indication if the VPN is up.

That concludes the Cisco IOS VPN configuration. Other platforms will be described in upcoming parts!

Site-to-site VPNs part I: theory.

The different types of VPN I’ve explained before, but in the upcoming articles I’ll cover more configuration details of site-to-site (S2S) VPN connections on different platforms. To set up a S2S VPN and connect two or more remote subnets to each other, first some theory about the required parameters. I’m not going to cover everything in-depth, just enough to set up the VPN.

A VPN uses encryption and hashing: encryption so no outsider can capture useful data, and hashing to verify that the sender the data is who he says he is and no alteration of data was done in transit.

First encryption. Important to understand here is that no encryption is truly unbreakable. Any key or encryption can be broken with brute-forcing: just trying all possible combinations until the right one is found. The encryption standards just have a massive amount of combinations, making this nearly impossible, e.g. 128-bit keys yield 3.4*10³⁸ possibilities.

There are many possible encryption schemes, but these two are used the most:

• 3DES, uses 168-bit keys to encrypt data. It’s been around since 1998 and some weaknesses have been found, but none that bad that encryption can be broken in a reasonable amount of time.
• AES, which uses 128, 192 or 256-bit keys. One weakness has been found so far, now requiring four times less computational power to break AES, but still well beyond any reasonable time frame (modern-day computers would still need millennia).

Blowfish encryption is an open standard, but not widely supported in vendor products so rarely seen in production environments. Most devices do support DES encryption (yes, 3DES is derived from it), but DES is considered breakable and insecure.

Hashing, the other main VPN parameter, also comes in two widely used flavors:

• MD5, while using 128-bit hashes, is considered insecure. A modern-day multi-core computer can break the encryption in less than a minute.
• SHA. SHA-1 uses a 160-bit hash, but has weaknesses and just like MD5 is supposedly cracked in less than a minute. SHA-2 however uses several different key lengths and has as of this article’s date not yet been broken, which makes it the only safe hash with support on many platforms.
  SHA-3 is a new standard that was announced just this month, and has no practical implementations yet.

While most of these hashing methods by themselves are insecure, they are still widely used in VPNs because the encryption provides sufficient protection already (the hash is also encrypted). Adding to the confusion, some platforms mention ‘SHA’ without indication about the version.

A third important parameter is the Diffe-Hellman (DH) group used. DH is a method of key exchange, since during the initial setup of a VPN, the VPN peers must exchange encryption keys. If these keys are captured by an outsider, the entire VPN can still be decrypted. DH solves this problem mathematically so peers can derive each others keys without sending them unmodified. The DH group means the length of the algorithm:

• DH Group 1: 768-bit group
• DH Group 2: 1024-bit group
• DH Group 5: 1536-bit group
• DH Group 7: 163 bits elliptical curve field

While most implementations simply ask the group, some ask for bit-length. Group 2 and 5 are used widely, and generally group 1 is not recommended because it’s suspected to be breakable in a reasonable amount of time with realistic computational power. DH Group 7 is a special one: it’s made for devices with low processing power, like PDAs. I couldn’t find any objective source claiming this encryption is better or worse than group 5, but most seem to agree it’s less secure.

Another important parameter is the mode used to connect: main mode or aggressive mode. Cisco also supports quick mode, see their site for a brief explanation. Quick mode is rarely used.

And last but not least: the timers. The VPN will renegotiate from time to time. Unlike the previous parameters, if these timers do not match on both ends, the VPN might come up, but will become unstable and disconnect from time to time.

Now that all important parameters are listed, one more thing: a VPN connection consists of two phases. Phase 1 is the initial setup of a secure tunnel, using a common encryption, hashing, renegotiation timer and DH group. Inside that secure tunnel, parameters for the actual encrypted tunnel for data are negotiated: again encryption, hashing, a timer and optionally a maximum data limit before renegotiation. This is Phase 2. Also optionally, during Phase 2, you can use ‘Perfect Forwarding Secrecy’ (PFS), which means Diffie-Hellman key exchange will be used again inside the secure tunnel.

Note  that the parameters (encryption, hashing, timers and optionally DH group) do not have to match between Phase 1 and Phase 2: you can use AES-256 SHA-2, DH group 5 for Phase 1, and a less resource-intensive 3DES MD5 DH group 2 for Phase 2, for example. Obviously, they have to match between the two connecting devices.

Edit 28/10/2012: looks like I forgot two important facts:
1) The Phase 2 also needs to list the traffic to encrypt, usually in a ‘from subnet x to subnet y’ form. Sometimes referred to as ‘encryption domain’.
2) How do the VPN peers actually exchange policy information? Through the exchange of IKE packets on UDP port 500, containing the Phase 1 information.

That concludes the theory. In the following articles, I’ll explain how to set up a VPN connection on different platforms. Stay tuned!

Using ACLs to mimic a firewall.

A stateful firewall should be considered a mandatory part of any network design. End user systems and the internet simply cannot be trusted, and even on servers there’s always the unexpected open port possibility. Going completely Cisco here for a moment, it’s an ASA, or a Zone-Based Firewall (ZBFW) configuration on an edge router.

But, usually due to budget constraints, it’s not always feasible to go and put firewalls everywhere in the network. While the WAN or internet edge should really have it, internally it can be less of a need. This is usually where access control lists (ACLs) come into play.

The example LAN above is completely internal. The switches are layer 2 access switches, the router depicted in the middle is a layer 3 switch acting as a default gateway for the VLANs.

Now let’s assume there’s a web server on 10.3.32.2 and a Voice server on 10.3.32.3. You want the following rules applied:

• From Clients access to the web server by http.
• From the IP Phones access to the Voice server using SIP protocol.
• Allow IP Phones to be pinged from the Voice server.
• Deny everything else.

On an ASA or any other stateful firewall, this would be a rule specified on VLAN 10, a rule for Voice on VLAN 20 and a rule for ICMP echo on VLAN 800. The stateful part would take care of the rest and automatically allow return traffic for existing connections. For TCP, it does so by checking the three-way handshake (SYN, SYN/ACK, ACK) and checking the connection breakdown (FIN and RST flags). For UDP, most stateful firewalls use a pseudo-stateful behaviour: the first UDP packet in a permitted rule will be set in the state table, with a time-out. Return traffic is accepted as long as the time-out isn’t reached. For each outgoing UDP packet part of the same stream, the timer is reset to zero. This is usually sufficient for connectionless communication.

ACLs however simply perform filtering and do not keep track of sessions. To do a ‘deny everything else’, both incoming and outgoing connections will have to be filtered properly with an ACL. A start would be this:

ip access-list extended VLAN10-IN
permit ip any host 10.3.32.2
ip access-list extended VLAN20-IN
permit ip any host 10.3.32.3
ip access-list extended VLAN30-IN
permit ip host 10.3.32.2 10.0.10.0 0.0.0.255
permit ip host 10.3.32.3 10.0.20.0 0.0.0.255

But the above access-list is very general and leaves a lot of security issues. To make it mimic a stateful firewall, add more details:

ip access-list extended VLAN10-IN
permit tcp 10.0.10.0 0.0.0.255 host 10.3.32.2 eq 80
ip access-list extended VLAN20-IN
permit udp 10.0.20.0 0.0.0.255 host 10.3.32.3 eq 5060
permit icmp 10.0.20.0 0.0.0.255 host 10.3.32.3 echo-reply
ip access-list extended VLAN30-IN
permit tcp host 10.3.32.2 eq 80 10.0.10.0 0.0.0.255 established
permit udp host 10.3.32.3 eq 5060 10.0.20.0 0.0.0.255
permit icmp host 10.3.32.3 10.0.20.0 0.0.0.255 echo

A breakdown of the above added parameters:

• Specifying a subnet with wildcard rather than just ‘any’, even if there’s just one subnet behind that interface, prevents IP spoofing. If just the return traffic is filtered on the subnet, this still allows for initial SYN packets, so SYN flooding from a spoofed IP is possible when ‘any’ is used.
• Always specify a destination port to prevent scanning of the servers and accidental (or malicious) connection to other services running on that server. Even if the server runs a software firewall: it shares the operating system with the services, who may open ports on this firewall.
• ICMP: specific definition of echo and echo-reply makes sure the server can ping the IP Phones, but not the other way around.
• In the return traffic, setting the source port to the service makes sure the server does not initiate connections, or in the case of UDP, starts a flow on a non-standard port. Since it’s not possible to use timers in the ACL based on outgoing connections, this way you can still do some filtering.
• For TCP, the ‘established’ keyword only allows packets that have the ACK bit set. The initial SYN used for the connection buildup is not allowed – Effectively preventing the server from initiating a connection himself. Instead, he has to listen for connections from the clients, where the ACK bit isn’t checked.

While this does not create a state table on the switch or router, it really narrows down the attack surface. Connections cannot be initiated where you don’t want it, packets must go to and originate from ports you decide. The biggest security problem is that UDP packets or TCP packets with ACK already set can be used to flood the links, but even then only from certain ports. And, compared to a stateful firewall, this configuration is more complex, because with each rule change, you have to completely understand the flow, and also adapt the ACL for the return traffic.

Dynamic Trunk Protocol: Wireshark research.

Time to review something that has been very unclear to me from the beginning: Dynamic Trunking Protocol. First off, it’s a Cisco-only protocol, and let’s be honest, it has no real world uses except acting as a security risk. Second: most literature about it is in fact quite unclear, except the CCIE OCG so far, but even then I’m left with question marks.

So let’s go through the theory first, as this is usually the best way to start:

• DTP sends special frames out of every switchport by default, which can be used to negotiate a trunk link, and negotiate the encapsulation (802.1q or Cisco-proprietary ISL).
• The frames can either be ‘auto’, ‘desirable’, or ‘on’. While ‘desirable’ and ‘on’ actively try to negotiate a trunk, ‘auto’ only negotiates one when the other end is set to trunking.
• The ‘switchport nonegotiate’ command prevents DTP frames from being sent.

Now, let’s see how it goes in practice.

Commands without effect
It’s never mentioned explicitly in any literature I’ve encountered so far, so I tested it just to be sure. The commands ‘switchport access vlan number‘ and ‘switchport trunk allowed vlan numbers‘ do not have any effect on DTP at all. Should the port become an access port, then the ‘switchport access’ command is used to define the VLAN, and the trunk allowed list is ignored. Should the port become a trunk, the trunk allowed list is used and the access VLAN is ignored. Same for ‘switchport trunk native vlan number‘, which is only used should the port become a trunk.

Default configuration
The default configuration of a Cisco switch is to send out DTP auto frames. This means no trunk link will be formed unless configured to do so. And here’s the security risk: if you leave a port in it’s default configuration, someone sending a DTP desirable frame can form a trunk and gain access to all VLANs. In case you’re thinking ‘Oh, this is highly theoretical’: it took me less than 30 minutes to find, download and install Yersinia on a Linux VM and send DTP frames to my home lab switch.

Commands with effect, and their changes
So what actually influences DTP? Two commands, it seems: ‘switchport mode’, and ‘switchport nonegotiate’. I’m listing my findings below, after trying all possible combinations on a switch:

• Default configuration: DTP sends two frames every 30 seconds (a timer that can’t be changed): one untagged frame, one ISL encapsulated frame. Both are DTP ‘auto’ mode (status code 0x03). Since ISL has no concept of native VLAN and some (older) switches only support ISL, sending the second ISL frame makes sense for compatibility reasons. DTP also sends a DTP Type, which is a HEX code listing the supported encapsulation methods.
• ‘switchport mode access’: no DTP frames are sent. At all. The ‘switchport nonegotiate’ does not make any difference.
• ‘switchport mode trunk’: DTP frames are sent in mode ‘on’, with a status code of 0x81. Since you have to choose either ISL or 802.1q as an encapsulation method before you can make the port a trunk, DTP sends this parameter too: 0xa5 for 802.1q and 0x42 for ISL. Also, independent of the encapsulation chosen, DTP will again send two frames: one untagged, one ISL encapsulated.
  Note that this port will operate in trunk mode regardless of what the other end decides. The frames are sent to help the other end in negotiation and choosing the right encapsulation. A port with default configuration will convert to a trunk port when receiving these DTP frames.
  Using ‘switchport nonegotiate’ here stops the sending of DTP frames. Should this port connect to a port with default configuration now, it will still be a trunk, but the other and will stay an access port.
• ‘switchport mode dynamic auto’: this is the default configuration and this line will not even show in the running config.
• ‘switchport mode dynamic desirable’: again like the default configuration, the only difference being status code 0x04, and a trunk will actively form when a port running DTP is connected (no matter the other end’s DTP mode).

Another unexpected command which has effect is the ‘vtp domain name‘: I’ve researched that before.

Practical implications
So what’s best in practice to counter any unexpected behavior, and security risks?
In case of an access port, ‘switchport mode access’ is effective enough as it shuts down DTP on a port. ‘switchport nonegotiate’ is a redundant command, so it doesn’t matter whether it’s applied or not. Just defining ‘switchport access vlan number‘ without the matching ‘switchport mode access’ is a security risk.
In case of a trunk port, I would still recommend disabling DTP, so a static configuration with ‘switchport nonegotiate’ becomes mandatory.
And what if DTP somehow is required to run, can the risk be minimized? (This is theory, if someone requires DTP, you… try to stay calm.) Yes: ‘switchport trunk allowed vlan numbers‘ can be configured to only allow access to the default access VLAN, or even set to ‘none’. This command doesn’t become effective until a trunk is negotiated.
Last, the Nexus series doesn’t run DTP at all, which I personally regard as a huge plus.

So that’s my in-dept research. Probably nothing I will really need in real life, but good to know for the security consequences, as well as some more knowledge for the next certification.

IPv6 RA Guard feature.

As promised an IPv6 post! The Cisco IPv6 workshop was a real eye-opener for me, with plenty of configuration examples, best-practices and highlighting important security issues. Something that had been lingering on my mind for some time was the fact that, in my IPv6 experiments so far, any device could send out a Router Advertisement (RA) if it wanted to, and it would automatically become the gateway for the subnet. No questions asked. Since I’m running my IPv6 router and tunnel on a virtual machine using 50 MB RAM, I became increasingly worried about the simplicity of a possible man-in-the-middle attack. Just set up a VM in a campus LAN, make it send out RAs, and capture all traffic. IPv6 is even preferred above IPv4 when a modern OS has the choice. That’s a big security hole which is hard to detect.

Turns out, when I asked my question, that Cisco had an answer ready for me: RA Guard, which works similar to DHCP Snooping for IPv4. RA Guard filters out any ICMPv6 type 134 messages (RA) coming from any port that is marked as untrusted. For the moment it seems to be available on Catalyst 6500 Series only, since software release 12.2(33)SXI4. A full configuration guide for various IPv6 security measures can be found on the Cisco website.

I was told that support for other platforms would eventually be possible. For now, a workaround exists using IPv6 access lists, but this was not recommended I was told, as this would be done in software, not in hardware. Nevertheless, since the issue exists in a present day network already, I tried configuring it.

Here’s the configuration, which uses a Port ACL:

WS-C3560-8PC#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
WS-C3560-8PC(config)#ipv6 access-list RA-GUARD
WS-C3560-8PC(config-ipv6-acl)#sequence 3 deny icmp any any router-advertisement
WS-C3560-8PC(config-ipv6-acl)#sequence 6 permit ipv6 any any
WS-C3560-8PC(config-ipv6-acl)#exit
WS-C3560-8PC(config)#interface FastEthernet0/5
WS-C3560-8PC(config-if)#ipv6 traffic-filter RA-GUARD in
WS-C3560-8PC#show ipv6 access-list
IPv6 access list RA-GUARD
deny icmp any any  router-advertisement sequence 3
permit ipv6 any any (24 matches) sequence 6

Quite simple and it turns out it works. FastEthernet0/5 had an IPv6 router behind it, sending RAs every 60 seconds. Strange fact: all IPv6 traffic was matched against the permit ACL as expected, but the RAs weren’t matched against the deny statement, nor the permit statement. No logging to be found, though the switch did drop them. My computers did not detect any IPv6 router. Disabling the traffic-filter and waiting a minute made the clients configure an automatic IPv6 address.

Unfortunately, I couldn’t do any throughput tests, so I can’t tell what the impact on CPU is, but if rogue RAs are really an issue in the network, it might be worth the increased CPU.

ASA part II: basic set-up and firewalling.

It’s been a while since I’ve posted anything since I’ve been very busy with lots of personal things.  Until a few days ago, when I needed to set up an ASA urgently as a stateful firewall to protect a web server. The perfect basic setup, but still a challenge for someone inexperienced. So below some brief notes to get an ASA going with basic firewall functionality.

First step: basic configuration of the interfaces. The ASA5505 interfaces work somewhat like a layer 3 switch, with VLAN interfaces and switchports, that can be configured in access, trunk or routed interface mode. Other ASA models work more like a router, with layer 3 interfaces, and subinterfaces for trunk link behavior.
In this example, the first interface on my ASA5505 will become a routed interface for out-of-band access in a 10.0.3.0/24 subnet, the second interface will also be routed and become the external connection with IP 20.30.40.50 (ISP gateway 20.30.40.1), and the remaining interfaces will be switchports part of VLAN 5 with subnet 192.168.3.0/24 as the internal network.

ASA5505#configure terminal
ASA5505(config)#interface Ethernet0/0
ASA5505(config-if)#no switchport
ASA5505(config-if)#ip address 10.0.3.2 255.255.255.0
ASA5505(config-if)#description Management
ASA5505(config-if)#nameif MGMT
ASA5505(config-if)#security-level 100
ASA5505(config-if)#management-only
ASA5505(config-if)#exit
ASA5505(config)#interface Ethernet0/1
ASA5505(config-if)#no switchport
ASA5505(config-if)#ip address 20.30.40.50 255.255.255.0
ASA5505(config-if)#description ISP
ASA5505(config-if)#nameif External
ASA5505(config-if)#security-level 0
ASA5505(config-if)#exit
ASA5505(config)#interface Vlan 5
ASA5505(config-if)#ip address 192.168.3.1 255.255.255.0
ASA5505(config-if)#nameif Internal
ASA5505(config-if)#security-level 50
ASA5505(config-if)#exit
ASA5505(config)#interface range Ethernet0/2 – 7
ASA5505(config-if)#switchport mode access
ASA5505(config-if)#switchport access vlan 5
ASA5505(config-if)#exit

Some explanations here: the ‘nameif’ gives the interface an actual name that can be seen in ASDM and worked with for all firewall rules to come. The security-level is used by the ASA to determine which interface is considered a safe-zone, and which one is not. By default, traffic from safer interfaces (higher security-level) can flow to less secure interfaces, but not the other way around (except for the return packets of stateful connections). Equal security-level interfaces can’t pass traffic between each other by default, but this option can be toggled in the ASDM, or by the ‘same-security-traffic permit inter-interface’ command. Also, the ‘management-only’ command on the management interface prevents that interface from being part of the routing, so no packets from and to any other interface can be passed through this interface.

Next is setting up a local user account for SSH and ASDM access, as well as an enable password. Consider this mandatory for any ASA.

ASA5505(config)#user reggle privilege 15 password ********
ASA5505(config)#enable password ********
ASA5505(config)#aaa authentication ssh console LOCAL
ASA5505(config)#ssh 0.0.0.0 0.0.0.0 MGMT
ASA5505(config)#http server enable
ASA5505(config)#http 0.0.0.0 0.0.0.0 MGMT
ASA5505(config)#asdm image disk0:/asdm-645-206.bin

Again more explanation: the third line makes sure the local username database is used when trying to log in on SSH. RADIUS and TACACS+ are also possible of course, but I’m not going to cover that here. The fourth and sixth line define who may connect to SSH and ASDM, respectively. In this case I allow access from any IP (0.0.0.0/0), but only on the Management interface, which is defined by the nameif configured earlier. You can add multiple lines with multiple subnets and interfaces, but this is a basic example.

The last line is also required or ASDM will not work. It defines where on the local system the ASDM installation file is located. The file has to be present! The version may differ of course and can be downloaded on the Cisco website. The positive side of this is that once all of this is configured, you can connect to the ASA with your browser and it will provide you with a download link for ASDM if you don’t have it installed already. This can save you a lot of searching when you urgently need to log in from a computer that doesn’t have this installed yet. Note that ASDM does require a modern 32-bit Java to function, even on 64-bit operating systems.
The last thing I do in the console after this is setting up basic static routing: a  default route towards the internet on the External interface. The Management interface is a bit trickier and I haven’t worked that one out yet: everything in the local 10.0.3.2 subnet can connect, but I haven’t tested if setting a default route for the Management interface actually works, so I’m not going to define one here.

ASA5505(config)#route External 0.0.0.0 0.0.0.0 20.30.40.1

That’s the end of the console part. For firewalling and NAT, I prefer the ASDM now. Logging in is done by surfing to https://10.0.3.2 and giving the username and password configured earlier. It’s an easy to understand interface. First NAT, which you can find under ‘Configuration’ in the menu above, then ‘Firewall’ on the left, and finally ‘NAT rules’, also on the left. There you can add new rules on the interfaces.

In the NAT rule menu, you can add objects (which you can create there too) that must be translated. For example, a dynamic or hide NAT of the 192.168.3.0/24 network behind the address of the External interface, 20.30.40.50. Static NAT rules for servers are also possible and you can NAT those behind addresses not configured on any interface, for example if you’ve received a range to use from your provider or own an IP range. In the last case, make sure routing (likely BGP for your own IP range) is pointing towards the ASA for the IP’s you’re going to use.

When your changes are done, you can click apply on the bottom of the screen to push the configuration towards the ASA. The ‘Save’ button on top of the screen acts the same as ‘copy run start’.
Next, under ‘Access rules’ on the left you can define the actual firewall rules. Again the same simple interface to add objects in rules, source, destination, ports, time frames,… I’m not going to explain in detail, it’s easy to experiment with should you have the chance to do so. A few points to keep in mind though:

• The rules are examined top-down. So if the first rule denies something, even a dozen allow rules after that will not change the decision.
• Top-down means it takes CPU to match something on the bottom of a long rule list. Luckily, the ASA shows the number of hits on each rule in the ASDM, so you can place the most-used rules on top of the rule list to reduce CPU load.
• When defining an object, use netmask 255.255.255.255 to define a single IP.
• If you’re using NAT on an external interface, don’t define any rule on that interface with the internal IP address of a NAT rule. It will of course not match any incoming packet.
• I’m very fond of how easy the ASDM interface is, but keep in mind this is a GUI which pushes configuration towards a device. This push action can be interrupted, which may result in missing rules or configurations. So for larger configurations, it can’t hurt to push ‘Apply’ twice from time to time.

This configures a basic ASA firewall. Biggest challenge after the configuration: connecting the cables correctly!

ASA part I: introduction.

And yet again I got the chance to test a device at home. This time: a Cisco ASA5505. ASA stands for Adaptive Security Appliance, and this branch of devices specializes in security features, such as NAT, stateful firewalling, IPS, and VPN. It supports site-to-site VPN, client-based VPN, SSL VPN,… Strangely enough, no support for DMVPN yet. The full product list can be seen here.

The ASA5505 is the smallest in the series, and the only one which does not come as a rack-mountable unit. It does have almost the same functionality as the other models: difference between models is in throughput, processing power and number of concurrent VPN sessions mostly. Port count starts with 0, and ports 6 and 7 support PoE.

The lower models ASA’s (5505 and 5510) come with a differentiated licences model, which can be checked here. Basically, the license costs more depending on the number of users, where users means the number of IP’s or devices. The one I’m testing has a Security Plus license, which is the highest for the model, with unlimited users and full functionality. Keep in mind that not everything I’m going to explain in the upcoming series of ASA posts may work on a lower license.

An ASA handles quite differently compared to a standard Cisco IOS. ASA runs a custom Linux/Unix version as operating software (so do the Cisco Nexus series), and commands differ. ‘show ip route’ is ‘show route’, ‘show ip interfaces brief’ is ‘show ip’, for example. Also, you can connect Adaptive Security Device Manager, or ASDM, to it to configure the ASA in a GUI. Given the complex possibilities of the device, this is quite handy, although the (Java-based) ASDM tool does contain a few minor bugs and in some configurations creates extra rules in the background, that can be seen from the command-line, but not in the ASDM.

For firewalling, it allows a lot of options with a modern software release: rules are defined with objects. Those objects can be source addresses or networks, destination addresses or networks, destination ports or port groups (both UDP and TCP), and time frames. All these rules can be defined in both IPv4 and IPv6. They also show the number of hits, so you can see which rules are used and which ones aren’t. Optionally you can use this feature to move the most-used rules to the top to reduce CPU load (rules are examined in the order they are listed).

In upcoming blog posts, I’m going to describe basic ASA functions, so stay tuned!

Different types of VPN explained.

Since I’m going to talk more about VPNs in the upcoming weeks, I’m going to explain the different types of VPN here. No configuration guides, but an explanation so it’s clear what is what.

For those who aren’t sure what a VPN is: a Virtual Private Network is an encrypted connection between two or more devices over a public network. Some may argue that it doesn’t necessarily has to be encrypted, but when it’s not, that’s called a tunnel (for me at least). Here’s a list of the types:

Site-to-site VPN
Often abbreviated to S2SVPN. It’s a connection between two sites and encrypts all traffic between two (or multiple) subnets. There are two types of S2SVPN:

• Policy-based: interesting traffic triggers an ACL and is encrypted and sent to the remote VPN peer.
• Routed: traffic is routed into an encrypted tunnel to the remote VPN peer.

For a detailed explanation and configuration, Jeremy made some excellent posts about this on Packetlife: Part 1 for policy-based and Part 2 for routed.

DMVPN
A dynamic multipoint VPN is not a protocol but more a technique using different protocols. One or more central hub routers are required, but the remote (spoke) routers can have dynamic IPs and more can be added without having to modify the configuration on the hub router(s), or any other spoke routers. The routers use a next-hop resolution protocol, combined with a dynamic routing protocol to discover remote peers and subnets. The VPN itself is a mGRE tunnel (GRE with multiple endpoints) which is encrypted. This way, traffic between spoke routers does not have to go through the hub router but can be sent directly from spoke to spoke.

Client VPN
A client VPN is an encrypted connection from one device towards a VPN router. It makes that one remote device appear as a member of a local subnet behind the VPN router. Traffic is tunneled from the device (usually a computer or laptop of a teleworker) towards the VPN router so that user has access to resources inside the company. It requires client software that needs to be installed and configured.

SSLVPN
This type of VPN works like a client VPN. The difference is that the remote client does not need preconfigured software, but instead the browser acts as VPN software. The browser needs to support active content, which every modern browser supports, either directly or through a plug-in. Traffic is tunneled over SSL (or TLS) to the SSLVPN router. From a networking perspective, traffic is tunneled over layer 4 instead of layer 3. The benefit is that the remote user does not need to configure anything and can simply log in to a web page to start the tunnel. The drawback that you’ll likely need a dedicated device as SSLVPN endpoint because this is not a standard feature.