Oh, fun! You've come across the "what if my VPN has more than one Phase II SA" use case.
The reason your test case w/ just one SA is not working is pretty simple: You have a proxy-id of 172.16.96.0/19 <-> 192.168.1.0/24, and you do not have a corresponding entry in your new_network_cryptomap.
Cisco ASA is quite strict when it comes to Phase II ids. a) they have to match exactly on both sides, and b) they have to match the traffic you are actually sending through the tunnel.
I have seen nothing in your setup that suggests the need to NAT within the tunnel. You only have one network on the SRX side, which simplifies things greatly.
Therefore, going with a policy-based VPN is a reasonable step to take. You'd just have one line of policy for each SA pairing.
This will work as long as you do not a) NAT any traffic across the tunnel and b) do not static-NAT any of the destination servers on the SRX side on the Untrust interface.
You can get around b) (should it be an issue in your environment) by using a source/destination NAT pair instead on Untrust. Though truth be told I don't think we tested that, but I do seem to remember we were thinking it should work.
If NATs are ruining your day with this VPN, then you do still have another option: Route-based VPNs with NHTB. I'll try and copy/paste the writeup I did on that. No guarantees as to how well the formatting will survive.
>>
The challenge
You have been tasked to set up a VPN between a Juniper SRX firewall and a Cisco ASA/PIX firewall. This can be challenging because of the interplay of NAT and the specific requirements of a Cisco VPN.
- Cisco uses ACLs to define Phase 2 "proxy IDs". Cisco requires that the source and destination IPs of the traffic traversing the tunnel "fit with" the proxy ID of the Phase 2 SA the traffic arrives in. When you have multiple destinations and sources, this can become complex quickly.
- Juniper recommends to use policy-based VPNs for this situation, creating one policy for each source/destination combination. On the Juniper side, proxy IDs are then derived from each policy.
- Policy-based VPNs will cease to function for hosts that have had static NAT applied to them on the Untrust (outside) interface, such as web or mail servers
- Policy-based VPNs cannot NAT the traffic traversing the VPN, as may be necessary when the remote side mandates the use of public IPs or there are overlapping network ranges
Solution: Configure a route-based VPN with NHTB (Next Hop Tunnel Binding)
Route-based VPNs can support bi-directional NAT through the tunnel, and will work for servers that have existing static NATs. Multiple Phase 2 configurations define each of the proxy ID pairs that may be required for the VPN. NHTB and routing select the correct Phase 2 (and thus proxy ID) to use depending on source and destination IP.
NB: This setup positively requires JunOS 10.0r3 or better. JunOS 10.0r2 has defects that breaks the routing in this design.
Example setup
The IP addresses and networks I will use to demonstrate this type of setup are:
- SRX outside interface: 172.16.1.1
- PIX outside interface: 172.16.2.1
- SRX protected network: 192.168.100.48/28
- SRX NAT space for protected network: 10.255.255.48/28
- PIX protected network: 10.255.252.48/28
- PIX protected host: 10.255.252.15/32
- st0 prefix: 172.31.255.1/24
This is close to the simplest setup you may encounter. There is only one source network on the SRX side, and two destinations on the PIX side. This allows for simple static destination NAT. The SRX device will NAT its own network for use through the VPN.
Alternate setups would have two or more source networks, in which case policy-based routing would need to be employed, or may require that the SRX NAT the traffic for the remote network, in which case the NAT clauses would need to be constructed a little differently.
Tunnel interface and NHTB
st0 {
unit 0 {
multipoint;
family inet {
next-hop-tunnel 172.31.255.2 ipsec-vpn CiscoASA-VPN-P2;
next-hop-tunnel 172.31.255.3 ipsec-vpn CiscoASA-VPN-P2-2;
address 172.31.255.1/24;
}
}
}
- st0 has an address of 172.31.255.1/24. Note the large mask: This is to allow for expansion in the future, as each proxy ID will need one "ephemeral" IP address. I have seen configurations with up to 400 different proxy IDs, in which case a /23 would be needed.
- multipoint enables NHTB
- next-hop-tunnel statements bind an "ephemeral" IP address to a specific Phase 2 configuration, and thus specific proxy ID. I call these IP addresses "ephemeral" because they do not actually exist on the Cisco PIX side: They are only used for purposes of NHTB
Routing
routing-options { static { route 10.255.252.48/28 next-hop 172.31.255.2; route 10.255.252.15/32 next-hop 172.31.255.3; } }
These routes have two purposes:
- They ensure that VPN traffic passes through st0.0, by routing to its subnet
- They "tie" each destination to a specific proxy ID by specifying the "ephemeral" IP referenced above, in the NHTB setup, as the next-hop for that destination
NB: If we had multiple source networks that needed to be represented in separate proxy IDs, simple destination-based static routing would not do the trick. You'd need to do policy-based routing, and decide the correct next-hop to specify based on both the source and destination IPs. This can quickly get complex: If you have 20 source networks and 20 destination networks, you end up with 400 possible combinations, and thus 400 proxy IDs, 400 Phase 2 entries, 400 next-hop-tunnel statements, and 400 policy-based route statements. To avoid getting into that situation, attempt to keep the number of objects as small as possible, by using subnets instead of hosts, and supernets instead of subnets.
IKE and IPSEC setup
ike {
respond-bad-spi;
proposal pre-g2-3des-md5-86400 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm md5;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;
}
policy CiscoASA-Policy {
mode main;
proposals pre-g2-3des-md5-86400;
pre-shared-key ascii-text "$9$i.mTzF/Au1TzyK8LbwoJGDqm"; ## SECRET-DATA
}
gateway CiscoASA-VPN-P1 {
ike-policy CiscoASA-Policy;
address 172.16.2.1;
external-interface fe-0/0/7.0;
}
}
ipsec {
proposal esp-g2-3des-md5-86400 {
protocol esp;
authentication-algorithm hmac-md5-96;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;
}
policy IPSec-Policy1 {
perfect-forward-secrecy {
keys group2;
}
proposals esp-g2-3des-md5-86400;
}
vpn CiscoASA-VPN-P2 {
bind-interface st0.0;
ike {
gateway CiscoASA-VPN-P1;
proxy-identity {
local 10.255.255.48/28;
remote 10.255.252.48/28;
}
ipsec-policy IPSec-Policy1;
}
}
vpn CiscoASA-VPN-P2-2 {
bind-interface st0.0;
ike {
gateway CiscoASA-VPN-P1;
proxy-identity {
local 10.255.255.48/28;
remote 10.255.252.15/32;
}
ipsec-policy IPSec-Policy1;
}
}
}
In this case, 3DES / MD5 is mandated by the Cisco PIX side. When you can choose, AES-128/SHA-1 would be your preferred choice every time.
You see your standard setup for a route-based VPN, with one twist: There are two vpn statements, each defining a separate proxy-identity, bound to the same tunnel interface. Routing, and thus NHTB, will determine which Phase 2 entry is used for any given source/destination IP pair.
Proxy ID is always a combination of the SRX-side (local) network or host, and the PIX-side (remote) network or host. In this case, as we have only one SRX-side source (a network) and two PIX-side destinations (one network, one host), we need only two Phase 2 (vpn) definitions.
NAT
nat {
static {
rule-set AHS-NAT {
from zone vpn;
rule 1 {
match {
destination-address 10.255.255.48/28;
}
then {
static-nat prefix 192.168.100.48/28;
}
}
}
}
}
The st0 interface happens to be in the "vpn" zone in this example. A static NAT that translates from one subnet to another has been set up. As these addresses are to be NATed through a VPN, proxy ARPs are not needed.
Variations on this theme may be:
- You need to NAT the remote network, not your local network. In that case, the direction of the NAT is reversed: You'd have a "from zone <local>" statement, instead of "from zone vpn", where <local> would be the zone your traffic that is to traverse the VPN is originating from: This may be trust, or might be dmz.
- One or more of your local assets are already static-NATed on the Untrust interface. As you cannot have multiple static NATs for the same physical host, you would need to create a source NAT / destination NAT pair in this case. JunOS 10.2 would be required if you needed more than 8 source NAT / destination NAT statements (rules) in your rule-set dedicated to the VPN.
- You need to NAT the remote network, not your local network, AND you are sourcing traffic from more than one zone. As with the above scenario, since you cannot have multiple static NAT entries for the same physical host(s), you would need to use source NAT / destination NAT pairs. JunOS 10.2 would be required if you needed more than 8 source NAT / destination NAT statements (rules) in your rule-set dedicated to the VPN.
