SRX

Hello everybody,

I have two DC sites DC-A & DC-B with branch offices . ISG2000 at DC-A and SRX1500 at DC-B with IPSec site to Site VPNs route based between  branch offices and DC's. At branch offices i have SRX320. 

Recently one of the site have been deployed with WAN link by ISP. DC-A is'nt reachable at all  via peer IP but DC-B does. On branch side SRX-320, i checked VPN status and found as below

SRX320-branch> show security ipsec security-associations

VPN shows UP with DC-A 

no SA stats for DC-B

Its kind of wear as no peer ip reachability with DC-A and still shows SA stats even after i clear SA's.

No SA/Ike stats for DC-B (reachable via peer ip)

Branch SRX320 (10.50.66.45)  ---------------WAN IP pingable-----------------------> 172.16.2.1 (SRX1500 DC-B)

Branch SRX320 (10.50.66.45) ---------------WAN ip ping failure------------------------> 10.50.40.1 (ISG2000 DC-A)

One of the thing i am doubtfull is the IKE port, may be blocked by ISP. Please help. 

Hello 

VPN may be up even while the gateway may not be pingable depending on the configuration. Is DC-A not pingable from other branches as well?

Regarding VPN to DC-B I would start with verifying the config before going the ISP way. Given the situation unlikely that the ISP is a problem due to two reasons:

> VPN to DC-A is up, so branch ISP is allowing IKE

> Other VPNs to DC-B are up so IKE should be permitted at the headend too

If you can attach the configs from the branch and the DC-B we can take a quick look.

Regards,

Vikas

Hello vikas,

Config attached for ur kind reference. I also want to explain that DC-A is pingable from other running branch offices and also VPN shows UP/ with LAN IP reachability as well.  Ping is aloowed globally and also on interface level, so no issues of policy/ disabling on interface. 

Attachment(s)

DC B end config.txt   1016 B 1 version

Branch end.txt   5 KB 1 version

Hello,

Please help/suggest troubleshooting tips.

Hello 

Can you check and confirm the status of Ph1 so we can troubleshoot accordingly? Is Ph1 up?

show security ike sa

> On DC-B ipsec config I am seeing traffic selector configured but dont see the same on branch side

> You have establish-tunels on traffic on the branch end, I suggest you change it to establish-tunnels immediately just to rule out that factor

Regards,

Vikas

Hello,

--------------------------------------------------------

Branch side

----------------------------------------------------

root@SRX-FSD-1638-TINDLIANWALA> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
604210 UP 945bd1fb7ae1fb1c 3feee2f654e61d47 Main 10.50.40.1 //primary VPN with DC-A ISG2000 Netscreen device

-------------------------------------------------------------------------------------------

Also there are three VPN's on branch side i.e. 

VPN-PRI-CORE       ////Primary VPN with DC-A

VPN-BCK-CORE    ////Secondary vpn with DC-A

VPN-PRI-NTC       ////Primary vpn with DC-B SRX1500

VPN-PRI-NTC based on traffic selectors just like on DC-B 

I also configured " establish-tunnels immediately " on branch side VPN facing DC-B. But still the situation is same. 

----------------------------------

Also attached DC-A ISG2000 config for reference.

Attachment(s)

DC-A end config.txt   1 KB 1 version

Hello,

Thanks for sharing this. So we know Ph1 is not coming up. Focusing on Ph1 can you share the entire outputs of the below commands from both ends. Earlier snippet you shared does not include this info. 

> show security ike

> show security ipsec

> show interfaces

> show security zones

Regards,

Vikas

Hi AZkhan,

If phase 1 is not coming up it is important to check if the peers are negotiating the tunnel at all. Please confirm if they are exchanging UDP 500 packets with the following  operational command. Please run the command on both SRXs:

        > show security flow session protocol udp destination-port 500 destination-address [remote_peer_address]

