Juniper SRX: IPSec VPN sourcing from loopback interface in a VRF

Probably not an overly common setup but you’ll inevitably become frustrated if you try it. As per this Juniper PR, it’s necessary to put your loopback interface and your external interface(s) in the same security zone. You still need that if you are sourcing from a loopback interface in a routing-instance however it doesn’t quite resolve the issue.

If you enable enough logging, you’ll see that the phase 1 (UDP) works fine but the phase 2 (ESP) gets blocked. If you look at flow logs, the following is the important bit:

  1. CID-1:THREAD_ID-05:RT:flow_first_policy_search: policy search from zone edge-> zone edge (0x0,0x11941194,0x1194)
  2. CID-1:THREAD_ID-05:RT: packet dropped, denied by policy

This says that it’s looking for a policy that permits ESP within the “edge” zone. In my case, “edge” is the name of the security zone that contains the external interfaces and the loopback interface.

The solution is to add a security policy from-zone edge to-zone edge which allows ESP. It looks like this:

  1. phil@be-fw-03# show security policies from-zone edge to-zone edge
  2. policy a_esp {
  3. match {
  4. source-address any;
  5. destination-address any;
  6. application esp;
  7. }
  8. then {
  9. permit;
  10. }
  11. }
  13. {primary:node0}[edit]
  14. phil@be-fw-03# show applications application esp
  15. term t1 protocol esp;

I couldn’t see a JunOS inbuilt policy for esp so I created the applicationesp as shown above.

If you’re using NAT Traversal with your VPN, it’s possible you’ll need to allow more stuff in your application. That might look like this:

  1. term t1 protocol udp source-port 500 destination-port 500;
  2. term t2 protocol udp source-port 4500 destination-port 4500;
  3. term t3 protocol esp;

Juniper JunOS: Difference between rib-groups and instance-import

Both rib-groups and instance-import allow you to selectively (or non-selectively) import routes into one VRF from another. I won’t go into detail of the syntax and usage of these two as Matt Dinham does it extremely well in his blog post.

However, it’s important to document the fundamental difference between the two. In essence, instance-import works on FIB routes and rib-groups work on RIB routes. That is to say that instance-import will only export the currently active route(s)¬†from the source VRF whereas rib-groups will export all routes from the target VRF.

Let’s say, for example, you wanted to create a VRF which contained a copy of all of the routes from your transit providers and none of the routes from your direct peers. Because instance-import¬†only imports currently active routes from the source table, it is unsuitable for the task at hand because it’s probable that many of your transit routes are inactive in favour of the direct peerings.