Hi,

I have been asked to upgrade a good bunch of live srx210H2s to the recommnded junos version but I have never done this before and don't have a test SRX to test it on.

Upgrade will be from 12.1X44-D15.5 to 12.3X48-D65.

I got to the point of getting an image to the SRX /var/tmp folder, did a checksum confirmation and I am ready for "request system software add /var/tmp/junos-srxsme-12.3X48-D65.1-domestic.tgz no-validate reboot"  ... but now I am a bit concerned if the config will compatible or do I have to upgrade to the intermidate verions.

will "request system software add /var/tmp/junos-srxsme-12.3X48-D65.1-domestic.tgz validate" just check if the config will have no issues and it is safe to procced or will it install the new firmware and give a message with any issues?

Please advise.

Thanks you

Hi,

I am trying to setup a VPN connection through GoogleCLoud from office location. The phase1 seems to be up but IKEPhase2 does not seem to be up. I turned on the debug and searched for the error messages but could not find anything. Does antbody has an idea on the issue please ?

The debug error messages are :

ay 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ssh_ikev2_sav1_select: Proposals do not match
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] P2 SA payload match failed for sa-cfg VPN-GCP. Aborting negotiation for tunnel local:64.13.163.35 remote:35.196.82.3 IKEv1.
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ikev2_fb_spd_select_qm_sa_cb: IKEv2 SA select failed with error No proposal chosen
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ikev2_fb_spd_select_qm_sa_cb: SA selection failed, no matching proposal (neg c49000)
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_qm_sa_reply: Start
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ikev2_fallback_negotiation_free: Fallback negotiation c49000 has still 2 references
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_state_restart_packet: Start, restart packet SA = { 84211c9d 4b8cf302 - ae045fad b0b5e00a}, nego = 11
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_state_step: Current state = Start QM R (15)/5, exchange = 32, auth_method = any, Responder
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_st_i_qm_sa_proposals: Start
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_st_i_private: Start
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_st_o_qm_hash_2: Start
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_st_o_qm_sa_values: Start
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_state_restart_packet: Error, send notify
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] <none>:500 (Responder) <-> 35.196.82.3:500 { 84211c9d 4b8cf302 - ae045fad b0b5e00a [11] / 0x9244da74 } QM; Error = No proposal chosen (14)
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_alloc_negotiation: Start, SA = { 84211c9d 4b8cf302 - ae045fad b0b5e00a}
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_alloc_negotiation: Found slot 12, max 13
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_init_info_exchange: Created random message id = 76f13ae3
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_init_info_exchange: Phase 1 done, use HASH and N or D payload
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_encode_packet: Start, SA = { 0x84211c9d 4b8cf302 - ae045fad b0b5e00a } / 76f13ae3, nego = 12
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_encode_packet: Encrypting packet
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_encode_packet: Final length = 124
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_send_notify: Sending notification to 35.196.82.3:500
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_send_packet: Start, send SA = { 84211c9d 4b8cf302 - ae045fad b0b5e00a}, nego = 12, dst = 35.196.82.3:500, routing table id = 0
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_delete_negotiation: Start, SA = { 84211c9d 4b8cf302 - ae045fad b0b5e00a}, nego = 12
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_free_negotiation_info: Start, nego = 12
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ike_free_negotiation: Start, nego = 12
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] IPSec negotiation failed for SA-CFG VPN-GCP for local:64.13.163.35, remote:35.196.82.3 IKEv1. status: No proposal chosen
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] P2 ed info: flags 0x0, P2 error: No proposal chosen
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ikev2_fallback_negotiation_free: Fallback negotiation c49000 has still 1 references
May 11 00:20:48 [64.13.163.35 <-> 35.196.82.3] ikev2_fallback_negotiation_free: Freeing fallback negotiation c49000

> show configuration security ike

traceoptions {
file ike-trace;
flag all;
}
proposal hq {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm 3des-cbc;
lifetime-seconds 86400;
}

