Vyatta IPsec site-to-site VPN
You can use two methods to configure an Internet Protocol Security (IPsec) site-to-site VPN on a Vyatta vRouter: policy-based and route-based. Rackspace supports only the policy-based method, and this article explains how to use that method.
This is an example of a site-to-site VPN configuration with a Vyatta firewall on the Rackspace side and a Cisco firewall on the customer side (data center or another remote location).
NAT and IPsec
Network Address Translation (NAT) and the IPsec engine work the same on the Vyatta vRouter as a Cisco Adaptive Security Appliance (ASA) in that NAT happens before the interesting traffic is evaluated for encryption by the IPsec engine. The reverse is also true: when a packet is received via the VPN tunnel, the packet is decrypted before it goes to the NAT engine. Policy NAT and Policy Port Address Translation (PAT) for site-to-site VPN tunnels is also possible. See Creating NAT rules for Vyatta vRouter for the current standards for NAT rule numbering.
Assume that there is an outbound PAT policy whereby all server traffic coming from the inside segment goes through PAT to the vRouter’s public IP address for Internet-bound traffic. [Be sure to refer to the example.]
You need to bypass the preceding PAT policy for VPN traffic only. The easiest way to accomplish this is to use the
exclude command in all of your NAT or PAT statements for the remote encryption domains. Note that these NAT rule numbers need to be lower than the PAT or NAT rule that you are trying to bypass. The order of the NAT or PAT statements is very important.
Example of NAT bypass
IPsec VPN configuration
Note: The default kickstart configuration populates the most common phase 1 and phase 2 settings. Be sure to check the existing configuration for required settings.
ISAKMP and IPsec requirements
Phase 1 configuration
If the kickstart configuration does not provide the combination of Phase 1 and Phase 2 settings that you require, you can use the following options to create new Phase 1 and Phase 2 settings.
If the required lifetime value is already part of an IKE group, you can create a new proposal within that IKE group, as shown in the following example:
If you require a different lifetime value than any configured, then you would require a new IKE group, as shown in the following example:
Phase 2 configuration
- ESP group
- IPsec peer (tunnel group)
- Interesting traffic for IPsec peer
The complete configuration
Verify the tunnels
- Phase 1 SA
- Phase 2 SA
Continue the conversation in the Rackspace Community.
©2017 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License