Scenario:
Office network consists of two internet facing SRX firewalls (FW1 and FW2) and L3 main switch (CORE-SW1). Core switch can be from any vendor, in our case, its cisco. Firewalls have uplinks two different ISPs, FW1 is connected to ISP1 and FW2 is connected to FW2. CORE-SW1 has L3 uplinks to each SRX and has a couple of different VLAN L3 interfaces where users live, and a switch is a default gateway for LAN devices.
Both firewalls have IPsecVPN links to the datacenter network, which consists of actually two datacenters connected via 10g DCI. Clients/Users of the remote office need to be able to connect to the internet and also to the datacenter via IPsecVPN. We need to be able to fail over to the secondary ISP should the primary fail. Active/Active scenario is preferred.
IP addressing schema:
Loopback interfaces: Core-sw1: 200.126.10.3; FW1: 200.126.10.1; FW2: 200.126.10.2; DC1-FW: 200.100.0.99; DC2-FW: 200.120.0.99
Core-sw1 to FW1: 200.126.253.0/24; Core-sw1 to FW2: 200.126.254.0/24; FW1 to FW2: 200.126.255.0
FW1 to DC1-FW: 200.255.7.0/24; FW2 to DC2-FW: 200.254.7.0/24;
DC1-R1 and DC2-R1 have few loopbacks configured, representing DC1 network:
DC1-R1: 200.100.100.1/32, 200.100.101.1/32;
DC2-R1: 200.120.200.1/32, 200.120.201.1/32
FW1 internet link: 11.11.11.2/24, default gw: 11.11.11.1/24
FW2 internet link: 22.22.22.2/24, default gw: 22.22.22.1/24.
Configuration.
Core-Sw1 configuration is very straight forward - vlans, vlan interfaces and ospf. In our case, we don't have vlan configured, instead we will have loopback interfaces to source the traffic from during the test:
SRX firewalls configuration:
We will define the following zones: UNTRUST (internet interface - ge-0/0/2), TRUST (internal interface - ge-0/0/1 and inter-firewall ge-0/0/0), VPN (ipsecvpn interface to the datacenter - ge-0/0/3).
* for the simplicity we will not be building IPSecVPN tunnel to the datacenter, instead we will just use a regular link.
SRX OSPF is configured with export policy, which 'redustributes' only a default route to OSPF, which will be received by the core switch. Because switch does not speak BGP and doesn't know about datacenter routes, it is going to use default route to send traffic to the datacenter. If both uplinks to FW1 and FW1 form the switch have the same OSPF cost, traffic will be load-balanced and we will be seeing asymmetric routing, which is not going to work, because SRX will be dropping packets, which have no session created. This is the reason why we have a higher cost on the link to FW2.
Routing verification output:
Note, that all outbound traffic from core-sw1 is sent to FW1 and it has to make a decision what to do with it based on its routing table. If its the internet traffic, its going to use a static default route to send it out to ISP1. If its a DC1 traffic, its going to use BGP routes that point to IPSecVPN link with DC1-FW, if its a DC2 traffic, then its going to hit a BGP route pointing to FW2, because FW2 has a better route to DC2 networks that FW1. Al return traffic will be going via FW1, because of OSPF cost of the link between between FW2 and Core-SW. This way we avoid asymmetrical routing and still have a failover working. If ISP1 becomes unavailable (assuming that physical line went down), than default route on FW1 will get withdrawn and IPSecVPN will go down along with BGP session with DC1-FW. FW1 will be getting all DC routes and a default route from FW2.
What if we need to load share Internet links? There are two ways to achieve that:
-- export BGP routes to OSPF so SW1 receives datacenter routes and remove metric of 50 on the link between Core-Sw1 and FW2. Switch will be sending DC traffic to the proper firewall, based on OSPF metric which will be translated form BGP MED attribute. Default route on the switch will have the same cost and will be load-balanced. Since Internet traffic is source NAT'd on the firewall, there will be no asymmetric routing happening.
-- configure policy based routing (PBR) on FW1 and use ISP1 orFW2=>ISP2 depending on the source IP address. We can have wired clients using ISP1 and wireless clients using ISP2. This option requires splitting inter-SRX link into two, creating a second VRF for internet traffic destined to ISP2 and creating firewall filter (the actual PBR policy).
For this lab, we will go with the second option.
Below, there are configuration snippets of both firewalls.
Interface: inter-firewall link is broken into two tagged links: first one in the default routing instance carrying datacenter traffic routed via FW2 and second - in the routing instance ISP2 carrying internet traffic, which is policy based routed via ISP2 based on source IP.
Routing Instance 'ISP2' has just one interface in vlan 100. There is a static route to the LAN 200.126.0.0/16 pointing to the table inet.0 so internet traffic could make back to the source. Dynamic protocol OSPF is running inside the instance to deliver a default route from FW2 to FW1 and there is a static default route on FW1 with preference of 200, so if FW2 has issues with internet and the default route stops being propagated to FW1, FW1 will be forwarding internet traffic straight out to ISP1.
PBR1 firewall filter is defined and should be applied on the FW1 interface connecting core switch. PBR-EXCEPTION is a prefix list that contains all source networks excluded from PBR, in other termswe define IPs (in our case just one) , who's internet traffic we will be routing to ISP2.
For failover, we could use ip-monitoring feature to monitor IPs in the internet (I usually Level3 and Google DNS servers: 4.2.2.1 and 8.8.8.8). If both probes fail on FW2, we could shutdown interface ge-0/0/0.100 (belongs to routing instance ISP2), then internet traffic will be routed directly out of FW1. If probes fail on FW1, then we could just shutdown interface between FW1 and Core-SW1, so all traffic will naturally be re-routed via FW2 using OSPF.