proposal IKE-PROP-1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-128-cbc;
lifetime-seconds 86400;
}
policy hq {
mode main;
proposals hq;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}

policy IKE-POLICY-GCP {
mode main;
proposals IKE-PROP-1;
pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
}
gateway hq {
ike-policy hq;
address 12.xxx.yy.zzz;
local-identity hostname xxxx.yyyy.com;
remote-identity hostname aaaa.bbb.net;
external-interface reth0.1298;
}

gateway IKE-PEER-GCP {
ike-policy IKE-POLICY-GCP;
address 35.196.82.3;
external-interface reth0.1298;
version v1-only;
}

> show configuration security ipsec 

proposal hq {
protocol esp;
authentication-algorithm hmac-sha-256-128;
encryption-algorithm 3des-cbc;
lifetime-seconds 28800;
}

proposal IPSEC-PROP-1 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-128-cbc;
lifetime-seconds 3600;
}
policy hq {
proposals hq;
}

policy IPSEC-POLICY {
proposals IPSEC-PROP-1;
}
vpn hq {
ike {
gateway hq;
ipsec-policy hq;
}
establish-tunnels immediately;
}

establish-tunnels immediately;
}
vpn VPN-GCP {
bind-interface st0.0;
ike {
gateway IKE-PEER-GCP;
ipsec-policy IPSEC-POLICY;
}
establish-tunnels immediately;
}

Hi,

Please find below Network topology and suggest suitable option to achieve ISP link failover/traffic diversion on firewall

1) For internet request core switch has default route towards SRX340

2)For MPLS request core switch has static route towards SRX240

3) SRX340 (HA) has default route towards ISP

4) SRX240 (packet mode - Primary and secondary) has VRF configuration to achieve ISP link failover

Here my query is - On SRX340 if ISP link failed internet traffic should routed to SRX240. If i tracert from internet router towards SRX240, first hop is SRX240 ge-0/0/3 interface IP.

We can directly connect one more cable from SRX240 to SRX340 or RPM configuration with next hop ge-0/0/3 interface. My main concern is routing. how packet will be traverse.

Thank you...

Hi all,

Let's say i have 20 security zone and each security zone have zone-to-zone policy. Each security policy have around 300 policy. If want to add new policy let say block TCP_450 and need to apply at all the security policy zone-to-zone at the top of policy then how to do like that? If using global policy then i will read as last. If create a "apply-group policy" and bind it to security policy then it still read as last policy right?

Thanks and appreciate any feedback

Hello,

I'm slowly getting my feet wet with JunOS as described in this earlier post: 

https://forums.juniper.net/t5/ScreenOS-Firewalls-NOT-SRX/Moving-away-from-SSG-ScreenOS-to-SRX-JunOS-best-way-to-proceed/m-p/322890#M32632

Over the past week, I have successfully inserted an SRX between my SSG and the ISP's equipment.

At this time, the SRX purely performs 1-to-1 static NAT for the SSG.

Now I'm noticing that IPSec VPNs configured between the SSG and other ScreenOS appliance reconnected immediately.

However, VPNs configured between SSG and remote SRX devices take *forever* to reconnect/pass traffic. Like 15-20 agonizing minutes or more.

Barring any misconfigurations, the VPNs typically show as 'up' on the remote SRX side, as I'm initiating ping traffic from my SSG side.

As I frantically checked and re-checked the configs on both sides, I did notice that anytime I add or remove a proxy ID check on both sides, the VPN auto-magically starts passing traffic upon commit.

What gives?

Any insight would be appreciated.

Hi,

SRX320 supports Group VPNv2, I would like to ask whether SRX320 supports ECDSA (256/384 bit) Authentication or not ?

Thanks in advance. Regards

I dont have a basic layer three connectivity between my two juniper srx210. I have two interfaces directly connected to each other, yet they cant ping each other. I will attach the config please let me know what I am doing wrong.

