Hi, 

We have a SRX chassis cluster which are throwing input errors and we want to replace the cable. Can we replace the fabric link without causing any traffic disruption / failover if the nodes are healthy? 
Is there anything we need to verify before doing that?

show interfaces ge-0/0/0 extensive | match err 
  Link-level type: 64, MTU: 9014, Link-mode: Full-duplex, Speed: 1000mbps, BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled, Source filtering: Disabled,
  Input errors:
    Errors: 12600527, Drops: 0, Framing errors: 12600527, Runts: 0, Policed discards: 0, L3 incompletes: 0, L2 channel errors: 0, L2 mismatch timeouts: 0, FIFO errors: 0,
    Resource errors: 0
  Output errors:
    Carrier transitions: 3, Errors: 0, Drops: 0, Collisions: 0, Aged packets: 0, FIFO errors: 0, HS link CRC errors: 0, MTU errors: 0, Resource errors: 0
    CRC/Align errors                  12600527                0
    FIFO errors                              0                0
    Output packet error count                                 0
    Flow error statistics (Packets dropped due to): 
      Incoming NAT errors:               0
      User authentication errors:        0

Same with ge-13/0/0 output too

Appreciate any help.

Hi all,

May i know is it possible to block attack from Bot Scrapy just using IDP feature on SRX. Or it mandatory need Sky ATP?

https://www.distilnetworks.com/bot-directory/bot/scrapy/

Thanks and appreciate any help.

Hi there,

I have a srx-320 in a test environment with this config:

interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 10.20.30.2/29;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 10.20.31.1/24;
            }
        }
    }
}

I'm searching for a solution to have the same network address 10.20.31.0/24 on both ge-0/0/1 and ge-0/0/2. I have 2 switches and would like to connect each switch to each own port on the srx320. I'm prefer inet before ethernet switching if it's possible. Thank you for your help.

Hi,

I have issue where none of my servers are ping, ssh to each other. They are not able to ping the gateway eaither, but all can access the internet. I have a site to site VPN setup and that is working fine I can ping from my local PC and connect to these servers. I have the following set:

policy trust_to_any {
    match {
                    source-address any;
                    destination-address any;
                    application any;
                    from-zone trust;
                    to-zone any;
                }
                then {
                    permit;
                }
            }


security-zone trust {
            interfaces {
                reth0.0 {
                    host-inbound-traffic {
                        system-services {
                            https;
                            ping;
                            ssh;
                        }
                    }
                }
            }
        }

When I do the below command I get no results, even though on server 192.168.1.110 there is a constant ping to 192.168.1.120:

show security flow session protocol icmp
show security flow session source-prefix 192.168.1.110

Any ideas?

Hi, I am confused with this warning and cant find any information about it.

Below is the output when commiting from the primary node of our cluster. It warns that peers are not syncronized as below however then commits to both nodes. I have also checked the configurations on both and these are exactly the same. Below is also the out put from show chassis cluster control-pane statistics...

Any help would be greatly appreciated. Thanks

show chassis cluster control-pane statistics

Control link statistics:
Control link 0:
Heartbeat packets sent: 2842401
Heartbeat packets received: 2842317
Heartbeat packet errors: 0
Fabric link statistics:
Child link 0
Probes sent: 5712712
Probes received: 5712607
Child link 1
Probes sent: 0
Probes received: 0

{primary:node0}[edit]
XXXXX.XXXXXX@XXXXXXXX# commit synchronize-peers
warning: Peers are not configured to sync the configuration.
warning: Cannot find commit sync peers values, ignoring it
warning: Peers are not configured to sync the configuration.
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

Hi all

I am pretty new to Juniper and having issues setting up dynamic VPN:

pair of SRX210HE2 --- running JUNOS 12.3X48-D75.4
client computer1: Windows 10 1709 -- Pulse Client 5.1.5 (61437)
client computer2: Windows 10 1803 -- Pulse Client 5.2.7 (1025)

Used this document as reference: https://www.juniper.net/documentation/en_US/junos12.1/topics/example/vpn-security-dynamic-example-configuring.html