Please check sessions with port 4500 as well. If there is a NAT device in beween the peers will use UDP 4500 and it is commonly blocked by the ISPs:

        > show security flow session protocol udp destination-port 4500 destination-address [remote_peer_address]

Also why is that the SRXs in the diagram have private IP addresses? If this becuase they are connected over the WAN link you mentioned?

Hi epaniagua

Please have a look on the desired output. Furthermore, private IP's being used for reason of leased MPLS based WAN links of ISP. 

===============
BranchSide
==============

Branch-Side> show security flow session protocol udp destination-port 500 destination-prefix 172.16.2.1
Session ID: 32893, Policy name: self-traffic-policy/1, Timeout: 30, Valid
In: 10.50.66.45/500 --> 172.16.2.1/500;udp, Conn Tag: 0x0, If: .local..0, Pkts: 3681, Bytes: 1295712,
Out: 172.16.2.1/500 --> 10.50.66.45/500;udp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 0, Bytes: 0,
Total sessions: 1

Branch-Side> show security flow session protocol udp destination-port 4500 destination-prefix 172.16.2.1
Total sessions: 0

====================================================================================================================================

DataCentre side SRX1500
================================

{primary:node0}
root@CDNS-SRX-1500-00> show security flow session destination-port 500 destination-prefix 10.50.66.45
node0:
--------------------------------------------------------------------------

Session ID: 323649, Policy name: self-traffic-policy/1, State: Active, Timeout: 36, Valid
In: 172.16.2.1/500 --> 10.50.66.45/500;udp, Conn Tag: 0x0, If: .local..0, Pkts: 4890, Bytes: 1115088,
Out: 10.50.66.45/500 --> 172.16.2.1/500;udp, Conn Tag: 0x0, If: reth0.0, Pkts: 3698, Bytes: 1301696,
Total sessions: 1

node1:
--------------------------------------------------------------------------

Session ID: 1770490, Policy name: self-traffic-policy/1, State: Backup, Timeout: 160, Valid
In: 172.16.2.1/500 --> 10.50.66.45/500;udp, Conn Tag: 0x0, If: .local..0, Pkts: 0, Bytes: 0,
Out: 10.50.66.45/500 --> 172.16.2.1/500;udp, Conn Tag: 0x0, If: reth0.0, Pkts: 0, Bytes: 0,
Total sessions: 1

---------------------------------------------------------------------------------------------
{primary:node0}
root@CDNS-SRX-1500-00> show security flow session destination-port 4500 destination-prefix 10.50.66.45
node0:
--------------------------------------------------------------------------
Total sessions: 0

node1:
--------------------------------------------------------------------------
Total sessions: 0

========================================================================================================

Thanks for the info AZkhan.

When the SRX320 is sending IKE traffic to DC-B it is not receiving any reply.:

==============
BranchSide
==============

Branch-Side> show security flow session protocol udp destination-port 500 destination-prefix 172.16.2.1 
Session ID: 32893, Policy name: self-traffic-policy/1, Timeout: 30, Valid
In: 10.50.66.45/500 --> 172.16.2.1/500;udp, Conn Tag: 0x0, If: .local..0, Pkts: 3681, Bytes: 1295712,    
Out: 172.16.2.1/500 --> 10.50.66.45/500;udp, Conn Tag: 0x0, If: ge-0/0/0.0, Pkts: 0, Bytes: 0, 
Total sessions: 1

Lets configure a firewall filter, on the external interface of SRX320, with a counter to count the incoming IKE packets from DC-B. This way we will be able to tell if UDP 500 packets are reaching the SRX320 at all:

set firewall family inet filter IKE_COUNT term COUNT from source-address 172.16.2.1
set firewall family inet filter IKE_COUNT term COUNT from protocol udp
set firewall family inet filter IKE_COUNT term COUNT from destination-port 500
set firewall family inet filter IKE_COUNT term COUNT then count IKE_INCOMING
set firewall family inet filter IKE_COUNT term COUNT then accept
set firewall family inet filter IKE_COUNT term ACCEPT-ALL then accept


