SRX VPN: Multipoint

Happy New Year to all readers!

Today we are going to make a multipoint VPN.
One hub site (VPN-CORE) and 2 spokes sites (LEFTY and RIGHTY2). All devices are SRXs.

Multipoint is only supported with Route based VPNs so that's what we will be using and the key point to note is that the multipoint hub only uses a single tunnel interface regardless of the number of VPN tunnels.

In real life you probably wouldn't bother with multipoint for just 2 spokes but this is a lab so lets do it!

Here is the network we are working on..
We will want to get traffic between the 2 trust zones and the server-zone running over the VPN.

SPOKE SITE CONFIG (RIGHTY2)

With colour highlights showing how all the different elements "glue" together.

1) TUNNEL INTERFACE

Create the tunnel interface.
All the tunnel interfaces are in the same subnet - 20.0.20.0/24

set interfaces st0 unit 0 family inet address 20.0.20.3/24

2) ROUTING

a) Define default route to point to the cloud.

set routing-options static route 0.0.0.0/0 next-hop 3.3.3.1

b) Define which destination traffic we wish to access to via the tunnel interface.
 
We wish to get to the server network behind VPN-CORE via the VPN,

set routing-options static route 192.168.210.0/24 next-hop st0.0

3) SPOKE CONFIG PHASE 1 and 2

a) Define Phase 1 proposal set

set security ike proposal aes-phase1 authentication-method pre-shared-keys
set security ike proposal aes-phase1 dh-group group2
set security ike proposal aes-phase1 authentication-algorithm sha1
set security ike proposal aes-phase1 encryption-algorithm aes-256-cbc
set security ike proposal aes-phase1 lifetime-seconds 86400

b) Define Phase 1 policy

set security ike policy hub_p1_pol mode main
set security ike policy hub_p1_pol proposals aes-phase1
set security ike policy hub_p1_pol pre-shared-key ascii-text testkey2

c) Define Phase 1 gateway

set security ike gateway hub_gw ike-policy hub_p1_pol
set security ike gateway hub_gw address 4.4.4.2
set security ike gateway hub_gw external-interface fe-0/0/7.0
set security ike gateway hub_gw version v1-only

The IP address here is the external address of the hub SRX ans the external interface in the physical interface the VPN traffic will use

d) Define Phase 2 proposal set

set security ipsec proposal aes-phase2 protocol esp
set security ipsec proposal aes-phase2 authentication-algorithm hmac-sha1-96
set security ipsec proposal aes-phase2 encryption-algorithm aes-256-cbc
set security ipsec proposal aes-phase2 lifetime-seconds 3600

e) Define Phase 2 policy

set security ipsec policy hub_p2_pol perfect-forward-secrecy keys group2
set security ipsec policy hub_p2_pol proposals aes-phase2 

f) Define the VPN

set security ipsec vpn hub_vpn bind-interface st0.0
set security ipsec vpn hub_vpn ike gateway hub_gw
set security ipsec vpn hub_vpn ike ipsec-policy hub_p2_pol
set security ipsec vpn hub_vpn establish-tunnels immediately

You can clearly see how the VPN section of the config ties all the other elements together

So no difference in configuring the spoke side of a multipoint VPN as compared to configuring one side of a point-to-point link.

4) VPN ZONE

Define a VPN security zone and put the tunnel interface in it.

set security zones security-zone vpn interfaces st0.0

5) ADDRESSES

Define any needed addresses for the policy rules

Local address..

set security address-book global address net_192.168.197.0/24 192.168.197.0/24  

Remote address..

set security address-book global address net_192.168.210.0/24 192.168.210.0/24

6) POLICY

Create appropriate policy rules according to your needs

From the local network to the remote server network on any port

set security policies from-zone trust to-zone vpn policy vpn_core_access match source-address net_192.168.197.0/24
set security policies from-zone trust to-zone vpn policy vpn_core_access match destination-address net_192.168.210.0/24
set security policies from-zone trust to-zone vpn policy vpn_core_access match application any
set security policies from-zone trust to-zone vpn policy vpn_core_access then permit
set security policies from-zone trust to-zone vpn policy vpn_core_access then log session-init

From the remote server network to the local network on any port

set security policies from-zone vpn to-zone trust policy vpn_core_access match source-address net_192.168.210.0/24
set security policies from-zone vpn to-zone trust policy vpn_core_access match destination-address net_192.168.197.0/24
set security policies from-zone vpn to-zone trust policy vpn_core_access match application any
set security policies from-zone vpn to-zone trust policy vpn_core_access then permit
set security policies from-zone vpn to-zone trust policy vpn_core_access then log session-init

