Screen OS

Hey guys,

I'm stuck in a bit of a pickle.  We're hosting two Dell servers that require dual redundancy on everything (including our firewall configuration).

The set up is as follows:

What we want to do is set up VRRP between the two SSG5 devices so that when the primary fails, the slave takes over.  My question is, is it possible to do this type of configuration on VRRP?  Another thing I've read is that we may need NSRP.  Being that I'm still learning all of this networking stuff, I'm not quite sure how to go about this whole proceedure.  Google and Juniper's documentation aren't being as helpful as I have hoped. 

For good measure, here's the config file of the primary device:

unset key protection enable
set clock ntp
set clock timezone -8
set clock dst recurring start-weekday 2 0 3 02:00 end-weekday 1 0 11 02:00
set vrouter trust-vr sharable
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
unset auto-route-export
exit
set alg appleichat enable
unset alg appleichat re-assembly enable
set alg sctp enable
set auth-server "Local" id 0
set auth-server "Local" server-name "Local"
set auth default auth server "Local"
set auth radius accounting port 1646
set admin name "username"
set admin password "password"
set admin http redirect
set admin auth web timeout 10
set admin auth dial-in timeout 3
set admin auth server "Local"
set admin format dos
set zone "Trust" vrouter "trust-vr"
set zone "Untrust" vrouter "trust-vr"
set zone "DMZ" vrouter "trust-vr"
set zone "VLAN" vrouter "trust-vr"
set zone id 100 "VPN1"
set zone id 101 "VPN2"
set zone "Untrust-Tun" vrouter "trust-vr"
set zone "Trust" tcp-rst
set zone "Untrust" block
unset zone "Untrust" tcp-rst
set zone "MGT" block
unset zone "V1-Trust" tcp-rst
unset zone "V1-Untrust" tcp-rst
set zone "DMZ" tcp-rst
unset zone "V1-DMZ" tcp-rst
unset zone "VLAN" tcp-rst
unset zone "VPN1" tcp-rst
unset zone "VPN2" tcp-rst
set zone "Untrust" screen tear-drop
set zone "Untrust" screen syn-flood
set zone "Untrust" screen ping-death
set zone "Untrust" screen ip-filter-src
set zone "Untrust" screen land
set zone "V1-Untrust" screen tear-drop
set zone "V1-Untrust" screen syn-flood
set zone "V1-Untrust" screen ping-death
set zone "V1-Untrust" screen ip-filter-src
set zone "V1-Untrust" screen land
set interface ethernet0/2 phy full 100mb
set interface ethernet0/3 phy full 100mb
set interface ethernet0/4 phy full 100mb
set interface ethernet0/5 phy full 100mb
set interface ethernet0/6 phy full 100mb
set interface "ethernet0/0" zone "Untrust"
set interface "ethernet0/1" zone "Null"
set interface "bgroup0" zone "Trust"
set interface "tunnel.1" zone "VPN1"
set interface "tunnel.2" zone "VPN2"
set interface bgroup0 port ethernet0/2
set interface bgroup0 port ethernet0/3
set interface bgroup0 port ethernet0/4
set interface bgroup0 port ethernet0/5
set interface bgroup0 port ethernet0/6
unset interface vlan1 ip
set interface ethernet0/0 ip 10.10.10.1/24
set interface ethernet0/0 route
set interface bgroup0 ip 192.168.1.1/24
set interface bgroup0 route
set interface tunnel.1 ip unnumbered interface ethernet0/0
set interface tunnel.2 ip unnumbered interface ethernet0/0
unset interface vlan1 bypass-others-ipsec
unset interface vlan1 bypass-non-ip
set interface ethernet0/0 ip manageable
set interface bgroup0 ip manageable
set interface ethernet0/0 manage ssl
set interface ethernet0/0 manage web
set interface bgroup0 dhcp server service
set interface bgroup0 dhcp server auto
set interface bgroup0 dhcp server option gateway 192.168.1.1
set interface bgroup0 dhcp server option netmask 255.255.255.0
set interface bgroup0 dhcp server option dns1 10.10.10.89
set interface bgroup0 dhcp server option dns2 10.10.10.90
set interface bgroup0 dhcp server ip 192.168.1.100 to 192.168.1.200
unset interface bgroup0 dhcp server config next-server-ip
unset interface bgroup0 dhcp server config updatable
set interface "serial0/0" modem settings "USR" init "AT&F"
set interface "serial0/0" modem settings "USR" active
set interface "serial0/0" modem speed 115200
set interface "serial0/0" modem retry 3
set interface "serial0/0" modem interval 10
set interface "serial0/0" modem idle-time 10
set interface "ethernet0/0" webauth
set flow tcp-mss
unset flow no-tcp-seq-check
unset flow tcp-syn-check
unset flow tcp-syn-bit-check
set flow reverse-route clear-text prefer
set flow reverse-route tunnel always
set hostname topaz
set pki authority default scep mode "auto"
set pki x509 default cert-path partial
set dns host dns1 0.0.0.0
set dns host dns2 0.0.0.0
set dns host dns3 0.0.0.0
set address "Trust" "192.168.1.1" 192.168.1.1 255.255.255.0
set address "VPN1" "192.168.2.0/24" 192.168.2.0 255.255.255.0
set address "VPN2" "192.168.3.0/24" 192.168.3.0 255.255.255.0
set crypto-policy
exit
set ike gateway "VPN1" address VPN1.website.com Main outgoing-interface "ethernet0/0" preshare "presharedkey" proposal "pre-g2-aes128-sha"
set ike gateway "VPN2" address 0.0.0.0 id "other VPN" Aggr outgoing-interface "ethernet0/0" preshare "presharedkey" proposal "pre-g2-aes128-sha"
unset ike gateway "VPN2" nat-traversal
set ike respond-bad-spi 1
set ike ikev2 ike-sa-soft-lifetime 60
unset ike ikeid-enumeration
unset ike dos-protection
unset ipsec access-session enable
set ipsec access-session maximum 5000
set ipsec access-session upper-threshold 0
set ipsec access-session lower-threshold 0
set ipsec access-session dead-p2-sa-timeout 0
unset ipsec access-session log-error
unset ipsec access-session info-exch-connected
unset ipsec access-session use-error-log
set vpn "VPN1" gateway "VPN1" replay tunnel idletime 0 proposal "nopfs-esp-aes128-md5"
set vpn "VPN1" monitor optimized rekey
set vpn "VPN1" id 0x1 bind interface tunnel.1
set vpn "VPN2" gateway "VPN2" replay tunnel idletime 0 proposal "nopfs-esp-aes128-md5"
set vpn "VPN2" monitor optimized rekey
set vpn "VPN2" id 0x2 bind interface tunnel.2
unset interface tunnel.1 acvpn-dynamic-routing
unset interface tunnel.2 acvpn-dynamic-routing
set url protocol websense
exit
set vpn "VPN1" proxy-id local-addr "Trust" "192.168.1.1/24" remote-addr "VPN1" "192.168.2.0/24" "ANY"
set vpn "VPN2" proxy-id check
set vpn "VPN2" proxy-id local-addr "Trust" "192.168.1.1/24" remote-addr "VPN2" "192.168.3.0/24" "ANY"
set policy id 1 from "Trust" to "Untrust"  "Any" "Any" "ANY" nat src permit log
set policy id 1
set log session-init
exit
set policy id 2 from "VPN1" to "Trust"  "192.168.2.0/24" "192.168.1.1/24" "ANY" permit log
set policy id 2
exit
set policy id 3 from "VPN2" to "Trust"  "192.168.3.0/24" "192.168.1.1/24" "ANY" permit
set policy id 3
exit
set nsmgmt bulkcli reboot-timeout 60
set ssh version v2
set config lock timeout 5
unset license-key auto-update
set telnet client enable
set ntp server "198.123.30.132"
set snmp port listen 161
set snmp port trap 162
set snmpv3 local-engine id "0162102008002403"
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
unset add-default-route
set route 0.0.0.0/0 interface ethernet0/0 gateway 10.10.10.1
set route 192.168.2.0/24 interface tunnel.1 preference 20
set route 192.168.3.0/24 interface tunnel.2 preference 20
exit
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
exit

