Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Router to Router SSL VPN

    Is it possible?

i would like a hub and dynamic spoke SSL enviroment.                   

Everyone's tags (4)
Cisco Employee

Router to Router SSL VPN

It's not possible on Cisco devices. SSL VPN is purely remote access technology.

What's the reason behind asking - IPsec should be good enough for this scenario.

New Member

Router to Router SSL VPN

SSL has lower overhead.

Cisco Employee

Router to Router SSL VPN

In which sense?

IPsec related calculation should be done by hardware engines each ISR/ASR routers has built in (unlike most SSL clients).

Packet overhead - how much will you gain? (Literature?)


New Member

Re: Router to Router SSL VPN

About IPSec VPN for IPv4 overhead please check

Comparing, Designing, and Deploying VPNs

Chapter 7. Scaling and Optimizing IPsec VPNs

MTU and Fragmentation Considerations in an IPsec VPN

Table 7-2. IPsec VPN Packet Sizes

shows the overhead  added when using AH and/or ESP (in tunnel and transport modes) and a variety of  cryptographic algorithms to a user packet size of 1500 bytes sent over an IPsec  or GRE/IPsec VPN tunnel.

New Member

Router to Router SSL VPN

My understanding is that IPSEC uses 50-57 where as SSL only adds 5.

Cisco Employee

Router to Router SSL VPN

Hey Martin,

Let me try to answer completely your question.

1. Overhead standpoint

SSL indeed has an header of 5 bytes. However it's not only that.

  • TCP Header (20 bytes)
  • The header (5 bytes)
  • The sequence number (DTLS only) (8 bytes)
  • The IV (8-16 bytes)
  • The MAC (10-20 bytes)
  • Padding (CBC mode only, 1-16 bytes)

----> In fact, SSL and IPSEC overhead avec very comparable....

2. Security:

From Security standpoint, IPSEC is better suited than SSL/TLS.

  • IPSEC always use a Diffie Helman exchange to generate keyeing material. [More info at].
    In that way, as long you use AES as encryption mechanism, there is no ways of decrypting the traffic by brute force even over billions years.

  • With SSL/TLS for instance, the usual method to generate the crypto keying material is the following:

    |"In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key." From the random number, both parties generate key material for encryption and decryption. More info at

So, in order words, if someone get access to the RSA private key [ most likely if you get physical access to the device ], then the encrypted traffic can be easily decrypted [ offline - instantaneous].

I hope this answer your initial question.