7) ALLOW IKE

Permit IKE on the external facing security zone

set security zones security-zone cloud-link host-inbound-traffic system-services ike

HUB SITE CONFIG (VPN-CORE)

1) TUNNEL INTERFACE

set interfaces st0.0 multipoint family inet address 20.0.20.4/24

* Note the use of the keywork Multipoint. This is the only tunnel interface we will need to create on the hub site. Which leads us to..

NHTB.

The hub device has only one tunnel interface in a multipoint config so it needs a way to be able to decide which VPN to use for what traffic.

For this it uses the next-hop tunnel binding table (NHTB) feature which maps VPN names to next hop IP gateways. VPN name in this instance means the actual name given in the set security ipsec vpn command. The remote device's st0 interface IP is the next hop IP for the NHTB

Here are the elements to get traffic into the correct tunnel for a specific destination address.
inet.0     - destination address to next hop mapping
NHTB     - next hop mapping to VPN ....i.e The link between the destination route and the VPN to use for that route

As all the devices in our network are SRXs we dont need to manually define the NHTB table as the NHTB mappings can be discovered during Phase 1 negotiations. If we didnt have Junos (or ScreenOS) devices as both ends we would need to manually define the NHTB entries.

We will see this all more clearly in the output when its all working below.

2) ROUTING

a) Define default route to point to the cloud.

set routing-options static route 0.0.0.0/0 next-hop 4.4.4.1

b) Define the next hops for the remote destination networks pointing to the remote st0 IPs

set routing-options static route 192.168.197.0/24 next-hop 20.0.20.3
set routing-options static route 192.168.20.0/24 next-hop 20.0.20.2
set routing-options static route 192.168.30.0/24 next-hop 20.0.20.2
set routing-options static route 192.168.40.0/24 next-hop 20.0.20.2

If this was a point-to-point to point VPN we would add the route for the remote networks pointing to st0.x. But we cant do that with the multipoint config as we only have the one tunnel! So we use the remote tunnel IP for the next hop IP (Remote st0 IP)

3) HUB CONFIG PHASE 1 and 2

a) Define Phase 1 proposal set

set security ike proposal aes-phase1 authentication-method pre-shared-keys
set security ike proposal aes-phase1 dh-group group2
set security ike proposal aes-phase1 authentication-algorithm sha1
set security ike proposal aes-phase1 encryption-algorithm aes-256-cbc
set security ike proposal aes-phase1 lifetime-seconds 86400

b) Define Phase 1 policies

set security ike policy righty2_p1_pol mode main
set security ike policy righty2_p1_pol proposals aes-phase1
set security ike policy righty2_p1_pol pre-shared-key ascii-text testkey2

set security ike policy lefty_p1_pol mode main
set security ike policy lefty_p1_pol proposals aes-phase1
set security ike policy lefty_p1_pol pre-shared-key ascii-text testkey

c) Define Phase 1 gateways

set security ike gateway righty2_gw ike-policy righty2_p1_pol
set security ike gateway righty2_gw address 3.3.3.2
set security ike gateway righty2_gw external-interface fe-0/0/7.0
set security ike gateway righty2_gw version v1-only

set security ike gateway lefty_gw ike-policy lefty_p1_pol
set security ike gateway lefty_gw address 2.2.2.2
set security ike gateway lefty_gw external-interface fe-0/0/7.0
set security ike gateway lefty_gw version v1-only

d) Define Phase 2 proposal set

set security ipsec proposal aes-phase2 protocol esp
set security ipsec proposal aes-phase2 authentication-algorithm hmac-sha1-96
set security ipsec proposal aes-phase2 encryption-algorithm aes-256-cbc
set security ipsec proposal aes-phase2 lifetime-seconds 3600

e) Define Phase 2 policies

set security ipsec policy righty2_p2_pol perfect-forward-secrecy keys group2
set security ipsec policy righty2_p2_pol proposals aes-phase2

set security ipsec policy lefty_p2_pol perfect-forward-secrecy keys group2
set security ipsec policy lefty_p2_pol proposals aes-phase2

f) Define the VPNs

set security ipsec vpn righty2_vpn bind-interface st0.0
set security ipsec vpn righty2_vpn ike gateway righty2_gw
set security ipsec vpn righty2_vpn ike ipsec-policy righty2_p2_pol
set security ipsec vpn righty2_vpn establish-tunnels immediately