I can hit both:
https://PUBLIC-IP/dynamic-vpn
https://PUBLIC-IP/web

set access profile dyn-vpn-access-profile address-assignment pool dyn-vpn-address-pool
set access address-assignment pool dyn-vpn-address-pool family inet network 172.16.20.0/24
set access address-assignment pool dyn-vpn-address-pool family inet xauth-attributes primary-dns 8.8.8.8/32
set access profile dyn-vpn-access-profile authentication-order password
set access profile dyn-vpn-access-profile client user1.name firewall-user password "XXXXXXXXXXXXXXXXXXXXXXXXXX"
set access profile dyn-vpn-access-profile address-assignment pool dyn-vpn-address-pool
set web-authentication default-profile dyn-vpn-access-profile
set security ike policy ike-dyn-vpn-policy mode aggressive
set security ike policy ike-dyn-vpn-policy proposal-set standard
set security ike policy ike-dyn-vpn-policy pre-shared-key ascii-text "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
set security ike gateway dyn-vpn-local-gw ike-policy ike-dyn-vpn-policy
set security ike gateway dyn-vpn-local-gw dynamic hostname dynvpn
set security ike gateway dyn-vpn-local-gw dynamic connections-limit 10
set security ike gateway dyn-vpn-local-gw dynamic ike-user-type group-ike-id
set security ike gateway dyn-vpn-local-gw external-interface reth0.XXXX
set security ike gateway dyn-vpn-local-gw xauth access-profile dyn-vpn-access-profile
set security ipsec policy ipsec-dyn-vpn-policy proposal-set standard
set security ipsec vpn dyn-vpn ike gateway dyn-vpn-local-gw
set security ipsec vpn dyn-vpn ike ipsec-policy ipsec-dyn-vpn-policy
set security policies from-zone UNTRUST to-zone TRUST policy dyn-vpn-policy match source-address any
set security policies from-zone UNTRUST to-zone TRUST policy dyn-vpn-policy match destination-address any
set security policies from-zone UNTRUST to-zone TRUST policy dyn-vpn-policy match application any
set security policies from-zone UNTRUST to-zone TRUST policy dyn-vpn-policy then permit tunnel ipsec-vpn dyn-vpn
set security zones security-zone UNTRUST interfaces reth0.XXXX host-inbound-traffic system-services ike
set security zones security-zone UNTRUST interfaces reth0.XXXX host-inbound-traffic system-services https
set security zones security-zone UNTRUST interfaces reth0.XXXX host-inbound-traffic system-services ping

Created a VPN Profile on Pulse Client and connect:

Get the "certificate" chain is base on untrusted root warning
Connect
Type in:
user1.name
password

Pulse client keeps "connecting"

srx> show security flow session source-prefix MYCLIENTIP | refresh 5
Session ID: 21431, Policy name: AllowManagement/16, State: Active, Timeout: 1742, Valid
In: MYCLIENTIP/50396 --> SRX-IP/443;tcp, If: reth0.XXXX, Pkts: 10, Bytes: 1636
Out: SRX-IP/443 --> MYCLIENTIP/50396;tcp, If: .local..0, Pkts: 12, Bytes: 4809
Total sessions: 1
...

Configured following logs [ike-debug and kmd-logs] but nothing gets logged:

user@srx# set security ike traceoptions file ike-debug
user@srx# set security ike traceoptions flag all
user@srx# set security ipsec traceoptions flag all
user@srx# commit
user@srx# run clear log ike-debug

# set system syslog file kmd-logs daemon info
# set system syslog file kmd-logs match KMD
# commit

