IPSEC tunnels with CBAC

[mpdavies]

Hello

I have a hub IOS router with CBAC enabled and ipsec tunnels coming in from spoke LANs over the internet.

The only way I have been able to get this working correctly is to allow the spoke private address ranges through the outside interface inbound access-list of the hub router, together with esp and isakmp from the remote vpn endpoint.

Otherwise traffic does not travel from spoke LAN to hub LAN.

eg : (hub router config)

access-list 110 permit ip 10.0.0.0 0.0.15.255 10.2.128.0 0.0.15.255

access-list 110 permit esp host 192.158.45.52 host 84.252.36.65

access-list 110 permit udp host 192.158.45.52 host 84.252.36.65 eq isakmp

10.0.0.0 / 20 = PRIVATE address range, spoke LAN.

10.2.128.0 / 20 = PRIVATE address range hub LAN.

192.158.45.52 = outside interface, spoke router.

84.252.36.65 = outside interface, hub router.

I apply this access-list inbound, to the outside interface of my router.

The second and third lines of the access-list permit esp and isakmp, but it will not work unless I have the first line also, which defines traffic from the spoke internal network to the nub internal network address range.

Allowing these PRIVATE address ranges through to my internal network appears to be a security hole.

Is there any way I can allow the encrypted traffic through but not allow the private address range. ?

[jasobrown]

I still think that this is the only way to allow the traffic thru. The routers dont have a command as in the pix "sysopt connection permit-ipsec". IMHO this is the better way to go using the ACL on the inbound interface because you can limit what traffic is coming in.

As far as this being a security hole. If someone were to spoof these private addresses the router will do a check on the traffic and see that it is supposed to be encrypted via the crypto map therefore if it is not encrypted then the traffic will just be dropped.

[nihal.akbulut]

hi,

I have the same problem, that's a bug with ID CSCdz54626. from bug toolkit:

Symptoms:

An inbound access control list (ACL) for incoming IP Security (IPSec) is

evaluated twice. The ACL is inspected once for the encapsulated IPSec packet

and then once more after the IPSec packet is decapsulated. Because the inbound

ACL is configured to allow only IPSec traffic such as Internet Security

Association and Key Management Protocol (ISAKMP) or Encapsulating Security

Payload (ESP), decapsulated clear packets will be dropped when the ACL

is processed the second time.

Conditions:

This symptom is observed on a Cisco router if the

access-group acl_ID command is configured

on the interface that terminates IPSec traffic.

Workaround:

Permit internal networks on the ACL.

Security Impact Of The Workaround:

The workaround suggested here does cause administrative overhead to the

configuration, there is no significant security impact.

Permitting internal networks in the inbound ACL may be exploited to inject

spoofed packets into the network. However this has no practical impact while

using static crypto maps. With static crypto maps, the unencrypted traffic will

be dropped even if it passes the inbound ACL.

In the case of dynamic crypto maps, it might be possible to inject spoofed

packets if there is no "match address" statement in the crypto-map. An attacker

would also require control of the neighboring routers that are connected to the

interface where the inbound ACL is applied, or the medium in between the

neighbors.

If "match address" statement is present in the crypto-map it is *not* possible

to inject spoofed packets into the network by exploiting the suggested

workaround.

[mpdavies]

Thanks very much guys.

I am aware of the 'sysopt permit ipsec' command on the PIX, but of course there is no such command on the ios router.

It's reassuring to hear that I am configuring the thing correctly although it seems a bit weird that that the access-list is applied twice.

Martin