set security ipsec vpn lefty_vpn bind-interface st0.0
set security ipsec vpn lefty_vpn ike gateway lefty_gw
set security ipsec vpn lefty_vpn ike ipsec-policy lefty_p2_pol
set security ipsec vpn lefty_vpn establish-tunnels immediately

Note the use of the same tunnel interface.

4) VPN ZONE

Define a VPN security zone and put the tunnel interface in it.

set security zones security-zone vpn interfaces st0.0

5) ADDRESSES

Define any needed addresses for the policy rules

Local address..

set security address-book global address net_192.168.210.0/24 192.168.210.0/24

Remote address..

set security address-book global address net_192.168.197.0/24 192.168.197.0/24
set security address-book global address net_192.168.20.0/24 192.168.20.0/24 
set security address-book global address net_192.168.30.0/24 192.168.30.0/24 
set security address-book global address net_192.168.40.0/24 192.168.40.0/24 

6) POLICY

From the remote networks to the local server network on any port

set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.197.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.20.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.30.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match source-address net_192.168.40.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match destination-address net_192.168.210.0/24
set security policies from-zone vpn to-zone server-zone policy vpn_core_access match application any
set security policies from-zone vpn to-zone server-zone policy vpn_core_access then permit
set security policies from-zone vpn to-zone server-zone policy vpn_core_access then log session-init

From the local server network to the remote networks on any port

set security policies from-zone server-zone to-zone vpn policy vpn_core_access match source-address net_192.168.210.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.197.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.20.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.30.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match destination-address net_192.168.40.0/24
set security policies from-zone server-zone to-zone vpn policy vpn_core_access match application any
set security policies from-zone server-zone to-zone vpn policy vpn_core_access then permit
set security policies from-zone server-zone to-zone vpn policy vpn_core_access then log session-init
 
7) ALLOW IKE

Permit IKE on the external facing security zone

set security zones security-zone cloud-link host-inbound-traffic system-services ike

VERIFICATION

SPOKE SIDE VERIFICATION  

1) Check Phase 1 is up..

blogger@RIGHTY2> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address  
3184912 UP     0b97d84cc0ef6274  6484e2b7dfa56dc0  Main           4.4.4.2        

blogger@RIGHTY2> show security ike security-associations detail
IKE peer 4.4.4.2, Index 3184912,
  Role: Responder, State: UP
  Initiator cookie: 0b97d84cc0ef6274, Responder cookie: 6484e2b7dfa56dc0
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 3.3.3.2:500, Remote: 4.4.4.2:500
  Lifetime: Expires in 73786 seconds
  Peer ike-id: 4.4.4.2
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
  Traffic statistics:
   Input  bytes  :                 2872
   Output bytes  :                 2244
   Input  packets:                   17
   Output packets:                    8
  Flags: IKE SA is created
  IPSec security associations: 5 created, 4 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 3.3.3.2:500, Remote: 4.4.4.2:500
    Local identity: 3.3.3.2
    Remote identity: 4.4.4.2
    Flags: IKE SA is created

2) Check Phase 2 is up..

blogger@RIGHTY2> show security ipsec security-associations
  Total active tunnels: 1
  ID    Algorithm       SPI      Life:sec/kb  Mon vsys Port  Gateway  
  <131073 ESP:aes-256/sha1 92cde104 2231/ unlim -  root 500   4.4.4.2        
  >131073 ESP:aes-256/sha1 8ef2d2ea 2231/ unlim -  root 500   4.4.4.2  
 
blogger@RIGHTY2> show security ipsec security-associations detail
  Virtual-system: root
  Local Gateway: 3.3.3.2, Remote Gateway: 4.4.4.2
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
    Direction: inbound, SPI: 92cde104, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2200 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 1628 seconds
    Mode: Tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 8ef2d2ea, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2200 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 1628 seconds
    Mode: Tunnel, Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

3) Check stats..

blogger@RIGHTY2> show security ipsec statistics
ESP Statistics:
  Encrypted bytes:            88160
  Decrypted bytes:            48720
  Encrypted packets:            580
  Decrypted packets:            580
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

HUB SIDE VERIFICATION

1) Check Phase 1 is up..

blogger@VPN-CORE> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address  
6340566 UP     3a4e4de2147e1425  3a329010954c4d83  Main           2.2.2.2        
6340567 UP     cce17ea8c4fbbaa5  01463a6a9e1bdd7b  Main           3.3.3.2 

