VPN-SIP uses IPSec Static Virtual Tunnel Interface (SVTI). IPSec SVTI stays in active (UP) state even when there is no IPSec security association (SA) established between the tunnel interface and the SVTI peer.

The following are three components for the VPN-SIP Solution:

• SIP

• VPN-SIP

• Crypto (IP Security (IPsec), Internet Key Exchange (IKE), Tunnel Protection (TP), Public Key Infrastructure (PKI) modules within crypto)

SIP is used as a name resolution mechanism to initiate an IKE session. VPN-SIP uses SIP service to establish a VPN connection to a home or a small business router that does not have a fixed IP address. This connection is achieved using self-signed certificates or pre-shared keys. SIP negotiates the use of IKE for media sessions in the Session Description Protocol (SDP) offer-and-answer model.

SIP is statically configured. One tunnel interface must be configured for each remote SIP number.

SIP also provides billing capabilities for service providers to charge customers based on the SIP number, for using the VPN-SIP service. Billing based on SIP numbers happens in the service provider network and is independent of the end devices like Cisco VPN-SIP routers.

VPN-SIP is the central block that coordinates between SIP and Crypto modules, and provides an abstraction between them.

When traffic destined to a remote network behind a SIP number is routed to the tunnel interface, the IPSec control plane gets a trigger from packet switching path as there is no IPSEC SA configured to that peer. IPsec control plane passes the trigger to VPN-SIP as the tunnel is configured for VPN-SIP.

Note	Static routes for remote networks for that SIP number must be configured to point to that tunnel interface.

When the VPN-SIP service is triggered, SIP sets up the call with a SIP phone number pair. SIP also passes incoming call details to the VPN-SIP and negotiates IKE media sessions using local address and fingerprint information of the local self-signed certificate or pre-shared key. SIP also passes remote address and fingerprint information to VPN-SIP.

The VPN-SIP service listens to tunnel status updates and invokes SIP to tear down the SIP session. The VPN-SIP service also provides a means to display current and active sessions.

The following steps summarize how the VPN-SIP feature works:

• IP SLA monitors the primary link using route tracking. When the primary link fails IP SLA detects this failure.

• Once the primary path fails, IP SLA switches the default route to the higher metric route that is configured on the router.

• When relevant traffic tries to flow using the secondary link, SIP sends an invite message to the SIP server to obtain the VPN peer information.

• The router receives the VPN peer information (IP address, local and remote SIP numbers, IKE port, and finger print) and it establishes VPN-SIP tunnel.

• When the primary path comes back up, IP SLA detects the primary path and the route falls back to the original path. When the idle timer expires, IPSec is torn down and a SIP call is disconnected.

Following is the topology for the VPN-SIP solution:

The SIP call flow is divided into initiation at the local peer and call receipt at the remote peer.

At SIP Call Intitiation

When packets are routed to an SVTI interface in data plane, the SIP call must be placed to the peer SIP number to resolve its address, so that VPN tunnel can be brought up.

• When local auth-type is PSK, IKEv2 finds the matching key for a peer SIP number. The IKEv2 keyring must be configured with id_key_id type (string) as SIP number for each SIP peer. IKEv2 computes the fingerprint of the looked-up key and passes it to VPN-SIP.

• When local auth-type is a self-signed certificate or an third-party certificate, IKEv2 computes the fingerprint of the local certificate configured under the IKEv2 profile and passes it to the VPN-SIP

The VPN-SIP module interacts with SIP to setup SIP call to the peer. When the call is successful, VPN-SIP sets the tunnel destination of SVTI to the resolved IP address, requesting SVTI to initiate the VPN tunnel.

Note	When a wildcard key is required, use the authentication local pre-share key command and the authentication remote pre-share key command in IKEv2 profile.

When SIP call is received at the remote peer

When a SIP call is received from a peer, following interactions occur between various crypto modules:

• The Tunnel Protection helps VPN-SIP module to set tunnel destination address.

• IKEv2 returns local auth-type (PSK or PKI) and local fingerprint to the VPN-SIP module. When local auth-type is PSK, IKEv2 finds a matching key for a corresponding SIP number.

Note	IKEv2 only knows peer by its SIP number.

During the SIP call negotiation between peers, each peer must select a unique local IKEv2 port number to be exchanged over the SDP. To support different port numbers for each session, the VPN-SIP module programmatically configures IP Port Address Translation (PAT) to translate between IKEv2 port (4500) and the port number exchanged over SDP. For the translation to work IP NAT must be configured on secondary link and the loopback interface configured as the VPN-SIP tunnel source. The lifetime of the translation is limited to the lifetime of the VPN-SIP session.