aabdulr2# run show configuration
## Last commit: 2018-05-12 21:39:31 UTC by aabdulr2
version 12.1X44-D35.5;
system {
root-authentication {
encrypted-password "$1$rdyA1q4X$qgkB.rb9I252lF9kT3H4q/"; ## SECRET-DATA
}
name-server {
208.67.222.222;
208.67.220.220;
}
login {
user aabdulr2 {
uid 2003;
class super-user;
authentication {
encrypted-password "$1$GyQmW9Kw$/zy7vBUhKqZQs7jJPLUaq1"; ## SECRET-DATA
}
}
}
services {
ssh;
telnet;
xnm-clear-text;
web-management {
http {
interface vlan.0;
}
https {
system-generated-certificate;
interface vlan.0;
}
}
inactive: dhcp {
router {
192.168.1.1;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.2 high 192.168.1.254;
}
propagate-settings ge-0/0/0.0;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
}
max-configurations-on-flash 5;
max-configuration-rollbacks 5;
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.2/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.2/24;
}
}
}
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
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;
}
then {
source-nat {
interface;
}
}
}
}
}
}
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
security-zone untrust {
screen untrust-screen;
}
}
}

and for R2

aabdulr2> show configuration
## Last commit: 2018-05-12 21:22:18 UTC by aabdulr2
version 11.2R4.3;
system {
root-authentication {
encrypted-password "$1$mqFiB.CD$K2.1ChYJMPmk0Az/MKlN8/"; ## SECRET-DATA
}
name-server {
208.67.222.222;
208.67.220.220;
}
login {
user aabdulr2 {
uid 2003;
class super-user;
authentication {
encrypted-password "$1$4Tfka88U$tMLnvxLATCtomUOeh40T7/"; ## SECRET-DATA
}
}
}
services {
ssh;
telnet;
xnm-clear-text;
web-management {
http {
interface vlan.0;
}
https {
system-generated-certificate;
interface vlan.0;
}
}
inactive: dhcp {
router {
192.168.1.1;
}
pool 192.168.1.0/24 {
address-range low 192.168.1.2 high 192.168.1.254;
}
propagate-settings ge-0/0/0.0;
}
}
syslog {
archive size 100k files 3;
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
}
max-configurations-on-flash 5;
max-configuration-rollbacks 5;
license {
autoupdate {
url https://ae1.juniper.net/junos/key_retrieval;
}
}
}
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.0.0.1/30;
}
}
}
lo0 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
}
security {
screen {
ids-option untrust-screen {
icmp {
ping-death;
}
ip {
source-route-option;
tear-drop;
}
tcp {
syn-flood {
alarm-threshold 1024;
attack-threshold 200;
source-threshold 1024;
destination-threshold 2048;
timeout 20;
}
land;
}
}
}
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;
}
then {
source-nat {
interface;
}
}
}
}
}
}
policies {
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
}
zones {
security-zone trust {
host-inbound-traffic {
system-services {
all;
}
protocols {
all;
}
}
}
security-zone untrust {
screen untrust-screen;
}
}
}

Dear all,

I have googled how to import certificate which exported from AD to SRX devices for SSL-proxy but no luck.

Hope I can have some advises here.

Thank you so much!

Tuan

Hi

i have the following problem since we switch from sophos to juniper srx.

We have a server with one public ip addresse. This server start an ikev1 with public ip. The ipsec connection also use the public ip as subnet for tunnel (traffic selector). This for very well with sophos, but since we switch to juniper the connection will not work.

Then we have add an dummy ip address and switch the trafficselector to the dummy ip address. Now the connection with dummy ip works, too.

The problem is that i can't switch the default ip address for only for vpn outgoing connections on the server.

Anybody know why juniper doesn't allow same ip address for vpn tunnel and traffic selector?

Hope to get solution

I have given ISP block xx.70.190.30/30 with 128 Public IP in different subnet on the gateway of primary ISP subnet xx.70.190.29.

when i tried to map public IP to internal server due to subnet in different network proxy-arp not functioning they way used to to.

