I figured I would take a moment and recap theses past few posts and talk about the different methods now that we understand what they are. I also want to talk about some of the things to consider when choosing your approach.
Policy-Based with Security Policies
In our first post, we covered using security policies to establish and pass the traffic over the tunnel. There are a few challenges with this type of configuration is that you need to be keenly aware of.
You need to keep in mind that the order of security policies is critical. If you have a policy that permits or denies this traffic before the policy that says to tunnel the traffic, you will never send the traffic over the tunnel. Also, new security policies are always placed at the end of the current policies, so when you add a new VPN, you will need to remember to insert the new policy in the proper location.
A caveat of these is that they tend to be more complex than either IKE proxy-id or traffic-selector due to security policies in the untrust zone. This is because you will need a security-policy for every local/remote subnet that needs to go over the VPN. I have seen where there are hundreds of security policies with matching pair-policies in configurations.
Also, since you do not have a dedicated interface nor usually a route for the tunnel, tracking down where the traffic is going and monitoring the VPN tends to be difficult.
One benefit of a policy-based security policy configuration is that you do not need any additional tunnel interfaces, routes, or security zones. Your Untrust zone and default route are all that you need.
Policy-Based with IKE Proxy-Identity
In our second post, we covered IKE Proxy-Identity for our VPNs. Technically this is a route-based VPN solution that interoperates with a policy-based VPN solution.
It is configured like any other VPN, you just need to configure the local and remote proxy-id. If you do not configure any proxy-identity, a default proxy-identity of 0.0.0.0/0 will be used.
These are nice as you can bind them to an st interface, apply that interface to its own zone, and create the associated zone-based policies. This helps to make troubleshooting easier as you can look for the associated zone-based policy that is either permitting or rejecting the traffic, monitor traffic on that interface to check for encap/decaps of the packets, as well as even monitor the interface for up/down status. If the VPN is critical, you can monitor for the interface being down as it will go down when the VPN is down.
A caveat to proxy-identity is that you need a separate ipsec vpn configuration stanza for each proxy-identity configuration. If you have 10 networks that you need to tunnel, you will have a vpn for each of the networks. Below is an example of what it would look like for two networks – local is 10.0.0.0/24 and remote networks are 10.1.0.0/24 and 10.10.0.0/24.
vpn VPN-B2B-1 {
bind-interface st0.0;
ike {
gateway IKE-GW-B2B;
proxy-identity {
local 10.0.0.0/24
remote 10.1.0.0/24
service any;
}
ipsec-policy IPSEC-POLICY-B2B;
}
}
vpn VPN-B2B-2 {
bind-interface st0.0
ike {
gateway IKE-GW-B2B;
proxy-identity {
local 10.0.0.0/24;
remote 10.10.0.0/24;
service any;
}
ipsec-policy IPSEC-POLICY-B2B;
Policy-Based with IKE Traffic-Selector
In our third post, we covered IKE Traffic-Selectors for our VPNs. Again, this is a route-based VPN solution that interoperates with a policy-based VPN solution. It is very much like the proxy-identity and shares all the same benefits.
Again you can bind the VPN to an st interface, apply that interface to its own zone, and create the associated zone-based policies. As mentioned, this is great for creating isolated policies for your zone-to-zone traffic and being able to troubleshoot, add, or remove policies. You are able to monitor the interface and be able to know when the VPN is down.
A difference with traffic-selector over proxy-identity is that additional networks are all configured under the same VPN stanza. You have one network, just add the one – you have 10, add all 10 under the same VPN stanza. There is no need for separate VPN stanza for each proxy-identity. Below is an example of a traffic-selector with multiple subnets being sent over it.
vpn B2B-VPN {
bind-interface st0.5;
ike {
gateway IKE-GW-B2B;
ipsec-policy IPSEC-POLICY-B2B;
}
traffic-selector VPN-B2B_10.1.0.0
local-ip 10.0.0.0/24;
remote-ip 10.1.0.0/24;
}
traffic-selector VPN-B2B_10.10.0.0 {
local-ip 10.0.0.0/24;
remote-ip 10.10.0.0/24;
}One caveat that I have come across with traffic-selector is that it is limited to 200 tunnels in a single configuration. While this sounds like a lot, yet when a customer wants to keep sending only /32s across a tunnel and not subnets, it can be a problem. I have come across this once so far (thats how I know the limit) and what I had to do was audit all the connections and clean-up the communication. We also finally convinced the customer to aggregate the subnets and use polices to block traffic as appropriate.
Traffic-selectors are the preferred way to handle policy-based VPNs on Juniper. They offer all the advantages of route-based with the compatibility to policy-based VPN firewalls. If you need to turn up a new policy-based VPN, use traffic-selectors.