SRX

Hi all,

I'm deploying VPN site to site between Main Office with branches by SRX devices. SRX Branches are behind NAT device. Main Office has IP static public, branches have dynamic IP (use noip). So, I use method VPN Hub and Spoke with point to multipoint. VPN connect success with  show security ipsec security-associations, show security ike security-associations are up both. But I can not ping between IP local main office and branches (same can not ping between IP tunnels). Please help me. Thank you

Hi,

Can you please share the VPN configuration from both the hub and spoke side.
Also can you enable flow trace for the traffic which is getting encrypted in teh SRX.

this will tell us whether the Packet is actually entering the VPN or not.

regards,

Guru Prasad

Thanks for your reply. Here Hub device config

security {
ike {
proposal ike-phase1-proposal {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike-phase1-policy {
mode aggressive;
proposals ike-phase1-proposal;
pre-shared-key ascii-text "$9$c-wSK8db2Ujq7-Zjk.F3hSrK87-Vw2oJN-"; ## SECRET-DATA
}
gateway gw-htn {
ike-policy ike-phase1-policy;
dynamic hostname branch.ddns.net;
no-nat-traversal;
local-identity user-at-hostname "responder_nat@xxx.com";
external-interface pp0.0;
version v1-only;
}

ipsec {
proposal ipsec-phase2-proposal {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
}
policy ipsec-phase2-policy {
perfect-forward-secrecy {
keys group5;
}
proposals ipsec-phase2-proposal;
}
vpn ike-vpn-htn {
bind-interface st0.0;
ike {
gateway gw-htn;
no-anti-replay;
proxy-identity {
local 192.168.6.0/24;
remote 192.168.7.0/24;
}
ipsec-policy ipsec-phase2-policy;
}
establish-tunnels immediately;
}

flow {
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
}

from-zone Internal to-zone vpn-htn {
policy vpn-site-htn {
match {
source-address PT;
destination-address [ HTN vpn-nt TL LG ];
application any;
}
then {
permit;
}
}
}
security-zone Internet {
host-inbound-traffic {
system-services {
ike;
}
}

security-zone vpn-htn {
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
interfaces {
st0.0;
}
}
}
st0 {
unit 0 {
multipoint;
family inet {
address 10.1.1.1/8;
}
}

routing-options {
static {
route 0.0.0.0/0 {
qualified-next-hop pp0.0 {
metric 1;
}
}

route 192.168.7.0/24 next-hop 10.1.1.2;
route 192.168.4.0/24 next-hop 10.1.1.6;
route 192.168.3.0/24 next-hop 10.1.1.7;
route 192.168.9.0/24 next-hop 10.1.1.4;
}
}

Here is config of a branch device 

routing-options {
static {
route 0.0.0.0/0 next-hop 192.168.1.1;
route 192.168.6.0/24 next-hop st0.0;
}
}
security {
ike {
proposal ike-phase1-proposal {
authentication-method pre-shared-keys;
dh-group group5;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
}
policy ike-phase1-policy {
mode aggressive;
proposals ike-phase1-proposal;
pre-shared-key ascii-text "$9$q.T3tu1reW9ASeM8Vbk.PT39Ap01EcCA"; ## SECRET-DATA
}
gateway gw-pt {
ike-policy ike-phase1-policy;
address 111.111.111.111;
local-identity hostname pvoiltl.ddns.net;
remote-identity user-at-hostname "responder_nat@xxx.com";
external-interface fe-0/0/0.0;
version v1-only;
}
}

ipsec {
proposal ipsec-phase2-proposal {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
}
policy ipsec-phase2-policy {
perfect-forward-secrecy {
keys group5;
}
proposals ipsec-phase2-proposal;
}
vpn ike-vpn-pt {
bind-interface st0.0;
ike {
gateway gw-pt;
no-anti-replay;
ipsec-policy ipsec-phase2-policy;
}
traffic-selector ts1 {
local-ip 192.168.7.0/24;
remote-ip 192.168.6.0/24;
}
establish-tunnels immediately;
}
}
flow {
tcp-mss {
ipsec-vpn {
mss 1350;
}
}
}

nat {
source {
rule-set trust-to-untrust {
from zone trust;
to zone untrust;
rule source-nat-rule {
match {
source-address 0.0.0.0/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
rule-set DYNAMIC {
from zone untrust;
to zone trust;
rule R2R3 {
match {
source-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
}
from-zone trust to-zone vpn-pt {
policy vpn-tr-chi {
match {
source-address TL;
destination-address PT;
application any;
}
then {
permit;
}
}
}
from-zone vpn-pt to-zone trust {
policy vpn-chi-tr {
match {
source-address PT;
destination-address TL;
application any;
}
then {
permit;
}
}
}
default-policy {
permit-all;
}

security-zone untrust {
screen untrust-screen;
host-inbound-traffic {
system-services {
ike;
}
}

security-zone vpn-pt {
host-inbound-traffic {
system-services {
any-service;
}
protocols {
all;
}
}
interfaces {
st0.0;
}

I only post config that important. show security ike security-associations and  show security ipsec security-associations then up both. I am configuring one Hub with 3 Spoke, sometimes I can ping between Hub and only 1 Spoke, after can't ping (I let ping daily). I show security flow session then traffic pass throught tunnel.

do you have security policies in place to permit the traffic?

Are all three tunnels at the hub site bound to the same interface?

If they are, are you using OSPF to automatically create the NHTB for the routes or manually creating them?

Thanks for your reply. Yes, I have create policy to permit traffic. Yes, all tunnel at hub is bound to same interface st0 (p2mp). I'm not yet try with OSPF. I'm also going try with this solution. You can explain help me why i can't use static route for tunnels. I found document that use static route with multipoint (https://www.juniper.net/documentation/en_US/junos/topics/example/ipsec-hub-and-spoke-configuring.html). Many thanks.

You can use static routes but you cannot use next-hop interface with a multi-point tunnel.

You need to use the next-hop of the specific ip address of the REMOTE side tunnel for each subnet.

Also wondering why you have the tunnel interfaces setup as such a large network using the whole 10.0.0.0/8 for the interface range.  This is not a problem, just unusual.  But would be a problem if you need to have routing to 10.0.0.0/8 subnets anywhere else on the network that would then overlap with this setup.

Thank you. I see i use next-hop with IP: 
route 192.168.7.0/24 next-hop 10.1.1.2;
route 192.168.4.0/24 next-hop 10.1.1.6;
route 192.168.3.0/24 next-hop 10.1.1.7;
route 192.168.9.0/24 next-hop 10.1.1.4;

I also changed subnet tunnel to 24.

Is everything working now then?

Not yet, everything not change. I'm really use next-hop with IP before. I'm only change subnet tunnel as you suggest. Thanks

I found when i delete ike service on external interface (only keep ike on untrust zone) then can pass traffic. But traffic vpn is not stable, sometime ping miss package. When traffic down, i check flow session on branche

show security flow session destination-prefix 192.168.6.5
Session ID: 14513, Policy name: self-traffic-policy/1, Timeout: 56, Valid
In: 192.168.3.1/0 --> 192.168.6.5/7738;icmp, If: .local..0, Pkts: 1, Bytes: 84
Out: 192.168.6.5/7738 --> 192.168.3.1/0;icmp, If: st0.0, Pkts: 0, Bytes: 0

Here is policies on Hub and Spoke. Please check help me, thank you.

Hub
root@FW# show security policies
from-zone Internet to-zone DMZ {
policy All_Internet_DMZ {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone DMZ to-zone Internet {
policy AllowAll_Internet_DMZ {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Internal to-zone Internet {
policy AllowAll_Internet_Internal {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Internet to-zone Internal {
policy remote-to-srv {
match {
source-address any;
destination-address Server;
application rdp;
}
then {
permit;
}
}
}
from-zone Internal to-zone DMZ {
policy All_Internal_DMZ {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Internal to-zone Internal {
policy internal_internal {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone Internal to-zone vpn-htn {
policy vpn-site-htn {
match {
source-address PT;
destination-address [ HTN vpn-nt TL LG ];
application any;
}
then {
permit;
}
}
}
from-zone vpn-htn to-zone Internal {
policy vpn-site-htn {
match {
source-address [ HTN vpn-nt TL LG ];
destination-address PT;
application any;
}
then {
permit;
}
}
}
from-zone DMZ to-zone Internal {
policy DMZ_To_Internal {
match {
source-address any;
destination-address any;
application any;
source-identity any;
}
then {
deny;
}
}
}
inactive: from-zone vpn-htn to-zone vpn-htn {
policy spokevpn {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
default-policy {
permit-all;
}

Branch

root# show security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
from-zone trust to-zone vpn-pt {
policy vpn-tr-chi {
match {
source-address NT;
destination-address PT;
application any;
}
then {
permit;
}
}
}
from-zone vpn-pt to-zone trust {
policy vpn-chi-tr {
match {
source-address PT;
destination-address NT;
application any;
}
then {
permit;
}
}
}
default-policy {
permit-all;
}

[edit]

This is saying the hub is able to send traffic but no reply comes back from the spoke.

Session ID: 14513, Policy name: self-traffic-policy/1, Timeout: 56, Valid
In: 192.168.3.1/0 --> 192.168.6.5/7738;icmp, If: .local..0, Pkts: 1, Bytes: 84
Out: 192.168.6.5/7738 --> 192.168.3.1/0;icmp, If: st0.0, Pkts: 0, Bytes: 0

Run throught these steps on the spoke side device.  You can start at #3

https://kb.juniper.net/InfoCenter/index?page=content&id=KB10093

Thanks spuluka. I have check steps but can not find error to fix this problem.

Is the firewall the only router at the spoke site or is there more networking devices downstream?

Is this behavior consistent or intermitent?

The data is showing a packet encrypted and sent from the hub to the spoke with no reply coming back from the spoke device.  We need to confirm:

The packets are delivered to the end device

And the replies can route back to the firewall for encryption and return

So the steps above verify you have the active route to the tunnel interface so if the packet is seen it will get forward

It verifies you have a policy to permit the traffic.

If there are layer 3 devices between the firewall and the device we need to confirm symmetrical routing back to the firewall.

Perhaps a packet capture on the device will also verify ultimate delivery of all the packets and replies being sent.

Thanks Spuluka. Maybe, I found troubleshoot by restart tunnel. When i restart tunnel on hub: restart ipsec-key-management, a few minutes all  vpn connections are up. But the problems is only one spoke can ping to hub (and else), others spoke i must execute bellow commands to pass throught traffic:

ping ip-local-hub source ip-local-spoke 

restart ipsec-key-management

If i only excute restart ipsec-key-management command then not pas throught traffic.

Anyway, traffic is not stable, sometimes i must do repeat commands as above. Maybe because spokes uses dynamic ip?

Thank you very much,

Maybe if you add vpn monitor to the affected site it would help.  This tests the vpn and keeps it up even when there is no local traffic.

Set this up with a ping from your local lan gateway interface on the remote side as the source and a reachable ip address gateway on the tunnel as a destination.

set security ipsec vpn NAME vpn-monitor source-interface vlan.0 destination-ip 192.168.10.1 optimized

web ui article:

https://kb.juniper.net/InfoCenter/index?page=content&id=KB10119

Thank you but it isn't work with my case. I tried with vpn-monitor, dead peer detection, SA life time aren't successful. Anyway, i can control with ping source and restart ipsec-key-management. Thank you very much.