Wondering if any way to map on SRX for 128 public IP series,

Hi guys,

in the following source NAT policy what does it means "destination-port 25"? it means"destination port 25 both UDP and TCP protocols"? and if yes, what about if I want to apply the NAT policy only for the TCP protocol?

set security nat source rule-set nat_set_333 rule CICCIO_rule_13 match source-address-name s1.1.1.1
set security nat source rule-set nat_set_333 rule CICCIO_rule_13 match destination-address-name s2.2.2.2
set security nat source rule-set nat_set_333 rule CICCIO_rule_13 match destination-port 25
set security nat source rule-set nat_set_333 rule CICCIO_rule_13 then source-nat pool snat-3.3.3.3

I have a branch office with a cluster of SRX220H2s that recently started exhibiting flapping issues with the secondary node in the cluster.  Every 5-10 minutes, the secondary node will be kicked out of the cluster, then added several minutes later, before starting the cycle over.  We've tried hard booting the secondary node to see if it would join and stick in the cluster, but it doesn't seem to help.

Additionally, I've noticed that the control-plane cpu on the primary node is consistently at 100%, with the jsrpd process consuming an awful amount of resources.  We have a number of essentially identical branch clusters elsewhere, none of which have jsrpd consuming high resources.  I know that that process is involved with the cluster process, in terms of messaging.  Checking the jsrpd logs, I'm seeing something very unusual:

May 14 16:55:04 TCP-S: accepted client connection.
May 14 16:55:04 TCP-S: TCP client from 130.16.0.1/56547 connected
May 14 16:55:04 TCP-S: TCP peer closed connection
May 14 16:55:04 last message repeated 100 times (hit threshold of (100))
May 14 16:55:04 last message repeated 200 times (hit threshold of (200))
May 14 16:55:04 last message repeated 300 times (hit threshold of (300))
May 14 16:55:04 last message repeated 400 times (hit threshold of (400))
May 14 16:55:04 last message repeated 500 times (hit threshold of (500))
May 14 16:55:04 last message repeated 600 times (hit threshold of (600))
May 14 16:55:05 last message repeated 700 times (hit threshold of (700))
May 14 16:55:05 last message repeated 800 times (hit threshold of (800))

Here's the system process extensive command output:

show system processes extensive
node0:
--------------------------------------------------------------------------
last pid: 47616;  load averages:  1.28,  1.26,  1.42  up 431+22:43:27    16:59:15
140 processes: 19 running, 108 sleeping, 2 zombie, 11 waiting

Mem: 210M Active, 149M Inact, 1036M Wired, 145M Cache, 112M Buf, 432M Free
Swap:

  PID USERNAME  THR PRI NICE   SIZE    RES STATE  C   TIME   WCPU COMMAND
 1403 root        5  76    0   996M 58812K RUN    0    ??? 102.20% flowd_octeon_hm
 1406 root        1 139    0 14096K  7032K RUN    0 727.7H 76.66% jsrpd
   22 root        1 171   52     0K    16K RUN    0 7574.2  0.00% idle: cpu0
   23 root        1 -20 -139     0K    16K RUN    0 118.8H  0.00% swi7: clock
    5 root        1 -16    0     0K    16K rtfifo 0  42.7H  0.00% rtfifo_kern_recv
   25 root        1 -40 -159     0K    16K WAIT   0  40.4H  0.00% swi2: netisr 0
 1413 root        1  76    0 12452K  5768K select 0  33.9H  0.00% license-check

show chasis cluster interfaces:

Control link status: Up

Control interfaces:
    Index   Interface        Status   Internal-SA
    0       fxp1             Up       Disabled

Fabric link status: Up

Fabric interfaces:
    Name    Child-interface    Status
                               (Physical/Monitored)
    fab0    ge-0/0/5           Up   / Up
    fab0
    fab1    ge-3/0/5           Up   / Up
    fab1

