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