offer SDP
      ...
      m=application 50001 udp ike-esp-udpencap
      c=IN IP4 10.6.6.49
      a=ike-setup:active
      a=fingerprint:SHA-1 \
      b=AS:512
      4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
      ...

   answer SDP
      ...
      m=application 50002 udp ike-esp-udpencap
      c=IN IP4 10.6.6.50
      a=ike-setup:passive
      a=fingerprint:SHA-1 \
      b=AS:512
      D2:9F:6F:1E:CD:D3:09:E8:70:65:1A:51:7C:9D:30:4F:21:E4:4A:8E

Following is the process for IKEv2 Security Session (SA) negotiation:

• Before starting the session, IKEv2 checks with VPN-SIP if the session is a VPN-SIP session.

• If it’s a VPN-SIP session and local auth-type is PSK, IKEv2 looks up the PSK key pair using SIP number of the peer instead of IP address of the peer.

• For validating self-signed certificate, IKEv2 checks if the certificate is self-signed and validates the certificate.

  • In addition to existing AUTH payload validation as part of IKEv2 protocol, IKEv2 calculates hash of the received certificate or looked-up PSK and compares with the fingerprint from SIP negotiation that IKEv2 queries from VPN-SIP module. Only if the fingerprint matches, IKEv2 considers authentication of peer is valid. If not, IKEv2 declares that peer has failed to authenticate and fails the VPN session.

VPN-SIP solution depends on IPSEC idle timer to detect that traffic is no longer routed over the backup VPN. The idle-time configuration under the IPSec Profile is mandatory for session to be disconnected when there is no traffic. 120 seconds is the recommended time.

VPN-SIP and SIP coordinate to tear down SIP call.

When IPsec idle time expires the VPN-SIP module informs the IKEv2 to bring down the IPsec tunnel. VPN-SIP requests the SIP module to disconnect the SIP call, without waiting for confirmation from the IKEv2.

When SIP call disconnect is received from the peer, VPN-SIP module informs the IKEv2 to bring down the IPsec tunnel, and acknowledges to SIP to tear down the SIP call.

The VPN-SIP feature is supported on the following platforms:

The following steps describe the process of configuring VPN-SIP:

1. Configure the tunnel authentication using third party certificates, self-signed certificates, or pre-shared keys.

   1. Tunnel Authentication using Certificates

      Configure a trustpoint to obtain a certificate from a certification authority (CA) server that is located in the customer's network. This is required for tunnel authentication. Use the following configuration:

      peer1(config)# crypto pki trustpoint CA
       enrollment url http://10.45.18.132/
       serial-number none
       subject-name CN=peer2
       revocation-check crl
       rsakeypair peer2
      
      peer2(config)# crypto pki authenticate CA
      Certificate has the following attributes:
             Fingerprint MD5: F38A9B4C 2D80490C F8E7581B BABE7CBD
            Fingerprint SHA1: 4907CC36 B1957258 5DFE23B2 649E7DDA 99BDB7C3
      % Do you accept this certificate? [yes/no]: yes
      Trustpoint CA certificate accepted.
      
      peer2(config)#crypto pki enroll CA
      %
      % Start certificate enrollment ..
      % Create a challenge password. You will need to verbally provide this
         password to the CA Administrator in order to revoke your certificate.
         For security reasons your password will not be saved in the configuration.
         Please make a note of it.
      Password:
      Re-enter password:
      % The subject name in the certificate will include: CN=peer2
      % The subject name in the certificate will include: peer2
      % Include an IP address in the subject name? [no]:
      Request certificate from CA? [yes/no]: yes
      % Certificate request sent to Certificate Authority
      % The 'show crypto pki certificate verbose CA' command will show the fingerprint.
      Certificate map for Trustpoint
      crypto pki certificate map data 1
      issuer-name co cn = orange
      

   2. Tunnel authentication using self-signed certificate

      Configure a PKI trust point to generate a self-signed certificate on the device, when authenticating using a self-signed certificate. Use the following configuration:

      peer4(config)#crypto pki trustpoint Self
          enrollment selfsigned
          revocation-check none
          rsakeypair myRSA
          exit
      crypto pki enroll Self
       
      Do you want to continue generating a new Self Signed Certificate? [yes/no]: yes
      % Include the router serial number in the subject name? [yes/no]: yes
      % Include an IP address in the subject name? [no]: no
      Generate Self Signed Router Certificate? [yes/no]: yes
       
      Router Self Signed Certificate successfully created

   3. Configure tunnel authentication using a pre-shared key

      crypto ikev2 keyring keys
      peer peer1
      identity key-id 1234
      pre-shared-key key123

