David Ramsden
29Mar/16

Cisco two armed VPN concentrator and default route

Take the following scenario:

  • You have a hub site.
  • Branch (spoke) sites connect to the hub with a L2L IPsec tunnel.
  • All traffic must traverse the tunnel (no local breakout to the Internet).
  • At the hub, your VPN concentrator is separate from your firewall and runs in two armed mode. Where one interface is outside the firewall (public) to terminate the incoming tunnels and another interface is within a DMZ. As such no NAT is configured since the firewall will be doing this, routing and filtering traffic.

The VPN concentrator will have its default gateway pointing out of the public interface. This becomes a problem when you're tunnelling all traffic from the spokes over the L2L tunnel, especially for traffic destined to the Internet which should go via the hub site's central firewall.

On a Cisco ASA two default gateways can be specified. One for non-tunneled traffic and one for traffic exiting from a tunnel.

In the example above, any traffic exiting from a tunnel on the inside interface and not matching another route, will be routed towards 192.168.0.1. Without this the traffic would be routed towards 111.222.333.444.

If a device running IOS is being used the same can be achieved using a route-map to match the traffic exiting the tunnel and then setting the next hop IP.

 

Tagged as: , , No Comments
13Oct/14

Cisco Crypto ACLs – Do they really need to match?

When starting out with IPsec tunnels it seems to be a common misconception that the crypto ACL, sometimes referred to as the encryption domain or the interesting traffic, must match 100% or be mirrored at both peers or the tunnel won't come up. This isn't strictly true. Whilst the ISAKMP phase 1 and IPsec phase 2 proposals must match, the crypto ACL can be different.

Assume that at the local peer traffic to be encrypted originates from 10.0.0.0/24 and is destined for 192.168.0.0/24. The crypto ACL would be:

But what about the following?

IPsec phase 2 can still be established even though the crypto ACL isn't mirrored at the local and remove peer. The local peer specifies 10.0.0.0/24 but the remote peer specifies 10.0.0.0/8. In this scenario IPsec phase 2 can only be initiated from the peer that has the larger subnet. This is true for both Cisco ASA and IOS.

And in the example above, in the local peer's ACL there's a deny ACE but none on the remote peer's ACL. In this scenario any traffic originating on the local peer from 10.0.0.0/24 destined to 192.168.0.200/32 won't traverse the tunnel. The device (ASA or IOS router) will look at the next crypto map in the sequence and try to match traffic there. If no crypto maps are found it'll flow unencrypted out of the egress interface.

Obviously be careful with mismatching subnets and using deny ACEs in the crypto ACL because you may end up with traffic trying to enter the wrong tunnel and other strange things happening.

 

Tagged as: , , , , , , No Comments
9Sep/14

Reviewing Cisco ASA firewall rules

Today I was reviewing a firewall rule set on a Cisco ASA firewall. The firewall has around 399 ACLs (Access Control Lists) comprising of 7272 ACEs (Access Control Entries). Quite a task! Unfortunately I didn't have any tools to hand such as Cisco Security Manager or something like FirePac to audit the rules and give me some suggestions.

Stage 1 was to visually look at the ACLs and spot the obvious mistakes and remove them. Stage 2 was to then remove any unused names, objects and object-groups. I hacked up a Perl script to do this. The script reads the complete ASA config, gets all the names, objects and object-groups then works out which ones aren't referenced anywhere else:

Stage 3 was to work out which ACLs could be completely removed and which ACLs should be reviewed in more detail. If an ACL with or without ACEs, has a total of 0 hits it can (probably) be removed. If an ACL with ACEs has less than or equal to 100 hits it should be reviewed in more detail because the chances are some of the ACEs associated with it can be removed. A quick and dirty Perl script did the trick:

I found 181 ACLs that can be immediately removed and a further 16 to be reviewed. With an average of 18 ACEs per ACL, that equates to 3258 ACEs that can removed and 288 that may be able to be removed after a review.

By the end of this journey I should have reduce the rule set by at least 44.80%. After that the rule set just needs re-ordering to optimise the processing.

Tagged as: , , , , , 8 Comments