Thank you all for your help.

You're on the right track.  Both VRRP and NSRP will solve the issue you're looking to solve, but in different ways, and with different caveats.  Which one you choose will depend on your needs.

VRRP will provide redundancy at Layer 3 -- meaning simply that one SSG acts as the gateway for your Dell servers.  If there is a failure, then the other SSG becomes the gateway.  Remember, though, that these are firewalls and not routers.  They are stateful devices, meaning they keep track of all traffic flowing through them in the session table.  The session table is what allows the firewalls to act like firewalls.  If you use VRRP, traffic will flow through one SSG (the "master," or "primary").  That firewall will have a session table built for all traffic flows going through it.  If there is a link failure or other kind of failure and VRRP transitions to make the other firewall active, now traffic will start to flow through that device.  However, that second firewall does not have a copy of the first firewall's session table.  No session table means no sessions, and no sessions means traffic doesn't pass through the firewall!  End result -- you will get dropped traffic and connections will need to be reestablished from the endpoints.

NSRP will address this problem -- by turning the 2 devices into a single virtual device, the session table is synced between them so that if one fails, the other can gracefully and seamlessly take over, and your network devices are none the wiser.  Traffic doesn't drop, and connections don't break.  With NSRP you are effectively turning the 2 SSG devices into a single logical / virtual device.  That's potentially going to change the dynamic of how your network works, so it will require some thought and planning.

