ASA L2L VPN design question

[fsebera]

We plan to have more than 10,000 remote L2L VPN clients.

I see that each crypto map needs a "set peer" statement and the IP address is the address of the remote L2L VPN peer.

:

EX:

crypto map UNI-POP 3 set peer 172.23.0.3

: . . .

crypto map UNI-POP 10000 set peer 172.26.0.250

:

I already feel this is going to a VERY long config, perhaps too large to save/read to/from memory.

:

Could anyone provide a better approach?

Thanks

Frank

[Marcin Latosiewicz]

Frank,

You need "set peer" only in case of INITIATING traffic.

In such a scenario (10k peers... WOW!) I would suggest going to reply-only and using certificates and only setting peer for specific peers you NEED to intiiate.

Otherwise your configuration will blow up in lenght.

Marcin

[fsebera]

Hi Marcin,

The remote peers (L2L VPN) will be mobile clients utilizing a non-Cisco 3G/4G cell modem (at this point the decision to use non-Cisco is hard set as Cisco has discontinued their 881G series routers).

The only time the VPN will be operational is when the remote users power on their equipment so the remote peers must initiate the VPN session with the HQ site ASA firewall.

:

Non-Cisco device does not support certs - yet.

:

Since each remote L2L VPN peer requires a "crypto map set peer statement" then we need to probably have multiple firewalls even through the ASA8500 supports 10,000 VPN sessions.

:

Thanks for your insight!

Frank

[Marcin Latosiewicz · Accepted solution]

Frank,

If the remote ends will run only from time to time, you should not need the set peer statments and normally it would be enought to have one dynamic crypto map.

If the remote ends do not support certificates, there is a possibility to land on defaultl2l  tunnel-group.

bsns-asa5505-19# sh run all tunnel-group
tunnel-group DefaultL2LGroup type ipsec-l2l
tunnel-group DefaultL2LGroup general-attributes
(...)

You'd need to test it yourself to see if it will work.

I also agree in terms of multiple firewalls. Having two devices in load-balancing or if possible 2pairs of devices in failover cluster could be great way to have a decent load per machine and hardware redundancy (ideal circumstances ;]). I suggest to ping your SE for sure any deployment involving 5585, the guys can usually give good tips (and discounts ;]).

Marcin

[fsebera]

Hi Marcin,

Not to beat a dead horse to double death but just wanted to clarify. :}

If I don't specify the peers by IP address and just use the default TUNNEL-GROUP option, how can I be certain the ASA firewall only accepts connections from known good and safe remote clients?

If I use the default TUNNEL-GROUP option, is the pre-shared key the only security feature required to make a secure connection?

Regards

Frank

[Marcin Latosiewicz]

Frank,

Indeed it might not be super secure, a complicated PSK should be enough. In fact that's why I thought certificates would be GREAT for this solution, but not applicable on 3rd party devices as you said.

What I would do is to add cut-through-proxy on the ASA to authenticate remote users, it makes sense if those remote users will be employees with an AD/LDAP/RADIUS account on HQ side.

So even if your PSK is for some reason stolen (note that IOS for example offers PSK encryption), the remote uses would still need to steal an account on your authentication server.

Marcin

[fsebera]

Marcin,

:

I like the idea of external authentication as the 3rd party device only supports PSK of A-Z and 0-9. Learned yesterday that no other characters are supported and of course the max number of characters is limited.

:

Yea I like the PSK encryption on IOS but discovered it is NOT transferable from box to box. once implemented, If you forget the key, you must assign a new key to both ends. I.E. write erase reload or config a new IOS box, paste in archived config from text file (notepad), encrypted PSK will be invalid.

:

Another issue with our 3rd party devices, the remote user will not have to log into the device to enable the  IPsec VPN tunnel, they only have to power it on. Authentication is performed at the next device out.

:

Anyway, I feel you have more than answered my questions so I will click on the correct answers for you!!!

:

In summary, if someone doesn't need the highest level of security for L2L VPN, a single generic TUNNEL-GROUP will suffice (use the DefaultL2Lgroup type l2l-IPsec). To step security up a notch you could enable external authentication and/or implement a different TUNNEL-GROUP for each single user or a sub-set of users. Stepping security up another level would be to implement PKI.

Thanks again

Frank

[fsebera]

This is just an update (follow up) to your last message (just in-case someone is following this thread and wonders about cut-through-proxy).

Cut-through-proxy on the Cisco ASA only supports protocols FTP, HTTP, HTTPS, and Telnet.

Normally cut-through-proxy is used when the destination server cannot provide authentication. When a client needs to communicate with a server on a different ASA interface and the server doesn't or cannot provide any type of authentication or insufficient authentication, one could setup the ASA to support cut-through-proxy for that FTP, HTTP, HTTPS and/or Telnet server.

Keep in mind, I did not setup this feature on my ASA firewall as my issue deals with L2L VPN.

Regards

Frank