2. • Configure IKEv2 Profile for Certificate

     crypto ikev2 profile IPROF
     match certificate data
     identity local key-id 5678
     authentication remote rsa-sig
     authentication local rsa-sig
     keyring local keys
     pki trustpoint self
     nat force-encap
     

   • Configure an IKEv2 Profile for pre-shared keys

     crypto ikev2 profile IPROF
     match identity remote any
     identity local key-id 5678
     authentication remote pre-share
     authentication local pre-share
     keyring local keys
     nat force-encap
     

   Note	To complete the IKEv2 SA configuration, the nat force-encap command must be configured on both peers. Since, UDP encapsulation is negotiated in SDP, IKEv2 must start and continue on port 4500.

3. Configure an IPsec profile

   crypto ipsec profile IPROF
   set security-association idle-time 2000
   

4. Configure a LAN side interface

   interface Vlan101
            ip address 192.0.2.3 255.255.255.0
            no shutdown 
   ! 
        interface GigabitEthernet2
            switchport access vlan 101
            no ip address
   

5. Configure a loopback interface

   The loopback interface is used as the source interface for the secondary VPN tunnel.

   interface loopback 1
       ip address 192.0.2.1 255.0.0.0
       ip nat inside
   

6. Configure a secondary interface.

   Note	Make sure the secondary interface is configured to receive the IP address, SIP server address, and vendor specific information via DHCP.

   interface GigabitEthernet8
        ip dhcp client request sip-server-address
        ip dhcp client request vendor-identifying-specific
        ip address dhcp
       ip nat outside
   

7. Configure the tunnel interface

   interface Tunnel1
        ip address 192.0.2.1 255.255.255.255
        load-interval 30
        tunnel source Loopback1
        tunnel mode ipsec ipv4
        tunnel destination dynamic
        tunnel protection ipsec profile IPROF ikev2-profile IPROF
        vpn-sip local-number 5678 remote-number 1234 bandwidth 1000
   
   

   Use the vpn-sip local-number local-number remote-number remote-number bandwidth bw-number command to configure the sVTI interface for VPN-SIP. Bandwidth is the maximum data transmission rate that must be negotiated with this peer and the negotiated value is set on the tunnel interface. Allowed values are 64, 128, 256, 512, and 1000 kbps.

   Once an SVTI is configured for VPN-SIP, changes cannot be made to tunnel mode, tunnel destination, tunnel source, and tunnel protection. To change the mode, source, destination, or tunnel protection you must remove the VPN-SIP configuration from the SVTI interface.

8. Add static routes to destination networks

   Add a secondary route with a higher metric.

   ip route 192.0.2.168 255.255.255.0 Tunnel0 track 1
   ip route 192.0.2.168 255.255.255.0 Tunnel1 254
   

9. Configure IP SLA

   ip sla 1
            icmp-echo 192.0.2.11
            threshold 500
            timeout 500
            frequency 2
           ip sla schedule 1 life forever start-time now
   

10. Configure route tracking

    track 1 ip sla 1 reachability

11. Enable VPN-SIP

    vpn-sip enable
    vpn-sip local-number 5678 address ipv4 GigabitEthernet8
    vpn-sip tunnel source Loopback1
    vpn-sip logging
    

    To configure VPN-SIP, you must configure local SIP number and local address. The vpn-sip local-number SIP-number address ipv4 WAN-interface-name command configures the local SIP number that is used for SIP call and the associated IPv4 address.

    Note	Only IPv4 addresses can be configured. Crypto module does not support dual stack. Backup WAN interface address may change based on DHCP assignment.

    When the primary WAN interface is functional, the destination of the VPN-SIP tunnel is set to the backup WAN interface, so that the tunnel interface is active. Destination is set to IP address of the peer that is learnt from SDP of SIP negotiation when traffic is routed to the tunnel interface. When primary WAN interface fails and the back routes are activated, packets are routed to the sVTI through backup.

    Note

    We recommend that you use an unused non-routable address as the address of the loopback interface and do not configure this loopback interface for any other purpose. Once a loopback interface is configured, VPN-SIP listens to any updates to the interface and blocks them. The vpn-sip logging command enables the system logging of VPN-SIP module for events, such as session up, down, or failure.

Optionally, you can apply a quality of service (QoS) policy to the VPN-SIP. A QoS policy provides secure, predictable, measurable, and sometimes guaranteed services to certain types of traffic.

1. Configure the appropriate policy map.

   Device(config)#class-map match-all UDP
    match protocol ip
   !
   policy-map CBWFQ
    class UDP
     bandwidth percent 60 
     queue-limit 12 packets

2. Attach the policy-map to the VPN-SIP:

   Device(config)#interface Tunnel1
   .
   .
   .
   vpn-sip local-number 5678 remote-number 1234 bandwidth 1000 service-policy CBWFQ

   Note

   When the VPN-SIP session is successfully negotiated and comes up, an implicit service policy is automatically attached to the tunnel interface. If you run the show running-config command for this interface, the implicit service policy is not displayed. Any policy-map that you create on the device becomes a child policy of this implicit service policy.