Pulse Client Log
'TM' Starting Phase 1 for reason = 'p_SRXIP_1_48666c8 IPSec Policy Group_SRXIP_48666 IKE SA Rule'
'TM' SAAction performed - name = 'p_SRXIP_1_48666c8IKE Negotiation Action' type = 'Negotiated IKEv5'
'TM' Calculated Refresh Lifetime = 25866 security
'TM' Calculated Refresh Lifetime = 0 KB
'TM' Marshal P1 Encryption = 7, Keylength = 128, Hash = 2, Group = 2, Lifetime = 28740 sec, Lifetime = 0 KB
'TM' MyID = FQDN: 'user1.name':0:17
'TM' --> SendInitialPacket Phase 1 packet ID=base
'TM' --> SEND IKE Message Size 405 to SRXIP:500
'TM' New Phase 1 Session (I) Created UID=0000000b with Peer UID=00000001
'TM' C_IKEPolicyAndPeer2::IndicateIKETunnelStatus(): IKE_PHASE1_STARTRXIP
'TM' onTMCallback(): no more status in the queue

I would really appreciate if anyone could point me in the right directions of tshoot this.

Thank you

I'm evaluating a VSRX appliance (v15.1X49) to look into the viability of using it for a remote location.  Up until now I've been having pretty good luck, but I'm having trouble getting a dynamic VPN built based on these instructions (https://www.juniper.net/documentation/en_US/junos/topics/topic-map/security-dynamic-vpns-with-pulse-secure-clients.html#id-dynamic-vpn-overview)

The problem I am running into is that when I try to start assigning the clients defined in the config with the dynamic VPN, it's acting like that part of the tree doesn't exist.  Specifically:

[edit security]
root# edit ?
Possible completions:
> address-book         Security address book
> advance-policy-based-routing  Configure advance-policy-based-routing rules
> alarms               Configure security alarms
> alg                  Configure ALG security options
> analysis             Configure security analysis
> application-firewall  Configure application-firewall rule-sets
> application-tracking  Application tracking configuration
> certificates         X.509 certificate configuration
> dynamic-address      Configure security dynamic address
> firewall-authentication  Firewall authentication parameters
> flow                 FLOW configuration
> forwarding-options   Security-forwarding-options configuration
> forwarding-process   Configure security forwarding-process options
> gprs                 GPRS configuration
> group-vpn            Group VPN configuration
> idp                  Configure IDP
> ike                  IKE configuration
> ipsec                IPSec configuration
> ipsec-policy         IPSec policy configuration
> log                  Configure security log
> nat                  Configure Network Address Translation
> pki                  PKI service configuration
> policies             Configure Network Security Policies
> resource-manager     Configure resource manager security options
> screen               Configure screen feature
> softwires            Configure softwire feature
> ssh-known-hosts      SSH known host list
> tcp-encap            Configure TCP Encapsulation.
> traceoptions         Network security daemon tracing options
> user-identification  Configure user-identification
> utm                  Content security service configuration
> zones                Zone configuration

Have I missed something earlier in the config, or is this just somethign that VSRX doesn't do?

I'm trying to troubleshoot a high memory situation on an SRX1500. I've got two of them running the same version of JUNOS (15.1X49-D110.4), with roughly the same config, but one is using a LOT more memory than the other.

Good box:

srx1> show chassis routing-engine
Routing Engine status:
    Temperature                 37 degrees C / 98 degrees F
    CPU temperature             37 degrees C / 98 degrees F
    Total memory              1954 MB Max   743 MB used ( 38 percent)
    Memory utilization          33 percent

Bad box:

srx2> show chassis routing-engine
Routing Engine status:
    Temperature                 36 degrees C / 96 degrees F
    CPU temperature             36 degrees C / 96 degrees F
    Total memory              1954 MB Max  1739 MB used ( 89 percent)
    Memory utilization          86 percent

I haven't been able to find any smoking gun in the config, and the nsd_chk_only log isn't throwing any answers at me, either. Every reference I can find in my searching online points to high CPU, not high memory. Anyone have any ideas on where to start looking?

Hey guys,

was looking some information to translate Cisco Configuration into SRX320 JunOS15.1x49-D110 configuration.

Those link,ike,ipsec,intf are in routing-instance virtual-router.

Tried to make my version of ipsec somehow when i tried to get "show security ike security-associtation" it turn out session is down.

root@WirelessGateway-POC> show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
2651109 DOWN   0498214c31fdd2d0  0000000000000000  Main           1.1.1.2

root@WirelessGateway-POC>

Here is CISCO config.

