ProteusElite:HowTo Proteus Networks Proteus Elite:HowTo Page 1

Transcription

1 Setting up an Out of Band Management Network on an SRX In this guide I describe one of the many methods of creating an out-of-band management network for the SRX Series Services Gateways. Background In Netscreen implementations there was no issue with the security policy logs and syslog traffic. Both could be sent to the same destination from the same port on the firewall. In the SRX Branch Office devices this remains the same. For the SRX data center devices a different management network must be created. The reason is based in the way traffic is handled in the high end SRX devices. In these devices the sessions are handled by the line card processors. The logs for that traffic are, by default, never seen by the routing engine. In the normal operation syslog traffic for alarms and other management traffic is generated by the RE and sent to the syslog server(s) identified in the system syslog stanza. The security log traffic on the high end SRXs is handled by the security log stanza. This means that the RE traffic port (syslog traffic) and a revenue port (security log traffic) have to be assigned to the management network. This of course causes problems because two interfaces from a router (SRX) can not be in the same subnet. There are a number of options that can be implemented that solve this dilemma. Option 1 Send security log traffic to the RE By changing the mode of the security log traffic from stream to event (set security log mode event) the RE receives these logs as an eventd message and processes them to the syslog server(s) as defined. The up side to this option is that dual interfaces and dual syslog stanzas are avoided. The down to this option is that the RE can quickly become over burdened with the traffic. JTAC warns that if this implementation is used the SRX should not support the Jweb GUI, multiple dynamic routing protocols or dynamic routing protocols with multiple areas. This warning should be enough to make you pause and think of other options. Option 2 Create a separate virtual router for security log traffic By creating a virtual router and installing the security log traffic interface in that router, the address conflict can be addressed. The source address setting in the security log stanza identifies the interface in the virtual router and a static route in the inet.0 table points to the virtual router. The upside of this approach is that it allows traffic to be sent to the same subnet for both RE syslog messages and PFE security log messages. The down side is that is adds complexity to the configuration and could cause a routing loop if return traffic is sent to the VR interface that is intended for the fxp0 interface. This option is explored in detail below. Options 3 Separate the logging servers and management servers on different subnets In this approach a duplicate address problem is solved by using different subnets for the different functions of the out of band network. In the SRX, the syslog server and the security log server can be the same box, but the subnet of the fxp0 port is different than the subnet of the security log port. The up side is that all default settings are used on the SRX. the down side is that a network design is being forced on the customer by the capabilities of the SRX. This option is explored in detail below. Procedure Option 2 In this approach we create a virtual router and house the security log port on that virtual router. This will allow both interfaces to be members of the same network and not create a routing problem in the SRX. In the following configuration steps can be used for this approach. In this example the syslog server and the security log server are on the same device Proteus Networks Proteus Elite:HowTo Page 1

2 1. Create a virtual router for the security log interfaces routing-instances { VR_mgt { interface ge-1/1/2.0; routing-options { static { route /0 next-hop ; ## gateway of the management network ### Figure 1 Virtual Router Configuration 2. Create a normal fxp0 interface and a syslog stanza pointing to a syslog server ( ) fxp0 { address /24; syslog { user * { any emergency; host { any any; Figure 2 SYSLOG Stanza 3. Create a security log interface and security log stanza point to the VR_mgt interface. interface { ge-1/1/2 { speed 1g; link-mode full-duplex; description "Security log Interface"; address /24 { primary; 2011 Proteus Networks Proteus Elite:HowTo Page 2

3 security { security-zone manage_syslog { ge-1/1/2.0; log { source-address ; stream Security_log { severity info; category all; host { ; Figure 3 Security and Interface Configuration Figure 4 Reference Diagram Option 3 In this approach we create a second management subnet that is used for security log traffic. The security log server is located on this subnet, while the syslog server and other management sevices (NSM) are located on the normal management network. In the following configuration steps can be used for this approach. 1. Create a normal fxp0 interface and a syslog stanza pointing to a syslog server ( ) 2011 Proteus Networks Proteus Elite:HowTo Page 3

4 fxp0 { address /24; syslog { user * { any emergency; host { any any; Figure 5 SYSLOG and Interface config ProteusElite:HowTo 2. Create a security log interface and security log stanza point to the security log server interface { ge-1/1/2 { speed 1g; link-mode full-duplex; description "Security log Interface"; address /24 { primary; security { security-zone manage_syslog { ge-1/1/2.0; log { source-address ; stream Security_log { severity info; category all; host { ; 2011 Proteus Networks Proteus Elite:HowTo Page 4

5 Figure 6 Security Config Conclusion Figure 7 Option 3 Reference Diagram Due to the limitations of the architecture, an out-of-band management is a necessity for the high end SRX devices. There are many options that are available for setting up the OOB network and none are simple. This set of sets will allow you to determine which is right for your network Proteus Networks Proteus Elite:HowTo Page 5