JNCIE-SEC Multipoint tunnels/Policy and route based VPNs

After the introduction to IPSEC a little bit, I am following with the second task and third task in the list which are Multipoint tunnels and policy/route based VPNs. Some of these individual tasks have overlapping case studies because of this I may not write a single post for each task.

IPsec VPNs


  • Implementation of NAT
  • Source NAT
  • Destination NAT
  • Static NAT
  • Implementation of NAT with IPSec
  • Overlapping IPs between sites

Our case study is that we have a company headquarter of which is in Amsterdam and has two offices in London and Paris. We will connect these two offices to Amsterdam HQ via an IPSEC tunnel. London office is route based and Paris office will connect via policy based VPN. Protected networks are assigned to ge-0/0/1.0 interface of each SRX device.


Below is the IPSEC config of J41 IPSEC HUB. Tunnel interface is marked as multipoint and assigned to the security zone vpn and IKE is allowed on external-interface.

J23 spoke configuration. It is very similar to HUB but st0.0 interface is
without multipoint option.

Check if IKE Phase1 and Phase2 have been established:

I have shown IKE output in detail to show you that Phase 1 lifetime mismatch between J23(3600secs) and J41(14400secs) According to RFC2409 lifetime isn’t among MUST be negotiated parameters and what I have seen is responder accepts what the initiator sends. In our case J23 accepts the 14400secs offer.

This setup was an ideal case which means we set it up and it worked but you may see numerous cases that IKE Phase 1 isn’t coming up and you don’t always see the reason in traceoptions. Here is the list to check if your IKE phase isn’t coming up from my experience;

Make sure:

  • IKE gateways have IP connectivity
  • UDP port 500 isn’t blocked anywhere in the path
  • There is no additional IP address configured on IKE external interfaces other than the IKE gateway IP
    You may initiate packets from wrong source address. You can work around this but better not to have it.
  • There is no firewall filter blocking UDP port 500 on lo0.0 interface.
  • Parameters you set match at both side

Soft Lifetime / Hard Lifetime
An IPSEC SA has both soft and hard life time. Below is an example output from another day (SPIs are different);

This says soft life time expired for the tunnel 131073 and after a new quick mode re-key, new SAs have been established (SPI:63c0bd98 and f7296421). But what does this mean in practical terms;


I initiated a ping just before the soft lifetime expires. As you can see in the wireshark capture just after the re-key peers stop using old SPIs and switch to the new tunnel SPIs and the old SPIs disappear from the list before lifetime counts down to zero.

Route Based VPN

Now it is time to protect traffic between network and network

Routes in two ways have been added and installed. One point we must pay attention to is that multipoint side route’s next-hop isn’t st0.0 interface. The reason is that there are multiple gateways behind this interface and next-hop to an interface can’t identify the right gateway. Because of which we must set the route to next-hop which we see in next-hop-tunnels output.

The following policies allow VPN traffic in both directions in both nodes.

Now we have a working Route Based VPN between two SRX peers. Time for Policy Based VPN!

Policy Based VPN

J41 HUB config
In policy based config

  • we don’t bind vpn to any stX interface.
  • Bidirectional security policies define which traffic to forward to tunnel
  • Source and destination addresses define the proxy ids of the tunnel if more than one address specified in any direction proxy id turns to

A new gateway for J21 device is defined under [edit security ike]

and a new VPN under [edit security ipsec]

Bidirectional security policies. Pay attention to the pair-policy option, it references the policies in two directions.

J21 Spoke config
Spoke has also a similar config. (Security zone config is omitted, but is like the config in HUB)

Verifying IPSEC tunnels

Now we have two active tunnels, one is policy based (ID:2) and route based (ID:131073) If you display policy based tunnel by index, you will also see which policy is linked to this tunnel

Check the Policy-name field.

Verifying encrypted traffic

Hmm it doesn’t work. I have enabled and seen that self-traffic-policy is hitting instead of int-to-vpn policy. Our ping command worked in route based VPN because self-traffic is forwarded to st0.0 interface by which encryption is done. However here we have to hit the right policy for encryption to happen. Actually I couldn’t find a way to do this without creating a routing instance. To make this ping successful, I had to make the following changes;

Now test ping again and we can see that packets are encrypted and decrypted.

We have reached the end of policy based VPN as well. I hope I haven’t made any mistake so far. I will continue with traceoptions in which I will do some bunch of IPSEC tunnel troubleshooting.

You have a feedback?

This site uses Akismet to reduce spam. Learn how your comment data is processed.