!
crypto ipsec profile Spoke-Profile-256
 set transform-set Spoke-Trans-Set-256
 set isakmp-profile Spoke-ISAKMP-Profile
!
crypto isakmp profile Spoke-ISAKMP-Profile
   keyring Spoke-Keyring
   match identity address 0.0.0.0 front-door
!
crypto ipsec transform-set Spoke-Trans-Set-256 esp-aes 256 esp-sha-hmac
 mode transport
!
crypto keyring Spoke-Keyring vrf front-door
  pre-shared-key address 0.0.0.0 0.0.0.0 key XXXX
!
!
interface GigabitEthernet0
 ip vrf forwarding front-door
 ip address 1.1.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface Tunnel10115005
 description "VRF_A_GRE CE#1" B2B
 ip address 100.66.1.9 255.255.255.254
 no ip redirects
 ip mtu 1400
 ip tcp adjust-mss 1360
 tunnel source 1.1.1.1
 tunnel destination 10.242.124.161
 tunnel key 10115005
 tunnel path-mtu-discovery
 tunnel vrf front-door
!
interface Loopback10115005
 description Management intf
 ip address 10.242.157.184 255.255.255.255

Here is my SRX320 config.

security {
    ike {
        proposal ike_proposals {
            authentication-method pre-shared-keys;
            dh-group group2;
            encryption-algorithm aes-256-cbc;
        }
        policy phase1_aes {
            mode main;
            proposals ike_proposals;
            pre-shared-key ascii-text "$9$xg27w2q.f6CpEc"; ## SECRET-DATA
        }
        gateway SRX320-to-WG {
            ike-policy phase1_aes;
            address 100.66.1.9;
            external-interface gr-0/0/0.0;
        }
    }
    ipsec {
        proposal ipsec_proposals {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-256-cbc;
        }
        policy ipsec_policy {
            proposals ipsec_proposals;
        }
        vpn VPN-To-TM-WG {
            bind-interface st0.0;
            ike {
                gateway SRX320-to-WG;
                ipsec-policy ipsec_policy;
            }
            establish-tunnels immediately;
        }
    }
    forwarding-options {
        family {
            inet6 {
                mode flow-based;
            }
        }
    }
    policies {
        default-policy {
            permit-all;
        }
    }
    zones {
        security-zone Trust {
            host-inbound-traffic {
                system-services {
                    all;
                }
                protocols {
                    all;
                }
            }
            interfaces {
                all;
            }
        }
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            description to-WG;
            family inet {
                address 1.1.1.1/24;
            }
        }
    }
    gr-0/0/0 {
        description GRE-Tunnel;
        unit 0 {
            description "webe_VRF_A_GRE CE#1";
            tunnel {
                source 1.1.1.1;
                destination 10.242.124.161;
                routing-instance {
                    destination front-door;
                }
            }
            family inet {
                address 100.66.1.9/31;
            }
        }
    }
    irb {
        unit 0 {
            family inet {
                address 192.168.1.1/24;
            }
        }
    }
    lo0 {
        unit 0 {
            family inet {
                address 10.242.157.184/32;
            }
        }
    }
    st0 {
        unit 0 {
            family inet;
        }
    }
}
routing-options {
    static {
        route 10.242.124.161/32 next-table front-door.inet.0;
    }
}
policy-options {
    policy-statement Advertise-VRF-BGP {
        term 1 {
            from {
                route-filter 10.242.157.184/32 exact;
            }
            then accept;
        }
        term 2 {
            then reject;
        }
    }
}
routing-instances {
    front-door {
        instance-type virtual-router;
        interface ge-0/0/0.0;
        interface gr-0/0/0.0;
        interface lo0.0;
        routing-options {
            static {
                route 10.242.124.161/32 next-hop 1.1.1.2;
            }
            router-id 1.1.1.1;
            autonomous-system 64628;
        }
        protocols {
            bgp {
                group eBGP-IPv4 {
                    type external;
                    export Advertise-VRF-BGP;
                    peer-as 23736;
                    local-as 64628;
                    neighbor 100.66.1.8;
                }
            }
        }
    }
}