Redundant-ethernet Information:
    Name         Status      Redundancy-group
    reth0        Up          1
    reth1        Up          1
    reth2        Up          1

Redundant-pseudo-interface Information:
    Name         Status      Redundancy-group
    lo0          Up          0

Interface Monitoring:
    Interface         Weight    Status    Redundancy-group
    ge-3/0/0          255       Down      1
    ge-0/0/0          255       Up        1

{primary:node0}

last 100 of show log chassisd

show log chassisd | last 100
May 14 16:39:58 SCC: pseudo_create_devs_swfab: Skipping creation of swfab1, since fabric presence is set to true
May 14 16:39:58 SCC: lcc_detach_interfaces_not_online lcc 1
May 14 16:39:58 CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(3)
May 14 16:39:58 CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(4)
May 14 16:39:58 CHASSISD_IFDEV_DETACH_FPC: ifdev_detach_fpc(5)
May 14 16:40:06 SCC: pfpc ready fpc 3 i2c 1897
May 14 16:40:06 SCC: fpc 3 clean, bringing online
May 14 16:40:06 SCC: lcc_send_fpc_online_cmd_generic:  lcc 1 fpc 0
May 14 16:40:06 SCC: pic_online_req for fpc 3, pic 0  lcc_slot 1 in lcc_recv_pic_online_req
May 14 16:40:06 SCC: lcc_send_pic_online_ack: On Switch-chassis: fpc 3 pic 0 pic_type 0x669 msg_len 20 tlv_len 0
May 14 16:40:06 SCC: From SCC send: fru 13361152 lcc_slot 1 online ack to LCC
May 14 16:40:06 SCC: From Switch-Chassis send: fpc 3 pic 0 online ack to LCC
May 14 16:40:08 SCC: lcc_recv_pic_attach: pic attach pic 0, flags 0x0, portcount 8, fpc 3
May 14 16:40:08 SCC: pic_set_online: i2c 0x669 pic 0 fpc 3 state 5 in_issu 0
May 14 16:40:08 SCC:  pic_type=1641 pic_slot=0 fpc_slot=3 pic_i2c_id=1641

May 14 16:40:08 SCC: fpc slot 3 pic_present 0x0 => 0x1
May 14 16:40:08 SCC: FPC 3 PIC 0, attaching clean
May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 0

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 0
May 14 16:40:08 SCC: Created pic for ge-3/0/0

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 1

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 1
May 14 16:40:08 SCC: Created pic for ge-3/0/1

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 2

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 2
May 14 16:40:08 SCC: Created pic for ge-3/0/2

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 3

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 3
May 14 16:40:08 SCC: Created pic for ge-3/0/3

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 4

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 4
May 14 16:40:08 SCC: Created pic for ge-3/0/4

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 5

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 5
May 14 16:40:08 SCC: Created pic for ge-3/0/5

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 6

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 6
May 14 16:40:08 SCC: Created pic for ge-3/0/6

May 14 16:40:08 SCC: Creating pic entry, baseport 0, nports 8, port 7

May 14 16:40:08 SCC: create_pic_entry: pic i2c 0x669, hw qs 8 supported qs 8, flags 0x0, pic port 7
May 14 16:40:08 SCC: Created pic for ge-3/0/7

May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/0
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/0
May 14 16:40:08 SCC: ge-3/0/0: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/1
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/1
May 14 16:40:08 SCC: ge-3/0/1: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/2
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/2
May 14 16:40:08 SCC: ge-3/0/2: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/3
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/3
May 14 16:40:08 SCC: ge-3/0/3: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/4
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/4
May 14 16:40:08 SCC: ge-3/0/4: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/5
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/5
May 14 16:40:08 SCC: ge-3/0/5: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/6
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/6
May 14 16:40:08 SCC: ge-3/0/6: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 CHASSISD_IFDEV_CREATE_NOTICE: create_pics: created interface device for ge-3/0/7
May 14 16:40:08 SCC: ifdev_create entered ge-3/0/7
May 14 16:40:08 SCC: ge-3/0/7: large delay buffer cleared
May 14 16:40:08 SCC: fpc_is_q_neompc: no valid ideeprom for slot 3
May 14 16:40:08 SCC: fpc_is_q_sangria: no valid ideeprom for slot 3
May 14 16:40:08 SCC: PIC (fpc 3 pic 0) message operation: add. ifd count 8, flags 0x3 in mesg
May 14 16:40:08 LCC: ignoring PIC message on LCC