blogger@VPN-CORE> show security ike security-associations detail
IKE peer 2.2.2.2, Index 6340566, Gateway Name: lefty_gw
  Role: Initiator, State: UP
  Initiator cookie: 3a4e4de2147e1425, Responder cookie: 3a329010954c4d83
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 4.4.4.2:500, Remote: 2.2.2.2:500
  Lifetime: Expires in 85593 seconds
  Peer ike-id: 2.2.2.2
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                  916
   Output bytes  :                 1000
   Input  packets:                    4
   Output packets:                    5
  Flags: IKE SA is created
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Initiator, Message ID: 0
    Local: 4.4.4.2:500, Remote: 2.2.2.2:500
    Local identity: 4.4.4.2            
    Remote identity: 2.2.2.2
    Flags: IKE SA is created

IKE peer 3.3.3.2, Index 6340567, Gateway Name: righty2_gw
  Role: Initiator, State: UP
  Initiator cookie: cce17ea8c4fbbaa5, Responder cookie: 01463a6a9e1bdd7b
  Exchange type: Main, Authentication method: Pre-shared-keys
  Local: 4.4.4.2:500, Remote: 3.3.3.2:500
  Lifetime: Expires in 85593 seconds
  Peer ike-id: 3.3.3.2
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes256-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                  916
   Output bytes  :                 1000
   Input  packets:                    4
   Output packets:                    5
  Flags: IKE SA is created
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0  

    Negotiation type: Quick mode, Role: Initiator, Message ID: 0
    Local: 4.4.4.2:500, Remote: 3.3.3.2:500
    Local identity: 4.4.4.2
    Remote identity: 3.3.3.2
    Flags: IKE SA is created

2) Check Phase 2 is up..

blogger@VPN-CORE> show security ipsec security-associations
  Total active tunnels: 2
  ID    Algorithm       SPI      Life:sec/kb  Mon lsys Port  Gateway  
  <131074 ESP:aes-cbc-256/sha1 9434a8a9 2755/ unlim - root 500 2.2.2.2        
  >131074 ESP:aes-cbc-256/sha1 47c144b2 2755/ unlim - root 500 2.2.2.2        
  <131073 ESP:aes-cbc-256/sha1 1298cf37 2755/ unlim - root 500 3.3.3.2        
  >131073 ESP:aes-cbc-256/sha1 12f7c6b5 2755/ unlim - root 500 3.3.3.2   

4 phase 2 SAs - one pair for each of the spoke sites - exactly what we expect for a route based VPN. 

blogger@VPN-CORE> show security ipsec security-associations detail
  ID: 131074 Virtual-system: root, VPN Name: lefty_vpn
  Local Gateway: 4.4.4.2, Remote Gateway: 2.2.2.2
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 600a29
  Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 9434a8a9, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2130 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 47c144b2, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2130 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

  ID: 131073 Virtual-system: root, VPN Name: righty2_vpn
  Local Gateway: 4.4.4.2, Remote Gateway: 3.3.3.2
  Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0)
  Version: IKEv1
    DF-bit: clear
    Bind-interface: st0.0

  Port: 500, Nego#: 1, Fail#: 0, Def-Del#: 0 Flag: 600a29
  Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: 1298cf37, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2118 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 12f7c6b5, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 2752 seconds
    Lifesize Remaining:  Unlimited
    Soft lifetime: Expires in 2118 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

3) Check NHTB table and routing.. 

blogger@VPN-CORE> show security ipsec next-hop-tunnels
Next-hop gateway  interface   IPSec VPN name                    Flag     IKE-ID                            XAUTH username
20.0.20.2         st0.0       lefty_vpn                         Auto     2.2.2.2                        
20.0.20.3         st0.0       righty2_vpn                       Auto     3.3.3.2 

See how the NHTB  entries have been auto installed due to phase 1 negotiations. If we were using a point-to-point VPN we would see no output for this command.
Here is a VPN debug showing the NHTB negotiations between the hub and 2 spokes.