Hello Team,

We have two SRX3400 in a cluster (member 0 and member1)at DC-DR respectively.  

we have a scheduled activity where only DR devices we will be power-off.

How I can power off only DR firewall (member1) from cluster. 

Right now when I hit "request system power-off" command it power-off complete cluster (DC-DR firewall).

I have a SRX220 which has been configured with an ISP1 (ge-0/0/0 --> address xxx.xxx.xxx.253/24). I'm also using a standard IKE/IPSEC VPN tunnel:

st0 {
    unit 1 {
        family inet;
    }
}

ike {

...

    gateway ike-gate-cfgr2 {

        ...

        external-interface ge-0/0/0.0;

    }

}

By using the default static routing: "route 0.0.0.0/0 next-hop xxx.xxx.xxx.1;" in the past, everything just worked fine.

I now ordered and installed a second internet line ISP2 (ge-0/0/1 --> address yyy.yyy.yyy.178/29)

and changed the static routing to:

routing-options {

  static {

     route 0.0.0.0/0 next-hop [ xxx.xxx.xxx.1 yyy.yyy.yyy.177 ];

   }

  forwarding-table {

     export LOAD-BALANCE;

   }

}

policy-options {
    policy-statement LOAD-BALANCE {
        then {
            load-balance per-packet;
        }
    }
}

I also added the ISP2 zone, the IPS2 policies, and updated NAT to [ISP1 ISP2]. Since having done these changes, my VPN tunnel is doing some crazy things I do not understand. Here what I can see:

- The VPN tunnel still comes up and remains stable.

- Changing the static routing from "route 0.0.0.0/0 next-hop xxx.xxx.xxx.1;" to "route 0.0.0.0/0 next-hop [ xxx.xxx.xxx.1 yyy.yyy.yyy.177 ];" keeps the tunnel working. I can send and receive data and everything just looks fine.

- As soon as I re-boot the SRX220, the tunnel comes up again, however, no data is transferred and/or received.

- As soon as I change the static routing back to "route 0.0.0.0/0 next-hop xxx.xxx.xxx.1;", the vpn tunnel immediately works again. I even can change it to "route 0.0.0.0/0 next-hop [ xxx.xxx.xxx.1 yyy.yyy.yyy.177 ];" without lossing that behavior.

I think I have reached a level, where I need some expert help. Does anybody know, where my mistake is?

Thanks.

Wilfried

PS: If somebody provides professional hourly support, please send me your contact data (WilfriedPeters@peprivate.com). Unfortunately Juniper does not offer this kind of help any more.

Hi All

 I confess to knowing Cisco, but not Juniper so looking for advice on a solution I've inheritted whereas I think I've worked out the issue:

 VOIP Server -> SRX340 Cluster (WAN HUB) -> Circuit -> SRX320 CPE -> Handsets

 WAN HUB is a SRX cluster in Flow mode, all ALG turned off, all Interfaces Trusted
 CPE is in Flow mode, all ALG Turned off, All Interfaces Trusted.

 The problem:  When VOIP calls originate from an external SIP provider, IE: wheras the VOIP server acts as a proxy, we see a frequent, but intermittent 8 second delay within the RTP stream on initiation (ie: no audio, then after 8 seconds or so its fine).

 All other VOIP is fine - ie: handset to other sites on the wan, handset to remote phones registered to the PBX, its only when the VOIP Server proxies the call we see this.

 Now, I believe the SRX should be in packet mode, however reading this: https://forum.ivorde.com/juniper-srx-packet-mode-how-to-switch-between-flow-mode-and-packet-mode-t19681.html - its not good to do that if they are in a chassis cluster (they are) - and they are remote to me.

 Now, reading this:  https://forums.juniper.net/t5/SRX-Services-Gateway/SRX240-in-flow-mode-and-SIP-ALG-issue/td-p/310419  - this suggests with ALG disabled, SIP OPTIONS aren't passed - which would explain why we only see the issue when the VOIP server is proxying.

 So the question is - my current thought here is enable SIP / RTSP ALG based on the thread above  - but what would be the communities thoughts on this ?

 Any advice appreciated, this issue may not be the Junipers, but any advice appreciated (and I am rapidly coming to love the Junipers)