For the moment, I've disabled the ports on the switch for the second node (node1) that keeps flapping, just so I don't keep seeing it go on and off, but can renable if needed. 

Any thoughts are appreciated!

Dear Juniper lovers,

I am currenlty searching for a solution to provide layer2 connectvity over vdsl. Our provider doesn't deliver a pure layer2 link. We need to use PPPoe to setup a link to our backbone. We currently have layer3 in service on this setup.

Due to the lower MTU, PPPoe, we need to use a GRE/IPSec to avoid dropping MPLS frames. I would also that we don't have mpls up to the end-customer. Due to the IPsec, the performance increases a lot.

CPE = SRX branch series

Backbone = MX / QFX5100 / EX

I was wondering which technologies you are using to build the layer 2 ? Layer 2 GRE to MPLS backbone ? Radius attributes ? Is there a solution for this setup ?

Looking forward..

Greetings

Hi,

I've some problem, maybe some bug or think like that configuring SkyATP using Junos Security Director.

I'd like to understand if someone of you has got the same issue.

The problem is after I configured threat prevention policy on Security Director and try to push the policy receveing:

[Error] Configuration update failed. 

Severity : error 
           At : [edit services advanced-anti-malware] 
Message : Missing mandatory statement: 'match' 
  Details : policy SkyATP_DMZ 

After that then, I try to configure manually by cli the missing part about "match" -> "then" and commit using CLI is working correctly.

The problem is that any future configuration on the security directory, it's trying to remove every times:

##Security Firewall Policy : junos-host - contact##
delete security policies from-zone junos-host to-zone contact policy PolicyEnforcer-Rule1-1
##Advanced AntiMalware Policy Configurations##
delete services advanced-anti-malware policy SkyATP_DMZ match 
delete services advanced-anti-malware policy SkyATP_DMZ then 
delete services advanced-anti-malware policy SkyATP_DMZ inspection-profile 
delete services advanced-anti-malware policy SkyATP_DMZ default-notification 
delete services advanced-anti-malware policy SkyATP_DMZ whitelist-notification 
delete services advanced-anti-malware policy SkyATP_DMZ blacklist-notification 

Reaching at the end the same commit error due match then statement missing.

The curious thing is that security directory is applying the correct template (I read that from 15.x version match then statement is not any longer required), but in my vSRX if I try to configure following the guide line, I can't find the correct command as espressed.

Here my configuration:

connection {
    url https://srxapi.eu-west-1.sky.junipersecurity.net;
    authentication {
        tls-profile aamw-ssl;
    }
}
policy SkyATP_DMZ {
    match {
        application HTTP;
        verdict-threshold recommended;
    }
    then {
        action permit;
        notification {
            log;
        }
    }
    inspection-profile default_profile;
    fallback-options {
        action permit;
        notification {
            log;
        }
    }
    default-notification {
        log;
    }
    whitelist-notification {
        log;
    }
    blacklist-notification {
        log;
    }
}

