Disable Juniper Ports


How to shutdown a Juniper switchport or interface.  This simple JUNOS task frustrates Cisco-minded folks.  So where does JUNOS hide the shutdown command?


"Disable" is the JUNOS command for "shutdown".  Examples:

     Disable:        root@host> set interface ge-0/0/1 disable
     Enable  root@host> del set interface ge-0/0/1 disable

That's it!

Clear BGP Sessions


How to reset BGP peering and re-announce BGP routes.  Inbound traffic is supposed to traverse through the preferred ISP.  However, traffic splits between different ISPs after maintenance or short outages.


Clear BGP sessions to update BGP routes after an outage or maintenance.


     clear bgp neighbor soft

This processes re-announces BGP routes to upstream neighbors. Clear a BGP session whenever inbound/outbound policy changes are made; or after outages or maintenance.



That's it!

Juniper SRX DNS Proxy Issues Over the VPN

Problem:  JUNOS DNS-Proxy resolution does not work over the VPN.

  • DNS name resolution only resolves external domain names (i.e. Internet).
  • SRX DNS proxy does not resolve internal/ local domains from DNS server on other side of the VPN..
  • Ping requests fail from the SRX (i.e., DNS-Proxy) to the remote VPN site.
       For Example, SRX2 cannot ping any node behind SRX1 via VPN.
  • All ping requests from the SRX fail without specifying exit interface.  
  • Ping request from nodes on either side of the VPN are successful.  Routing and VPN work.
Topology:  The DNS proxy and DNS server are on separate sides of the VPN.

  • SRX1 is at the data center.  Its site hosts the primary domain controller (DC) and DNS servers.
  • SRX2 is at the branch office.  
  • The SRX2 site does not have a local DC or DNS server.  It uses a split-tunnel VPN and split-brain DNS proxy for internal and external name resolution

Solution:  Assume routing, DNS-Proxy and firewall configurations are OK.   The problem is with how the SRX chooses its default address.  Specify the default address for s should fix the problem:

set system default-address-selection
Next, assign the loopback interface with a routed IP address.
set interface lo0 unti 0 family inet address
N.B., Planning to use the DNS proxy with an public DNS server (e.g.,  Don't forget to create a corresponding NAT statement:

[edit security nat]
rule-set self-internet {
from zone junos-host;
to zone UNTRUST;
rule RE-untrust {
match { source-address;
then {
source-nat {
Reason:  The DNS proxy service uses the SRX loopback interface (lo0) for its source address.  The default lo0 addess is  Traffic isn't going to go far with that address!  Everything works if you assign lo0 with an IP address from your default VLAN!

N.B., This fixes all other issues with ICMP, FTP, etc., across the SRX to VPN as well.


Prevent Rouge Access Points: Wireless IDS/ IPS

Wireless Threat Detection and Countermeasures:  Monitor and Protect Your Wireless Access Points.

Takeaway:  Automated countermeasures discover, attack, and disable rouge Wi-Fi devices! This article explores Wireless Access Controllers, Intrusion Detection Systems (IDS), and Intrusion Prevention Systems (IPS).   These instructions explain how to enable countermeasures for Juniper Wireless Controllers (WLCs).  Cisco, Aruba, and other controllers offer similar mitigation.  

Problem:  Corporate networks are vulnerable to rouge wireless technology.  Wireless access points (WAPs), wireless routers, and wireless bridges can extend the corporate network and provide an insecure entry point.  Untrusted wireless technology risks data integrity and confidentiality.

Internal and External Rouge Wireless Threats.

Threats:  Internal threats include unapproved wireless devices that extends or bridges the corporate network.  For example, an employee may install a residential WiFi router to provide network access to their smartphone.  Their intent may not be malicious but it nonetheless exposes the network to compromise.

Hackers or wireless devices in proximity to corporate access points are external threats.  External threats can intercept and harm company data.  Additional threats can entirely disrupt wireless communication (Table 1).  

Enable Countermeasures:  The WLC includes countermeasures that attack rouge devices.  These countermeasures consist of packets that disrupt client communications to rouge devices.   Rouge devices are rendered useless once the WLA initiates an attack.  WLC countermeasures are disabled by default.  Enable countermeasures on all rouge devices:

LocalWLC#set radio-profile default countermeasures rogue
Alternately, enable countermeasures on all rouge and interfering devices:

LocalWLC#set radio-profile default countermeasures all

Enable ad-hoc countermeasures if desired:

LocalWLC#set rfdetect classification ad-hoc rogue 

Configure SSID list to whitelist existing SSIDs:

LocalWLC#set rfdetect ssid-list BIZ_SSID
Enable log messages to display on console:

LocalWLC#set rfdetect log enable
N.B., Interfering devices may include neighboring APs using the same radio channels.  The WLC includes RF Auto-Tuning that changes WLA channels as needed.  Consider rouge-only countermeasures when located near other businesses. 

Rouge Classifications:  The WLC identifies all nearby 802.11 wireless devices.  It uses a classification system to detect rouge devices: 

LocalWLC# sh rfdetect classification
Rule      Rules for RF Classification             Classification
----     ---------------------------              --------------
N      1. If AP in Rogue list ....................... ROGUE
N      2. If AP is part of Mobility Domain .......... MEMBER
N      3. If AP in Neighbor list .................... NEIGHBOR -------------------------------------------------------------------
Y      4. If AP is Masquerading our SSID ............ ROGUE
Y      5. Client or Client DST MAC seen in network .. ROGUE
Y      6. If AP is acting as an Ad-hoc device ....... SKIP-TEST -------------------------------------------------------------------
N      7. If SSID is in SSID list ................... NEIGHBOR -------------------------------------------------------------------
Y      8. Default Classification .................... SUSPECT

Rouge List:  The WLC attacks all devices in the Rouge list.  The WLA does not transmit client traffic while it attacks rouge devices.  WLAs can be provisioned in Sentry mode for dedicated scanning and attacking purposes.

Suspect List:  Devices in the Suspect list are considered potential Rouges.  The WLC does not attack suspect devices unless they become a threat.  In most circumstances, suspect devices are neighbor APs which have not been manually added to the Neighbor list.

Neighbor List:  The Neighbor list acts as a whitelist.  The WLC does not attack its neighbors.  Be a good Samaritan and add your neighbors' APs to the Neighbor list.  The Juniper WLC GUI makes identifying and adding neighbors a cinch.

Juniper WLC GUI:  RF Neighbors

 Countermeasures in Action:  What happens if an employee connects a wireless AP to the corporate network?  For this example, assume the switch access ports are not configured for 802.1X authentication or BPDU Guard.

1.  Employee discretely connects a Linksys wireless router to the network. 
Employee adds unapproved wireless access point to company network.

2.  The Linksys router connects to the company network and advertises its SSID:

3.  The Linksys SSID remains in the Suspect list as long as clients are not connected it.
4.  The employee connects their laptop to the Linksys SSID.  The WLC immediately identifies the Linksys AP as a rouge device:

ROGUE Sep 24 11:11:26.009242 NOTICE ROGUE_AP_ALERT: Client Mac 88:XX:XX:XX:XX:XX(Rogue AP Mac 00:XX:XX:XX:XX:XX) is seen on the wired network by Switch on port X vlan X tag 0. Detected by listener a8:XX:XX:XX:XX:XX(AP 1, radio 1), channel 6 with RSSI -55 SSID "linksys".
5.  The WLC begins its countermeasure attack:

ROGUE Sep 24 11:12:35.065652 NOTICE ROGUE_AP_ALERT: COUNTERMEASURES STARTED for Xmtr Mac 00:XX:XX:XX:XX:XX Performer Mac a8:XX:XX:XX:XX:XX SW-I Paddr AP 1 Radio 1 Channel 6
6.  Confirm countermeasures:

WLC# sh rfdetect countermeasures Total number of entries:1
          Type(Adhoc/Infra) Countermeasures                        Port/Radio
Rogue MAC         /Class    Radio Mac        RSSI MX IPaddr        /Channel ----------------- -------- ----------------- ---- --------------- ------------ 00:XX:XX:XX:XX:XX I/rogue  a8:XX:XX:XX:XX:XX -59       AP 1/1/6

WLC Detected a Rouge SSID
Conclusion:  Tests confirm wireless clients cannot connect to rouge SSIDs when WLC countermeasures are enabled.  Interestingly, the WLC countermeasures are similar to those available on some WiFi hacking tools.  These countermeasures compliment existing mitigation strategies;  Enterprise WPA2, 802.1X authentication;  BYOD Policy, client and server certificate authentication; disabling client auto-connect; Windows IPSec, etc... 

Table 1. Wireless Threats and Mitigation.
Type of Attack

RF Jamming
DoS - Flooding
Overwhelms WLAN with high-power noise.
WLA detects excessive interference on a channel.  WLC Auto-Tuning changes the radio to a different channel.

De-authenticate frames
DoS Precursor to Identity Spoofing
Basis for man-in-the-middle attacks.  Spoofing changes source MAC so frames appear to come from a legitimate AP.

WLA checks packets for the source MAC address. 

Broadcast De-authenticate Frames
DoS Precursor to Identity Spoofing
Spoofs de-authenticate frames to disconnect all clients attached to an AP.
WLA checks for de-authenticate broadcast frames.

Disassociation frames
DoS Precursor to Identity Spoofing
Disassociation frames from an AP instructs clients to end their association to AP.

WLA checks for  disassociation frames

Null probe response
Rogue devices send probe response with null SSID.  NICs can lock up upon null probe responses.

WLA checks for Null probe responses.

Decrypt Errors
 Identity Spoofing
Rogue device pretends to be a legitimate device by spoofing the MAC address.
WLA checks for excessive number of decrypt errors.  This indicates multiple clients are using the same MAC address.

Fake APs
Rouge device sends beacon frames for excessive SSIDs or BSSIDs.  Clients cannot connect to valid Aps.

WLA check for excessive beacon frames.

Fake SSIDs
 Identity Spoofing -MITM
Rouge device pretends to be a legitimate SSID in your network.  Clients associate with rouge SSID.

WLA checks for APs masquerading as company SSID.

Spoofed WAPs
 Identity Spoofing -MITM
Rouge device pretends to be legitimate AP by changing its MAC source address.
WLC detects spoofed AP attacks based on AP fingerprint.  WLA signatures must be enabled to detect AP spoofing.

Netstumbler and Wellenreiter
Hacker applications gather information about APs, location, manufacturer, and encryption.

WLC syslog warnings identify Netstumbler and Wellenreiter.

Wireless Bridge
Identity Spoofing
Extends network to personal or rouge devices.
 WLA identifies internal wireless bridges.

Ad-Hoc Networks
Identity Spoofing
Client Wireless NICs extend network to personal or rouge devices.

 WLA identifies internal Ad-Hoc Networks.

Weak WEP Keys
Brute Force Vulnerability
Network systems vulnerable to attacks.
WLC syslog warnings identify clients using weak WEP. 

 Note:  IDS console messaging and SNMP alerts are additional mitigation features.  WLAs are configured to actively scan for threats (i.e. Active Scan) by default.

Table 2.  Rouge Determination

Wireless AP, bridge, or ad-hoc Network

Does the device have a known MAC address from the wired network?

Does the destination header contain a known MAC from the wire network?

Does the SSID belong to the SSID list?

Is the device use a Juniper transmitter?

Does the client or AP MAC address on the blacklist?

Does the client or AP MAC address belong to the Rouge list?

Does the client or AP MAC address belong to the Neighbor list?

References:  Juniper Mobility System  Software Configuration Guide

BGP Troubleshooting Artifact

Artifact:  Demonstrate the value of ICT methodology.
By Steven Jordan on 11/26/2013.

Abstract:  This document identifies a BGP routing problem that resulted in unstable peering relationships, routing instability, and excessive route flaps.  The document also serves as an artifact to demonstrate the value of ICT methodology.  

Background:  Customers, all from the same organization, complained of poor web site usability.  Symptoms of the problem were described as slow loading web pages,  limited functionality, and an excessive delay of data enumeration.  To be clear, the problem only affected this particular organization. 

Solution:  Troubleshooting, using ICT methodology, identified a problem at the customer's location.  I sent the following email that outlined the resolution process:

Dear Kathy,
It was a pleasure speaking with you on the telephone.  I wish it were under better circumstances.  I am writing to outline the network problem that prevents staff at your location from connecting to our network.

My research indicates there may be a problem with your organization’s local Internet connection and related routing issues.  There are two influencing factors: 

     1.  Network tests sourced from your organization indicate packet loss; well before traffic reaches our servers.  The problem may be sourced from your organization or from an upstream ISP.
·         A ping test measured bits of data sent and received from your location to our hosted web site.  We found approximately 25% of the data was dropped en route.
·         A trace route documented the path the packet traveled across the Internet.  We found there were over 10 separate network hops from your organization to our servers (not unusual).  Each “hop” represents a different Internet Service Provider (ISP) router.

·       A separate PING test to each hop indicated that 25% of the data was lost.  We are reasonably certain that 25% of all data sent from your location is lost; from at least the CenturyLink/Quest hop.  Our server farm is located several hops upstream from the Quest network.
      2.  There may be BGP routing problems with your organization's network.  There were multiple BGP route announcements sourced from your network today.

The Internet uses a routing protocol called Boarder Gateway Protocol (BGP).  Your organization uses BGP to host a single IP subnet with multiple ISPs.  If the primary ISP is unavailable the network will failover to the secondary ISP, while still using the same IP subnet. 

I determined there were hundreds of route updates and withdraws that continued up until 6/30/2013 at 3:21:PM PST.  The following graph is a snap shot of the multiple paths to your organization’s network from external ISPs:

There were excessive route flaps and instability during this time-frame.  I suspect there are still unintended BGP peering relationships to your organization’s network.  Multiple inbound paths from different ISPs may cause data loss.  I cannot provide further details because I am not familiar your organization’s private network.  I can confirm that the problem is severe enough to interfere with our service.  Unless the problem is resolved, your staff will begin to notice issues from other web sites as well.

Earlier today, I spoke with Bob from your IT department’s help desk.  Bob was very helpful as he assisted with some of the network tests.  It is my understanding that Bob planned to escalate the issue based on the ping and trace route tests.  I also encourage you to forward this email to the appropriate network department to assist the escalation process.  Re-announcing the BGP routes to upstream ISPs should resolve the network instability. 

Please contact me with any questions.  This issue is important to me and I will do whatever I can to help make our service accessible to your staff.  Please call my cell phone any time this evening if I can be of assistance.


Steven M. Jordan
Network Administrator