Troubles with somewhat complicated ASA-SRX tunnels

[#1]

I have a somewhat complicated setup, we are currently in the process of migrating our office network (replacing our ASA5505 router, renumbering our internal network, moving QA and test equipment out), and I'm having some problems bringing up a working VPN tunnel between the ASA and our new SRX240.

I've attached a diagram.  Please try to not view it on a full stomach, or if you have a heart condition.  I think there are only 8 different, haphazardly-assigned netblocks behind the "old network" (plus the random /24 transit netblock between the ASA and the L3 switch), but there might be more.  I am sticking everything new into the one /19 behind the SRX.

However, because there's gear in all of those networks, a simple route-based VPN isn't going to work for me.  Sadface.  I considered going the quick-and-dirty route GRE-inside-IPSEC route, but unfortunately you cannot terminate GRE on a Cisco ASA.  You -can-, however, terminate it on a 4948, running full IOS - except, for some reason, I cannot reach the old-network L3 switch from any device on the new network.

Currently, as the config works now, I can, from any device in 172.16.96.0/19, ping the inside interface on the ASA (192.168.1.1).  I cannot ping the L3 interface on the switch (.14), nor any other device in 192.168.1.0/24. From the ASA, if i do 'ping inside $ip', I can ping anything in 172.16.96.0/19, but I cannot ping from anything else in the old network (including the L3 switch) to the new network.

Normally I would just cable up an interface between the ASA and the SRX, stick both sides on the trusted/inside security zone, slap some routes together and go.  However, we have two datacenters (East and West) with an ASA5510 and ASA5505, respectively, that we need tunnels to, and I figured breaking the office is better than breaking a datacenter.  Luckily, these will also be renumbered and re-engineered with Vendor-J equipment at a later date - sadly, not this quarter.

I'm pretty sure that to get this working, I'm going to have to move to a policy-based VPN.  But I'd like to see it at least pass SOME traffic beyond the ASA before I go into reworking that.   Anyone have any suggestions?

Relevant ASA config (There's some random ACL stuff in there, I've been trying different things to convince it to work):

interface Ethernet0/1

 nameif inside

 security-level 100

 ip address 192.168.1.1 255.255.255.0 

interface Ethernet0/3

 nameif outside

 security-level 0

 ip address x.x.x.34 255.255.255.224 

access-list new_network_cryptomap extended permit ip 172.16.100.0 255.255.252.0 172.16.0.0 255.255.255.0 

access-list new_network_cryptomap extended permit ip 172.16.0.0 255.255.255.0 172.16.100.0 255.255.252.0 

access-list new_network_cryptomap extended permit ip 172.16.127.4 255.255.255.252 192.168.1.0 255.255.255.0 

access-list new_network_cryptomap extended permit ip 192.168.1.0 255.255.255.0 172.16.127.4 255.255.255.252 

access-list new_network_cryptomap extended permit ip 172.16.100.0 255.255.252.0 192.168.1.0 255.255.255.0 

access-list new_network_cryptomap extended permit ip 192.168.1.0 255.255.255.0 172.16.100.0 255.255.252.0 

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac 

crypto map new_network_Tom 10 match address new_network_cryptomap

crypto map new_network_Tom 10 set peer x.x.x.35 

crypto map new_network_Tom 10 set transform-set ESP-3DES-SHA

crypto map new_network_Tom 10 set security-association lifetime seconds 28800

crypto map new_network_Tom 10 set security-association lifetime kilobytes 1048576

crypto isakmp policy 10

 authentication pre-share

 encryption 3des

 hash sha

 group 2      

 lifetime 86400

tunnel-group x.x.x.35 type ipsec-l2l

tunnel-group x.x.x.35 ipsec-attributes

 pre-shared-key *

Relevant SRX config:

interfaces {

    ge-0/0/0 {

        gigether-options {

            auto-negotiation;

        }

        unit 0 {

            description "External (Untrust)";

            family inet {

                address x.x.x.35/27;

            }

        }

    }

    st0 {

        unit 0 {

            family inet {

                address 172.16.127.5/30;

            }

        }

    }

    vlan {

        unit 901 {

            family inet {

                address 172.16.127.1/30;

            }

        }

    }

}

routing-options {

    static {

        route 0.0.0.0/0 next-hop x.x.x.33;

        route 172.16.100.0/22 next-hop 172.16.127.2;

        route 172.16.0.0/24 next-hop st0.0;

        route 192.168.1.0/24 next-hop st0.0;

    }

}

security {

    ike {

        proposal P1-3DES-SHA {

            authentication-method pre-shared-keys;

            dh-group group2;

            authentication-algorithm sha1;

            encryption-algorithm 3des-cbc;

            lifetime-seconds 28800;

        }

        policy tomIKE {

            mode main;

            proposals P1-3DES-SHA;

            pre-shared-key ascii-text "youWouldn'tBeInterestedInThis"; ## SECRET-DATA

        }

        gateway gwTom {

            ike-policy tomIKE;

            address x.x.x.34;

            external-interface ge-0/0/0;

        }

    }

    ipsec {

        proposal P2-SHA-3DES {

            protocol esp;

            authentication-algorithm hmac-sha1-96;

            encryption-algorithm 3des-cbc;

            lifetime-seconds 28800;

            lifetime-kilobytes 1048576;

        }

        policy tomIPSEC {

            proposals P2-SHA-3DES;

        }

        vpn tomVPN {

            bind-interface st0.0;

            ike {

                gateway gwTom;

                proxy-identity {

                    local 172.16.96.0/19;

                    remote 192.168.1.0/24;

                }

                ipsec-policy tomIPSEC;

            }

            establish-tunnels immediately;

        }

    }

    nat {

        source {

            rule-set interface-nat {

                from zone trust;

                to zone untrust;

                rule default-out {

                    match {

                        source-address 0.0.0.0/0;

                        destination-address 0.0.0.0/0;

                    }

                    then {

                        source-nat {

                            interface;

                        }

                    }

                }

            }

        }

    }

    zones {

        security-zone trust {

            tcp-rst;

            address-book {

                address new-network-wired 172.16.100.0/23;

                address new-network-wireless 172.16.102.0/23;

                address-set new-network {

                    address new-network-wired;

                    address new-network-wireless;

                }

            }

            host-inbound-traffic {

                system-services {

                    ssh;

                    ping;

                }

                protocols {

                    all;

                }

            }

            interfaces {

                vlan.901 {

                    host-inbound-traffic {

                        system-services {

                            ssh;

                            ping;

                        }

                        protocols {

                            all;

                        }

                    }

                }

                st0.0 {

                    host-inbound-traffic {

                        system-services {

                            ssh;

                            ping;

                        }

                        protocols {

                            all;

                        }

                    }

                }

            }

        }

        security-zone untrust {

            address-book {

                address old-network-servers 172.16.0.0/24;

                address old-network-wired 172.16.8.0/22;

                address-set old-network {

                    address old-network-wired;

                    address old-network-servers;

                }

            }

            screen untrust-screen;

            host-inbound-traffic {

                system-services {

                    ike;

                }

            }

            interfaces {

                ge-0/0/0.0 {

                    host-inbound-traffic {

                        system-services {

                            ping;

                        }

                    }

                }

            }

        }

    }

}

[#2]

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.