root@vSRXdmzserver> show configuration services security-intelligence
url https://10.20.20.203:443/api/v1/manifest.xml;
url-parameter "$9$pXdQBhrKMXbYoxNz36C0OEhSyv824ZH.fRhx-bYoaZGDHm536CtuBoJ9tuBhcbwYgGjqm539pX7H.PQ6/X7Nb4JiH.f5zX7sgoZiHn69COIyrKWXNLxH.mf3nREcr8XVw2oZDz37dsYaJGUjiPT6/AIRc-VqP5z9C"; ## SECRET-DATA
authentication {
    auth-token GQ5A1SNB1T0TO29PJPXKPFGYZKKCWJUO;
}
profile SkyATP_DMZ_CC {
    category CC;
    rule Rule-1 {
        match {
            threat-level [ 1 2 3 4 ];
        }
        then {
            action {
                permit;
            }
            log;
        }
    }
    rule Rule-2 {
        match {
            threat-level [ 5 6 7 ];
        }
        then {
            action {
                permit;
            }
            log;
        }
    }
    rule Rule-3 {
        match {
            threat-level [ 8 9 10 ];
        }
        then {
            action {
                block {
                    drop;
                }
            }
            log;
        }
    }
}
profile SkyATP_DMZ_Infected-Hosts {
    category Infected-Hosts;
    rule Rule-1 {
        match {
            threat-level [ 1 2 3 4 5 6 ];
        }
        then {
            action {
                permit;
            }
            log;
        }
    }
    rule Rule-2 {
        match {
            threat-level [ 7 8 9 10 ];
        }
        then {
            action {
                block {
                    drop;
                }
            }
            log;
        }
    }
}
policy SkyATP_DMZ {
    CC {
        SkyATP_DMZ_CC;
    }
    Infected-Hosts {
        SkyATP_DMZ_Infected-Hosts;
    }
}

root@vSRXdmzserver> show services advanced-anti-malware statistics
Advanced-anti-malware session statistics:
  Session interested:    1014
  Session ignored:       691
  Session hit blacklist: 0
  Session hit whitelist: 0
                         Total         HTTP          HTTPS
  Session active:        0             0             0
  Session blocked:       0             0             0
  Session permitted:     322           322           0

Advanced-anti-malware file statistics:
                                Total         HTTP          HTTPS
  File submission success:      0             0             0
  File submission failure:      1             1             0
  File submission not needed:   823           823           0
  File verdict meets threshold: 0             0             0
  File verdict under threshold: 0             0             0
  File fallback blocked:        0             0             0
  File fallback permitted:      1             1             0
  File hit submission limit:    0             0             0

The above configuration has been perfromed by CLI due the problem with Security Directory.

Any suggestion?

Regards

A customer has an SRX with 2 virtual routers in packet mode. There are no interfaces in the default instance. I have been asked to confugre Jflow to monitor traffic of one of the interfaces within one of the VRs. The sampling server is routable from this instance. Is there a way to get this to work without having a loopback interface in the default instance and having to perform route leaking? I know this is acheivable with route leaking but this is not desirable in this case.

Also it appears the sampling configuration within the routing instance (routing-insance r1 forwarding-options sampling) has no function, only the global sampling configuration (forwarding-options sampling) seems to work. 

I'm having trouble establishing a route-based multipoint tunnel from an SRX5400 running 12.3x48 code to an ISG1000, pretty sure the issue is on the SRX side. The security association appears to be up on both sides, but I can't pass any traffic over it. Here is the output from looking at the SRX SA:

show security ipsec security-associations index 131090 detail
node1:
--------------------------------------------------------------------------

ID: 131090 Virtual-system: root, VPN Name: JAXS
Local Gateway: x.x.132.44, Remote Gateway: x.x.72.44
Local Identity: ipv4(any:0,[0..3]=x.x.132.44)
Remote Identity: ipv4(any:0,[0..3]=x.x.72.44)
Version: IKEv1
DF-bit: copy, Bind-interface: st0.1
Port: 500, Nego#: 3581, Fail#: 3566, Def-Del#: 0 Flag: 0x600a21
Tunnel events:
Tue May 15 2018 21:31:36: IPSec SA rekey successfully completed (1 times)
Tue May 15 2018 21:31:36: IKE SA negotiation successfully completed (17 times)
Mon May 14 2018 21:41:43: IPSec SA negotiation successfully completed (2 times)
Mon May 14 2018 21:41:33: Tunnel configuration changed. Corresponding IKE/IPSec SAs are deleted (1 times)
Mon May 14 2018 21:33:28: IPSec SA negotiation successfully completed (1 times)
Mon May 14 2018 21:33:24: Tunnel configuration changed. Corresponding IKE/IPSec SAs are deleted (1 times)
Mon May 14 2018 20:15:27: IPSec SA negotiation successfully completed (1 times)
Mon May 14 2018 20:15:22: IPSec SA delete payload received from peer, corresponding IPSec SAs cleared (1 times)
Mon May 14 2018 07:36:17: IPSec SA negotiation successfully completed (1 times)
Location: FPC 0, PIC 1, KMD-Instance 2
Direction: inbound, SPI: c1f70cac, AUX-SPI: 0