Aside from how you configure the redundancy on your SSGs, you have another problem -- the way the Dell servers are connected.  Each server has 4 ethernet connections.  You have 2 going to one SSG and 2 going to the other SSG from each server.  That's going to be problematic since you can't do a LAG / port aggregation on a SSG.  Which means you're going to either have to have each port in a separate VLAN or use different IP addresses on the same VLAN (not a good idea, don't do this).

You will just use 2 ports on each Dell server -- 1 to each SSG.  You'll still get the failover you need.

Keith, you're awesome.  This gives me a much better idea of what I'm looking at.  I'm still curious at what other responses I may get on this topic, so I don't quite want to pin the "solved" on this thread yet, but I really am greatful for your time.

Is there anyone out there with a working configuration for two SSG5 devices running VRRP?

I'm having an issue with setting VRRP up in that I get a 'command unknown' error when I try to set priority and preempt.

Futhermore, I'm trying to configure VRRP on the untrust (ethernet0/0) interface.  Is this the right interface to do it on?

Again, thank you all so much.

---

Is there anyone out there with a working configuration for two SSG5 devices running VRRP?

---

It's supported on SSG devices with > 6.1 code.  What version are you running?

---

I'm having an issue with setting VRRP up in that I get a 'command unknown' error when I try to set priority and preempt.

---

Are you following the syntax to assign the priority and preempt on the virtual IP / group?

Example:

set interface ethernet0/0 ip 172.83.54.10/24
set interface ethernet0/0:3 ip 172.83.54.30/24
set interface ethernet0/0 protocol vrrp
set interface ethernet0/0 protocol vrrp enable
set interface ethernet0/0:3 protocol vrrp preempt
set interface ethernet0/0:3 protocol vrrp priority 50

---

Futhermore, I'm trying to configure VRRP on the untrust (ethernet0/0) interface.  Is this the right interface to do it on?

---

It's the right interface if that's the link you want to protect.  

Based on the previous discussion, though, I don't think that's where you want it.  You were looking to protect the inside interfaces which link to your Dell servers.  VRRP protection is per interface.  You can have some interfaces set up with VRRP for redundancy, and others set up without it.

You won't be able to configure VRRP on your Trust side as it is right now because the interfaces are in a bgroup.  You can't do VRRP on a bgroup:

http://kb.juniper.net/InfoCenter/index?page=content&id=KB10892&smlogin=true

Hint:  < NSRP >       << nudge nudge >>

So I have to set up VRRP for each individual interface?

I basically want to set it up so that if the first device loses connectivity, the second device takes over.

---

So I have to set up VRRP for each individual interface?

---

Each pair of interfaces (one from each SSG) that you want to be redundant needs to be set up as a VRRP group.

If your outside interfaces are set up for VRRP, that has no effect on your inside interfaces, and vice versa.

---

I basically want to set it up so that if the first device loses connectivity, the second device takes over.

---

I keep hearing "NSRP" in a whispering voice throughout this discussion.  

What you just described is right up the NSRP alley, and is more cumbersome to make work the way you want it to work with VRRP.

With VRRP, if you set up a VRRP group on your inside interfaces to provide redundancy for your Dell servers, that VRRP group has no ties to the untrust interfaces linking you upstream.  If there's a link failure on your untrust side, for example, that won't trigger your inside VRRP to transition to the other device.  You'd need a switched link in between the SSGs to allow traffic to transit in that case.  It can get a little goofy.

I really think you'll be happier overall with NSRP.

Others are free to weigh in and vehemently disagree with me.  It certainly wouldn't be the first time.  

One other thing.. in order to really make your design work correctly, you're going to need a way to manage the multiple connections from your Dell servers.  Since you can't aggregate / LAG / 802.3ad / trunk / <and all the other different terms that different vendors use for the same thing> interfaces on the SSGs, you'd want to put a proper switch in between.  You can create a LAG/trunk/etc. from your Dell servers to your switch.  The switch then handles the uplinks to the SSGs and VRRP does its thing there.

Otherwise... you don't really have a [correct] way to have 2 interfaces on a single server live in the same VLAN.

If using NSRP, however, the interfaces on the passive node are "down" until the node becomes active.  Thus, you could theoretically have both of your server interfaces configured with the same IP address on the same VLAN.  If there was a transition, the links would swap and the "down" link would become "up" and the "up" link would become "down."  I've never really played with that in a lab so I don't know if your server would bark at you about an IP address conflict or not.  You'd have to experiment.

Even if you do make all this work with VRRP, remember that you have no session table sync between the firewalls.  A failure scenario is going to be much more disruptive than if you used NSRP.  NSRP is not *perfect* -- you may drop a couple packets... but it's significantly more robust than VRRP.

After 11 hours on the phone, 4 Juniper tech support engineers, tons of caffiene and one angry boss later, we all figured it out.  I will be posting a guide (I'll edit this post) in the very near future to help anyone else who has to go through this type of hell to get a redundant SSG5 configuration on VRRP.  Everything is finally working the way it should!  I couldn't have done it without your help Keith.  Thank you very much.  This topic is officially resolved.