Chris

Hello there,

I have a device connected to my network that should be accessed by the port 3000.

It is in my internal network and I can ping it properly.

The problem is that I cannot access the device using the proper software because it does not respond.

I think it is because my Juniper SRX300 is blocking the 3000 port somehow.

Is there anyway to see if it is blocking or not?

How can I unblock it?

Kind regards.

I have the following 2 firewall filters; how can the config. below be corrected to allow the second filter to work?

firewall {
    filter VPN {
        term VPN {
            from {
                source-address {
                    #SECRET#;
                }
                destination-port 500;
            }
            then accept;
        }
        term IKE-BLOCK {
            from {
                destination-port 500;
            }
            then {
                reject;
            }
        }
        term else {
            then accept;
        }
    }
    filter External-HTTPS {
        term Whitelist {
            from {
                source-prefix-list {
                    whitelist;
                }
                destination-port 443;
            }
            then accept;
        }
    }
}

Hi Everybody, I followed some KB and online reference and set the lab to test FBF function. During the ping test, the original packets hit the ingress interface filter and the counter is grow up but the reverse packets are dropped in the another ingress interface due to no "No route present". After setting the default route in inet.0, the ping test is success.

I really want to know why the reverse packets do not follow the reverse route lookup.

interface
ge-0/0/0 {
    unit 0 {
        family inet {
            address 114.114.114.114/24;
        }
    }
}
ge-0/0/1 {
    unit 0 {
        family inet {
            address 192.168.1.2/30;
        }
    }
}
ge-0/0/3 {
    unit 0 {
        family inet {
            filter {
                input From-ZoneA;
            }
            address 172.17.3.5/30;
        }
    }
}
ge-0/0/4 {
    unit 0 {
        family inet {
            filter {
                input From-ZoneB;
            }
            address 172.17.3.1/30;
        }
    }
}

firewall
family inet {
    filter From-ZoneB {
        term 0 {
            from {
                destination-address {
                    192.168.98.0/24;
                    192.168.99.0/24;
                }
            }
            then {
                routing-instance 2nd-router;
            }
        }
        term other {
            then accept;
        }
    }
    filter From-ZoneA	{
        term 0 {
            from {
                source-address {
                    192.168.99.0/24;
                }
            }
            then {
                count access;
                routing-instance 2nd-router;
            }
        }
        term other {
            then accept;
        }
    }
}

routing-instance
2nd-router {
    instance-type forwarding;
    routing-options {
        static {
            route 192.168.98.0/24 next-hop 172.17.3.6;
            route 192.168.99.0/24 next-hop 172.17.3.6;
            route 172.17.128.0/24 next-hop 172.17.3.2;
            route 0.0.0.0/0 next-hop 172.17.3.6;
        }
    }
}

routing-options
interface-routes {
    rib-group inet 2nd-router;
}
static {
    route 0.0.0.0/0 next-hop 114.114.114.1;
	route 192.168.0.0/16 next-hop 192.168.1.1; ## This route must not be removed.
	route 192.168.98.0/24 next-hop 172.17.3.6; ##After adding this route here2, ping success

}
rib-groups {
    2nd-router {
        import-rib [ inet.0 2nd-router.inet.0 ];
    }
}

admin@SRX220> show firewall filter counter access From-ZoneA

Filter: From-ZoneA
Counters:
Name                                                Bytes              Packets
access                                             319980                 5333