It appears to be up, right? The only issue I can find is that sometimes the following error message appears :

"IPSec negotiation failed with error: Received nexthop-tunnel IP address from peer, is not in  bind-interface's subnet. Negotiation failed. "

Does this mean that the tunnel interfaces on both sides of the VPN need to be in the same subnet? I have been able to successfully build tunnels from Netscreen to Netscreen using different tunnel interface subnets, so I'm not sure swhy it wouldn't work Netscreen to SRX.

Please let me know if you need more information.

Hey Team,

Topology: 

Spoke A ------------ipsec tunnel-------------Hub-------------ipsec tunnel------------Spoke B

Scenario: Migration from SSG to SRX

When sending traffic from spoke A to Spoke B Lan side, there is packet loss between 10-20% over the VPN. No packet loss is observer when pinging Hub side using MPLS addresses on which Ipsec vpn runs. Route based vpn.

All three devices are SRXes. 

Spoke A: 

PING 172.24.11.33 (172.24.11.33): 56 data bytes

64 bytes from 172.24.11.33: icmp_seq=2 ttl=252 time=69.842 ms

64 bytes from 172.24.11.33: icmp_seq=3 ttl=252 time=60.986 ms

64 bytes from 172.24.11.33: icmp_seq=6 ttl=252 time=59.521 ms << seq 4 and 5 never made it.

On Hub side:

I see three being processed in traces:

May 16 03:26:23 03:26:23.381298:CID-01:FPC-01IC-00:THREAD_ID-26:RT:<172.24.8.93/3->172.24.11.33/3712;1> matched filter pf1:

May 16 03:26:23 03:26:23.381341:CID-01:FPC-01IC-00:THREAD_ID-26:RTacket [84] ipid = 35815, @0xf8cbc914

but then traces move to seq 6: 

May 16 03:26:26 03:26:26.384147:CID-01:FPC-01IC-00:THREAD_ID-10:RT:<172.24.8.93/6->172.24.11.33/3712;1> matched filter pf1:

May 16 03:26:26 03:26:26.384182:CID-01:FPC-01IC-00:THREAD_ID-10:RTacket [84] ipid = 35846, @0xfc31f114

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

Also, 

Also, policy denied counters were increasing consistently on hub side when SRX devices were being used on the spoke side instead of SSG from which we migrated during the window:

 run show interfaces st0.28 statistics detail | match policy     

      Bytes permitted by policy :        152998034129

      Bytes permitted by policy :        170287121600 

      Policy denied:                     24433

run show interfaces st0.28 statistics detail | match policy    

      Bytes permitted by policy :        152998051349

      Bytes permitted by policy :        170287132067 

      Policy denied:                     24436

But nothing in the policies which would drop the traffic. 

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

Spoke B is communicating fine with other Spokes and no packet loss.

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

When change is rolled back on Spoke A side not to use SRX and go back to SSG no more packet loss and those counters dont increase any more. To rollback move the cabes, disable enable interfaces and update vpn monitoring on hub rest configuration including st0 interfaces stays same on hub side.

Both Spoke A , Hub are running 12.3X48 D 50.6 which is standard across all the devices. 

Any help would be really appreciated.