blogger@VPN-CORE> show log VPNLOG | match NHTB
[Jan  2 12:38:42]Construction NHTB payload for  local:4.4.4.2, remote:2.2.2.2 IKEv1 P1 SA index 6340566 sa-cfg lefty_vpn
[Jan  2 12:38:42]iked_nhtb_get_tunnel_ifam: got ifa  error  0
[Jan  2 12:38:42]Construction NHTB payload for  local:4.4.4.2, remote:3.3.3.2 IKEv1 P1 SA index 6340567 sa-cfg righty2_vpn
[Jan  2 12:38:42]iked_nhtb_get_tunnel_ifam: got ifa  error  0
[Jan  2 12:38:42]Received NHTB payload from  local:4.4.4.2, remote:2.2.2.2 IKEv1 P1 SA index 6340566
[Jan  2 12:38:42]Received NHTB private IP address 20.0.20.2
[Jan  2 12:38:42]In iked_nhtb_config_send_msg Adding GENCFG msg with key = 20002
[Jan  2 12:38:42]iked_nhtb_config_send_msg: Successfully added NHTB Config with key
[Jan  2 12:38:42]nhtb route operation: ifindex=69, (69), rttabl=0
[Jan  2 12:38:42]iked_nhtb_add_entry: Not adding NHTB entry to kernel as IKED_NHTB_IN_KERNEL is set
[Jan  2 12:38:42]Received NHTB payload from  local:4.4.4.2, remote:3.3.3.2 IKEv1 P1 SA index 6340567
[Jan  2 12:38:42]Received NHTB private IP address 20.0.20.3
[Jan  2 12:38:43]In iked_nhtb_config_send_msg Adding GENCFG msg with key = 20001
[Jan  2 12:38:43]iked_nhtb_config_send_msg: Successfully added NHTB Config with key
[Jan  2 12:38:43]nhtb route operation: ifindex=69, (69), rttabl=0
[Jan  2 12:38:43]iked_nhtb_add_entry: Not adding NHTB entry to kernel as IKED_NHTB_IN_KERNEL is set

Note how the phase 1 SAs above match the following info..

blogger@VPN-CORE> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address  
6340566 UP     3a4e4de2147e1425  3a329010954c4d83  Main           2.2.2.2        
6340567 UP     cce17ea8c4fbbaa5  01463a6a9e1bdd7b  Main           3.3.3.2  

So lets go over the routing from the hub SRX to get to the remote network behind RIGHYT2 - 192.168.197.0/24
Here is how I think it through..

blogger@VPN-CORE> show route 192.168.197.0

inet.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

192.168.197.0/24   *[Static/5] 00:18:43
                    > to 20.0.20.3 via st0.0

The above says to get to the remote network 192.168.197.0/24 go via 20.0.20.3 via st0.0
We know 20.0.20.3 is the IP of st0.0 on RIGHTY2
But how do we get to 20.0.20.3?

blogger@VPN-CORE> show security ipsec next-hop-tunnels
Next-hop gateway  interface   IPSec VPN name                    Flag     IKE-ID                            XAUTH username
20.0.20.2         st0.0       lefty_vpn                         Auto     2.2.2.2                        
20.0.20.3         st0.0       righty2_vpn                       Auto     3.3.3.2               

The above says we get to 20.0.20.3 via the righty2_vpn.

4) Check stats..

blogger@VPN-CORE> show security ipsec statistics   
ESP Statistics:
  Encrypted bytes:            13568
  Decrypted bytes:             7420
  Encrypted packets:             68
  Decrypted packets:             83
AH Statistics:
  Input bytes:                    0
  Output bytes:                   0
  Input packets:                  0
  Output packets:                 0
Errors:
  AH authentication failures: 0, Replay errors: 0
  ESP authentication failures: 0, ESP decryption failures: 0
  Bad headers: 0, Bad trailers: 0

5) Check ESP is in the session flow table

blogger@VPN-CORE> show security flow session | match esp
  In: 2.2.2.2/37940 --> 4.4.4.2/43177;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0
  In: 2.2.2.2/0 --> 4.4.4.2/0;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0
  In: 3.3.3.2/4760 --> 4.4.4.2/53047;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0
  In: 3.3.3.2/0 --> 4.4.4.2/0;esp, If: fe-0/0/7.0, Pkts: 0, Bytes: 0

You can also see the same thing with show security flow session tunnel

SPOKE TO SPOKE COMMUNICATIONS

With what we have set up in this lab, the spokes will not be allowed to talk to each other. If you wanted to allow the spokes to talk to each other you would need..

On the HUB..

An intra vpn zone policy such as..
 
set security policies from-zone vpn to-zone vpn policy intra-vpn match source-address any
set security policies from-zone vpn to-zone vpn policy intra-vpn match destination-address any
set security policies from-zone vpn to-zone vpn policy intra-vpn match application any
set security policies from-zone vpn to-zone vpn policy intra-vpn then permit
set security policies from-zone vpn to-zone vpn policy intra-vpn then log session-init

On the Spokes..
 
Adjust the policies accordingly and don't forget to add the routes to the other spoke(s) via st0.0

Model: srx210he
JUNOS Software Release [12.1X45-D15.5]