admin@SRX220> show interfaces ge-0/0/4.0 extensive
  Logical interface ge-0/0/4.0 (Index 75) (SNMP ifIndex 526) (Generation 140)
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Traffic statistics:
     Input  bytes  :             73890779
     Output bytes  :             34590868
     Input  packets:               589864
     Output packets:               460282
    Local statistics:
     Input  bytes  :              1712652
     Output bytes  :              2000700
     Input  packets:                22731
     Output packets:                22730
    Transit statistics:
     Input  bytes  :             72178127                  472 bps
     Output bytes  :             32590168                  712 bps
     Input  packets:               567133                    0 pps
     Output packets:               437552                    1 pps
    Security: Zone: ZoneB
    Allowed host-inbound traffic : ping ntp
    Flow Statistics :
    Flow Input statistics :
      Self packets :                     21817
      ICMP packets :                     257049
      VPN packets :                      0
      Multicast packets :                0
      Bytes permitted by policy :        50492026
      Connections established :          8038
    Flow Output statistics:
      Multicast packets :                0
      Bytes permitted by policy :        34245820
    Flow error statistics (Packets dropped due to):
      Address spoofing:                  0
      Authentication failed:             0
      Incoming NAT errors:               0
      Invalid zone received packet:      0
      Multiple user authentications:     0
      Multiple incoming NAT:             0
      No parent for a gate:              0
      No one interested in self packets: 0
      No minor session:                  0
      No more sessions:                  0
      No NAT gate:                       0
      No route present:                  1103
      No SA for incoming SPI:            0
      No tunnel found:                   0
      No session for a gate:             0
      No zone or NULL zone binding       0
      Policy denied:                     2810
      Security association not active:   0
      TCP sequence number out of window: 0
      Syn-attack protection:             0
      User authentication errors:        0
    Protocol inet, MTU: 1500, Generation: 162, Route table: 0
      Flags: Sendbcast-pkt-to-re
      Input Filters: From-ZoneB
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 172.17.3.0/30, Local: 172.17.3.1, Broadcast: 172.17.3.3, Generation: 160

Hello,

Would someone please explain the concept of SCP & NPC as i read many articles here and couldn't understand..

i understand there is a midplane &the FPC is plugged in the midplane and IOC are plugged in the FPC.

But how it works regarding SPC & NPC & IOC.

Thanks in advance

Hi all

I have just deployed a VMWare vSRX appliance (ESXi 6.5U1 and ESXi 6.5U2), and my problem is that I can't get a functional fxp0 interface to ssh to the thing and configure it.

Things I've checked:

Virtual network adaptor 1 is in the correct portgroup on ESXi.

The MAC of virtual network adaptor 1 matches the mac you get from a "show interface fxp0"

Another VM in the same portgroup can be reached OK.

Promiscuous mode is enabled on the vSwitch.

So I'm reasonably sure that the network config within the environment is OK.  This has been added to an existing ESXi setup with plenty of networks and uplinks; nothing else has ever given us a problem like this.

I also tried installing on another ESXi cluster just in case there was a specific issue with the hypervisor in 6.5U2 - I see exactly the same problem.

Troubleshooting this, I (logically) connected fxp0 to a spare NIC on another test VM on the same ESXi host, and captured packets on the test VM, and then try and ping the test VM. I see the ARP request going out from the vSRX, and the test VM responding with its MAC address.  This repeats.  On the vSRX, the mac address *does not* appear in show arp.

However, if I place the vSRX fxp0 into a "busy" network subnet, "show arp" *does* show learned mac addresses that the vSRX has seen (I'm guessing it populates the ARP table with gratuitous ARP replies that come past on the network).

The combination of the above two suggest that this isn't a specific tx or rx problem, it can clearly do both - but not function as expected.

I have tried vSRX versions 18.2R1.9 and 15.1X49-D140, and have tried this on ESXi clusters with distributed switches as well as standard vSwitches.

Here's how I got to where I am:

1) Installed the vSRX appliance (deploy the OVF with all defaults).

2) Connect my virtual network adaptors to the correct networks (have tried various combinations of them being connected and disconnected) - the test network being a single port group permitting all VLANs, with the vSRX fxp0 at one end and the test VM's second NIC at the other; basically as close as I can get to a bit of cat5 between a physical SRX and a laptop for testing.

3) Add config:

set system host-name vsrx1

set system root-authentication plain-text-password

set interfaces fxp0 unit 0 family inet address 192.91.199.1/24

4) Try and ping 192.91.199.2 (this is the test VM mentioned)

5) Observe this traffic on 192.91.199.2:

15:17:14.483826 00:50:56:ab:66:d1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.91.199.2 tell 192.91.199.1, length 46
15:17:14.483844 00:50:56:93:d8:32 > 00:50:56:ab:66:d1, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.91.199.2 is-at 00:50:56:93:d8:32, length 28
15:17:15.381605 00:50:56:ab:66:d1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.91.199.2 tell 192.91.199.1, length 46
15:17:15.381636 00:50:56:93:d8:32 > 00:50:56:ab:66:d1, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.91.199.2 is-at 00:50:56:93:d8:32, length 28
15:17:16.081673 00:50:56:ab:66:d1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.91.199.2 tell 192.91.199.1, length 46
15:17:16.081693 00:50:56:93:d8:32 > 00:50:56:ab:66:d1, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.91.199.2 is-at 00:50:56:93:d8:32, length 28
15:17:16.781737 00:50:56:ab:66:d1 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 192.91.199.2 tell 192.91.199.1, length 46
15:17:16.781767 00:50:56:93:d8:32 > 00:50:56:ab:66:d1, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Reply 192.91.199.2 is-at 00:50:56:93:d8:32, length 28

Checking in the ARP cache on the vSRX at this point just shows:

The source mac is fxp0 on the vSRX:

(Apologies for photos, that's all I can get from the console!)

I'm familiar with the hardware SRX, but this is the first time I've used the vSRX platform - so it is likely I'm missing something really obvious.  Does anyone have any idea what stupid thing I'm doing (or not doing?)

Thanks

Paul.

We saw the new unified security policies that were released with 18.2 and wanted to test them out thinking it would help some of the issues we have had with the appFW before and for easier creation of security policies with applications as part of the match criteria. I know this is pretty new so not sure how many people are utilizing this.

In or scenario for easy testing, we want a security policy that permits the SIGNAL private messenger app with no SSL proxy enabled.  My assumption was that we could create a security policy with the match for the SIGNAL app and not apply the SSL proxy under the advanced services. SSL proxy is enabled on our default rule which breaks the cert pinning in the signal messaging app. This kind of scenario for us seems to be common with pinned certs in an application and attempting to exclude it from inspection.

In our test, we have a SRX340 running 18.3R1.9 and I have a security policy as listed below..... This is not working or matching in the logs. In the logs I can see it identifies the applciation as SIGNAL-PRIVATE-MESSENGER. The traffic never hits this policy and instead hits the default rule we have created. Yes, this rule is in higher sequence than the default outbound rule.

policy SSL-Exempt-Apps {
    match {
        source-address lan-net;
        destination-address any;
        application any;
        dynamic-application [ junos:SIGNAL junos:SIGNAL-PRIVATE-MESSENGER ];
    }
    then {
        permit;
        log {
            session-close;
        }
    }
}






<14>1 2018-11-13T11:58:14.531-05:00 Alpha-SRX340-AT29686712 RT_FLOW - APPTRACK_SESSION_CLOSE [junos@2636.1.1.1.2.135 reason="TCP FIN" source-address="x.x.x.x" source-port="1479" destination-address="52.203.236.220" destination-port="443" service-name="junos-https" application="SSL" nested-application="SIGNAL-PRIVATE-MESSENGER" nat-source-address="x.x.x.x" nat-source-port="10439" nat-destination-address="52.203.236.220" nat-destination-port="443" src-nat-rule-name="source-nat-rule" dst-nat-rule-name="N/A" protocol-id="6" policy-name="Default_Outbound_Traffic" source-zone-name="trust" destination-zone-name="untrust" session-id-32="15210" packets-from-client="6" bytes-from-client="644" packets-from-server="7" bytes-from-server="1872" elapsed-time="2" username="testuser" roles="testgroup" encrypted="No" profile-name="N/A" rule-name="N/A" routing-instance="default" destination-interface-name="ge-0/0/0.0" uplink-incoming-interface-name="N/A" uplink-tx-bytes="0" uplink-rx-bytes="0" category="Messaging" subcategory="miscellaneous" apbr-policy-name="N/A"]