set interfaces ge-0/0/0 unit 0 family inet filter input IKE_COUNT

Once you commit the above configuration, use the following command to check the counter:

[edit]
root@SRX1# run show firewall

Filter: __default_bpdu_filter__

Filter: IKE_COUNT
Counters:
Name                                                Bytes              Packets
IKE_INCOMING                                            0                    0

Hi epaniagua

Check the stats.

I think IKE traffic is not passing through. 

branchside> show firewall

Filter: __default_bpdu_filter__

Filter: IKE_COUNT
Counters:
Name                                        Bytes                                         Packets
IKE_INCOMING                        0                                                     0

AZkhan,

Definitely it looks like the UDP 500 traffic is not reaching the SRX and you should raise this concern to your ISP. As a final test I will suggest you to take a packet capture on the external interface matching traffic from the IP addresses of both firewalls and double-check that the UDP 500 traffic is not received from the remote end:

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

This will be a vital test to present to the ISP along with the counter you already provided.

Hi epaniagua

Thanks for the prompt reply. 

Should i use the Firewall filter as suggested by you or the one given in th KB11709?

Moreover, is it must to use wrieshark etc to view the Packet Capture file ? 

AZKhan,

1. Use a filter like the one shown in the KB:

et firewall filter PCAP term 1 from source-address 172.16.2.1
set firewall filter PCAP term 1 from destination-address 10.50.66.45
set firewall filter PCAP term 1 then sample
set firewall filter PCAP term 1 then accept
set firewall filter PCAP term 2 from source-address 10.50.66.45
set firewall filter PCAP term 2 from destination-address 72.16.2.1
set firewall filter PCAP term 2 then sample
set firewall filter PCAP term 2 then accept
set firewall filter PCAP term allow-all-else then accept 

And yes, after the capture is taken, download the file and open it with Wireshark. The file will be saved under /var/tmp/ directory.

Thanks epaniagua for your help.

As a last favour, Please share the commands to copy the file "testpacketcapture.ge-0.0.0 " from Branch SRX320 to DataCentre SRX1500

10.50.66.45 --------copy to -------------------->>> 172.16.2.1

Or to local PC kept within the branch. 

Hello,

You can scp the file from the shell of the Branch.

syntax: scp <src file location> username@IP:<dest file location>

scp /var/tmp/<filename> root@172.16.2.1:/var/tmp/

% scp /var/tmp/testpacketcapture.ge-0.0.0 root@172.16.2.1:/var/tmp/
The authenticity of host '172.16.2.1 (172.16.2.1)' can't be established.
ED25519 key fingerprint is 9d:a3:8b:a6:94:73:87:8f:26:06:53:07:cd:b3:dd:49.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.2.1' (ED25519) to the list of known hosts.
Password:
testpacketcapture.ge-0.0.0 100% 22KB 21.8KB/s 00:00

Regards,

Vikas

Thanks vvikas@juniper.net

It worked. 

Hello,

I have viewed the captured file with Wireshark, How do i interpret that there is something wrong with the IKE traffic?

What information could i exactly present to the ISP that the IKE traffic is not passing through ?

Hi AZkhan

Apply the following filter in Wireshark:

   ip.addr==10.50.66.45 && ip.addr==172.16.2.1

The results will be the communications between both firewalls. If you dont see IKE packets from 172.16.2.1 towards 10.50.66.45 then they were never received by the branch SRX and more likely were dropped in transit.

If you have any ISP modem on your branch side I will suggest to reboot it.

Hi epaniagua

I filtered the capture with " ip.addr==10.50.66.45 && ip.addr==172.16.2.1 && udp.port == 500 " to narrow down only ike traffic, and i just found one way traffic from 10.50.66.45 --------> 172.16.2.1, No replies from the other side. This means that the IKE requests are being initiated by the branch side but no response is being recieved from the other side.

Also appended the snapshot for your review. 

Thanks

AZkahn,

I dont see a file attached, can you check this.