Support Support Downloads Knowledge Base Service Request Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] Accessing fxp0 Out of Band management interfaces of a cluster over VPN

0

0

Article ID: KB30949 KB Last Updated: 27 Feb 2020Version: 3.0
Summary:

Fxp0 interfaces are meant to be for Out of Band management only. If we try to push transit traffic through it, the traffic will be dropped. This article explains how to access the Out of Band management interfaces of a cluster when coming from a VPN tunnel terminating on the SRX.

Symptoms:

The fxp0 interfaces are supposed to be Out of Band management interfaces. However, there is a specific requirement where the SRX nodes in a cluster need to be accessed on fxp0 from the other side of a VPN tunnel terminating on the SRX.

Cause:

Fxp0 interfaces are meant to be for Out of Band Management only. If we try to push transit traffic through it, the traffic will be dropped.

Solution:

Use this workaround to allow VPN users to get access to the fxp0 interfaces for managing the SRX cluster nodes.

Topology:

 
  • We would have to create a new reth interface and connect it to the switch of the fxp0 subnet and assign it an IP address of the same subnet.
  • RETH0 is in the untrust zone.
  • RETH1 is in trust zone.
  • RETH2 is the new reth interface which we have created and it is assigned to a new DMZ zone.
  • The IP addresses of FXP0 on node1, node 2 and the RETH2 are in the same management subnet 10.204.115.0/24 and connected to the management switch.
  • All Revenue ports are added in a new virtual router.
  • 10.204.115.254 - Default gateway for reth2 and management network.
  • st0.0 is the tunnel interface for the SRX1/2 cluster.
  • Backup router should be configured to access secondary node on fxp0 interface.

routing-instances {
         production-VR {
               instance-type virtual-router;
               interface reth0.0;
               interface reth1.0;
               interface reth2.0;
               interface st0.0;
               routing-options {
                   static {
                       route 192.168.3.0/24 next-hop st0.0;
                       route 10.0.0.0/8 next-hop 10.204.115.254;
                   }
         }
}
  • Create the VPN tunnel from that virtual router and add the management subnet to the VPN tunnel route.
  • The VPN tunnel has been made between the SRX1/SRX2 cluster and SRX3 using RETH0 as the external interface.
  • The remote subnet is 192.168.3.0/24 on the remote side of the VPN.
  • Put a route in the default VR pointing towards the management switch for reverse traffic.
  • In this scenario, only the fxp0 interface would be in the default routing instance and all the other interfaces would be in a different virtual router.
  • So, when the traffic would be received for the management subnet, it would do a lookup on the Virtual routing instance and forward it out the new reth interface.

VPN Configuration

security {
    ike {
       policy ike-policy {
               mode main;
               proposal-set standard;
               pre-shared-key ascii-text "$ABC123"; ## SECRET-DATA
        }
       gateway ike-gateway {
               ike-policy ike-policy;
               address 192.168.1.2;
               external-interface reth0.0;
       }
}
   ipsec {
       policy ipsec-policy {
              proposal-set standard;
        }
        vpn ipsec-vpn {
            bind-interface st0.0;
            ike {
               gateway ike-gateway;
               ipsec-policy ipsec-policy;
            }
        establish-tunnels immediately;
     }
}

Interface Configuration

reth0 {
   redundant-ether-options {
   redundancy-group 1;
  }
   unit 0 {
     family inet {
     address 192.168.1.1/24;
   }
}
}
reth1 {
   redundant-ether-options {
   redundancy-group 1;
   }
   unit 0 {
     family inet {
         address 192.168.2.1/24;
    }
}
}
reth2 {
   redundant-ether-options {
   redundancy-group 1;
   }
   unit 0 {
     family inet {
            address 10.204.115.115/24;
        }
   }
}

groups {
node0 {
interfaces {
      fxp0 {
         unit 0 {
             family inet {
                  address 10.204.115.108/24;
               }
         }
     }
}
}
node1 {
interfaces {
      fxp0 {
        unit 0 {
             family inet {
                   address 10.204.115.107/24;
               }
          }
     }
}
}
}

 

In this example, the traffic comes over the VPN tunnel and is decrypted after entering through the Reth0 interface. A route lookup sends it out the new Reth2 interface, where it reaches the destination Fxp0 interfaces traversing the switch.

Modification History:
2020-02-27: minor non-technical edits.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Security Alerts and Vulnerabilities

Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search