Chapter 4. Route Mode and Static Routing
4.0. Introduction
Routing is the most important factor for traffic to flow over the network. Every packet traveling from Host A to Host B needs to have a defined path; otherwise, communication over the network is impossible. The defined path can be a default route, or it can be specific routes for an IP address. The paths can be configured manually using static routing, or they can be established using dynamic methods with the help of routing protocols, such as the Open Shortest Path First (OSPF) protocol, the Border Gateway Protocol (BGP), and the Routing Information Protocol (RIP).
Each path is considered to be a route and has the following elements:
- Prefix
The IP address and mask. This is the IP address for which the route is defined.
- Next hop
The gateway IP address, and the interface or Virtual Router (VR). This is where the packet should be forwarded for the IP address.
- Preferences
- Metric
The cost associated with the route.
- Tag
Used to identify the route for filtering or redistribution into other instances.
The collection of all paths is kept in a database called the routing table.
In ScreenOS software, you can deploy a firewall in three different system modes: Network Address Translation (NAT) mode, route mode, and transparent mode. The routing table is used differently in each mode. When the device is in transparent mode, the device utilizes the Media Access Control (MAC) table to forward packets; while in NAT/route mode, the device uses the route table to make forwarding decisions. You can check in which mode the system is operating with the get system command. This example shows a system operating in NAT/route mode:
SSG->get sysProduct Name: SSG-140 ....... ....System in NAT/route mode.Use interface IP, Config Port: 80 User Name: netscreen
The system mode is determined based on how you configure the interfaces. By default, when you put an interface in the Trust zone, it operates in NAT mode; for all other zones, the interface operates in route mode. If you assign interfaces to V1-Trust, V1-Untrust, or any user-defined Layer 2 zone, the device operates in transparent mode, which means that the firewall operates as a switch on the network. If you assign interfaces to Trust, Untrust, or any user-defined Layer 3 zones and assign IP addresses to the interfaces, the device operates in NAT or route mode. To configure the ingress interface to be in NAT mode, use the command set interface e1 nat. This means you want NAT to be performed on ingress traffic on this interface while crossing the firewall. The firewall performs NAT on traffic only if the interface belongs to a predefined Trust zone and the egress interface goes to the Untrust zone. If the interface belongs to a user-defined zone such as Private, the device does not perform NAT on the traffic, and you would have to cross the VRs for NAT to happen.
In route mode, NAT is not performed on any traffic, and the traffic is forwarded with the original IP address that the firewall received in the packet. You can change the interface mode to route mode using the command set interface e1 route.
The ScreenOS software has the concept of VRs, which are routing table instances. A device can have multiple VRs. Each VR has its own routing tables, which provide routing security by separating the routing tables on the firewall. Each interface is bound to a zone, and each zone is bound to a VR (see Figure 4-1).
The system-defined VRs on the device are trust-vr and untrust-vr. All zones are bound to trust-vr. You can configure interfaces to be in different zones. Refer to Chapter 1 for information on how to configure and separate the routing instances on the firewall.
In ScreenOS software, VRs are populated with routes from connected/host routes (derived from interface IP addresses), static routes, dynamic routing protocols (such as OSPF, BGP, RIP, the Internet Group Management Protocol [IGMP], and the Protocol Independent Multicast [PIM] protocol), and imported routes from other VRs.
Each VR has several routing tables: the destination IP-based table, the source IP-based table, the source interface-based table, the policy-based route table, and the multicast route table. This chapter concentrates on the static route configuration and route preferences. You can configure any of the following static routes on the firewall:
It is common to configure destination IP static routes. You configure the path for the destination IP address of the packet. Traditionally, all routing devices configure routes for the destination IP address and provide the next-hop gateway address. When the device is forwarding packets, all route lookups are done based on the destination IP address.
In ScreenOS software, you can configure source-based routing. This means that you want the routing decision to be made based on the source IP address of the packet. Use this method when you want some hosts to take Path A and others to take Path B in the traffic flow. For example, you might want traffic from contractors to use a slower Internet link and traffic from regular employees to use a faster Internet link.
With source interface-based routing, the routing decision is based on two factors: the source IP address of the packet and the ingress interface on which the packet arrived. You might use this when you don’t want traffic coming from a lab network to use the Internet link and you want to drop these packets, but when you do want traffic from other corporate divisions that use the same source IP address on a different ingress interface to be allowed to pass through, using source-based routing or destination IP-based routing.
You can configure routing policies using policy-based routing, which makes the routing decision on five tuples—the source IP address, source port, destination IP address, destination port, and protocol—and the packet’s Type of Service (ToS) bits. We discuss policy-based routing in Chapter 19.
In ScreenOS software, the route selection process is as follows:
A route is considered only if the next hop is a VR or if the outgoing interface is not in the Down state.
If there are multiple routes for the same prefix (subnet), routes with the lowest preference value are chosen.
If multiple routes have the same preference, routes with the lowest metric value are chosen.
If multiple routes have the same preference and metric values, the first installed route in the routing table is chosen.
If Equal Cost Multipath (ECMP) is enabled, all routes are considered to be active, and traffic is distributed in a round-robin fashion among them. The round-robin distribution is done per session, not per packet.
All active routes are placed into the routing table, which is used for route lookups. The longest prefix is matched first.
The following are the default preferences on the firewall:
SSG-> get vr trust-vr preference
vrouter trust-vr route preference table
---------------------------------------------
Host Routes: 0
Connected Routes: 0
Static Routes: 20
Auto-exported Routes: 30
Imported Routes: 140
RIP Routes: 100
EBGP Routes: 40
IBGP Routes: 250
OSPF Routes: 60
OSPF External Type-2 Routes: 200
NewYork->You can change the preferences using the set vr trust-vr preference command. Here is an example of changing the static route preference to 40:
SSG-> set vr trust-vr preference static 40For static routes, you can configure the metric. For dynamic routing protocols, the metric is derived based on the routing protocol calculations and interface costs. You cannot change the metric for connected/host routes.
Now that you understand that there are multiple routing tables in the VR, how do you figure out which table is used when the firewall receives a packet? The route lookup is done on the ingress interface to the VR based on the configured lookup preference. By default, the route lookup preference is done in the following order: policy-based routing, source interface-based routing, source-based routing, and destination-based routing. You can change the route lookup preference, as demonstrated in Recipe 4.9. Figure 4-2 shows the route lookup process for a packet on the firewall.
Once the session is created, it contains a pointer to the route ID and the Address Resolution Protocol (ARP) for the next-hop gateway IP address. Traffic is allowed to pass through the device based on the matched session. However, if the route has changed, the traffic has to flow along a different path. The route change is allowed only if the new path is also reachable in the same zone. If the new path crosses into another zone, the traffic is not allowed and the firewall drops it. This occurs because of the statefulness of the firewall.
The sequence is as follows:
A route becomes inactive because the next hop is not reachable. All sessions using this route are notified.
If a route becomes active, all sessions using this route are notified. Any route with a longer prefix is used if all the following conditions are met:
| — The new route’s interface differs from the old route’s interface. |
| — The new route’s gateway differs from the old route’s gateway. |
| — The zone of the new route’s interface differs from the zone of the old route’s interface. |
When a session is notified, a new route lookup occurs when the next packet for that session arrives; if the interface belongs to a different zone from the previous routes, the route will not be used. The route failover occurs only when both interfaces belong to the same zone.
4.1. View the Routing Table on the Firewall
Problem
You want to view the routing table on the firewall to verify which IP networks are reachable.
Solution
The get route command shows the contents of the routing table:
SSG-> get route
IPv4 Dest-Routes for <untrust-vr> (0 entries)
----------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv4 Dest-Routes for <trust-vr> (4 entries)
----------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
----------------------------------------------------------------------
* 4 1.1.1.2/32 eth0/1 0.0.0.0 H 0 0 Root
* 2 192.168.1.1/32 eth0/0 0.0.0.0 H 0 0 Root
* 1 192.168.1.0/24 eth0/0 0.0.0.0 C 0 0 Root
* 3 1.1.1.0/24 eth0/1 0.0.0.0 C 0 0 RootIf IPv6 is enabled on the firewall, the routing table contains its routes. These are listed at the end of the get route command, or you can display them separately with the get route v6 command:
SSG-> get route v6
IPv6 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv6 Dest-Routes for <trust-vr> (2 entries)
-------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
-------------------------------------------------------------------
* 3 9009:1::/64 eth0/3 :: C 0 0 Root
* 4 9009:1::205:85ff:fe7e:2f87/128 eth0/3 :: H 0 0 RootWhen dynamic routing protocols are running on the device, you can use the get route prot <protocol> command to list routes specific to the routing protocol, such as OSPF, BGP, RIP, and RIPng (next generation), as well as static routes:
SSG-> get route prot ospf
IPv4 Dest-Routes for <trust-vr> (8 entries)
-------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
-------------------------------------------------------------------
* 8 192.168.2.0/24 tun.1 192.168.254.1 O 60 11 RootDiscussion
The get route command is the basic command for listing routes in the routing table. The first command in this recipe, without any options, shows the contents of all the routing tables. This output shows the contents of two routing tables, trust-vr and untrust-vr, which are the default VRs on the firewall. By default, all interfaces are in the trust-vr routing table.
The first line shows which VR you are viewing. The next four lines of the get route output show the description of the P (Protocol) column for the entries in the route table:
H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2
The trust-vr table shows four routes: two connected routes and two host routes. On the left of the route entry, an asterisk (*) indicates which routes are the active routes. If there is no asterisk in front of a route, it means the route is inactive and will not be matched when the firewall is doing a route lookup. By default, the connected routes are the interface subnetworks configured by the user and the host routes for the interface IP address itself. Following the asterisk is the route ID, which you can use to get detailed output of the route, and then the route prefix.
To the right of the route prefix are the outgoing interfaces for each route, the next-hop gateway address, and the protocol type. For example, an H indicates a Host route. Refer to the description for this column in the first few lines of the output.
The Pref (Preference) column shows the local preference for the route entry. The preference values shown in the output are all the default values. You can check the default preferences using the following command:
Chicago-> get vr trust-vr preference
vrouter trust-vr route preference table
---------------------------------------------
Host Routes: 0
Connected Routes: 0
Static Routes: 20
Auto-exported Routes: 30
Imported Routes: 140
RIP Routes: 100
EBGP Routes: 40
IBGP Routes: 250
OSPF Routes: 60
OSPF External Type-2 Routes: 200The Mtr column lists the metrics for the routes. All connected routes have a default metric of 0 and static routes have a default metric of 1. All other route metrics are calculated by the routing protocol.
The last column, Vsys, is the Virtual System (VSYS) to which this route belongs.
You may wonder why the firewall has many addresses in its routing tables when no routing protocols or static routes have been configured. When you configure interfaces, the ScreenOS software automatically places routes in the routing table. For the routing table examples in this recipe, the following interfaces and interface addresses are configured:
SSG-> get int
A - Active, I - Inactive, U - Up, D - Down, R - Ready
H - IPv6 Host Mode, O - IPv6 Router Mode
Interfaces in vsys Root:
Name IP Address Zone MAC/INT-ID VLAN State VSD
eth0/0 192.168.1.1/24 Trust 0005.857e.2f80 - U -
eth0/1 1.1.1.2/24 Untrust 0005.857e.2f85 - U -
eth0/2 0.0.0.0/0 Untrust 0005.857e.2f86 - D -
eth0/3 0.0.0.0/0 DMZ 0005.857e.2f87 - U -
9009:1::205:85ff:fe7e:2f87/64 020585fffe7e2f87 O
eth0/4 0.0.0.0/0 Null 0005.857e.2f88 - D -
eth0/5 0.0.0.0/0 Null 0005.857e.2f89 - D -
eth0/6 0.0.0.0/0 Null 0005.857e.2f8a - D -
eth0/7 0.0.0.0/0 Null 0005.857e.2f8b - D -
eth0/8 0.0.0.0/0 Null 0005.857e.2f8c - D -
eth0/9 0.0.0.0/0 Null 0005.857e.2f8d - D -
vlan1 0.0.0.0/0 VLAN 0005.857e.2f8f 1 D -
null 0.0.0.0/0 Null N/A - U 0
Chicago->Looking at the trust-vr routing table, you see it contains entries for each interface and for the subnetworks (the /24 address) to which they are connected:
* 4 1.1.1.2/32 eth0/1 0.0.0.0 H 0 0 Root * 2 192.168.1.1/32 eth0/0 0.0.0.0 H 0 0 Root * 1 192.168.1.0/24 eth0/0 0.0.0.0 C 0 0 Root * 3 1.1.1.0/24 eth0/1 0.0.0.0 C 0 0 Root
This output shows entries for the two configured interfaces. For eth0/1, there is an entry for the interface itself (1.1.1.2/32), and an entry for the summary of all the addresses on the subnetwork (1.1.1.0/24). There are similar entries for the eth0/0 interface.
This is the basic output of the routing table on the firewall. Refer to Chapter 15 to understand how the routing entries are populated based on the protocol updates.
4.2. View Routes for a Particular Prefix
Problem
You want to check whether a particular IP subnet prefix is in the routing table on the firewall and you need to know the next hop.
Solution
The get route prefix command shows the contents of the routing table:
SSG-> get route prefix 2.2.2.2/24
IPv4 Dest-Routes for <untrust-vr> (0 entries)
-------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv4 Dest-Routes for <trust-vr> (6 entries)
-----------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
-----------------------------------------------------------------
* 22 2.2.2.0/24 eth0/1 1.1.1.1 O 60 2 RootDiscussion
You use this command when you want to know whether a particular destination is taking the intended path. The output provides information on which zones to configure in the firewall policy. In addition, this command helps you verify that the configuration is correct and that the route is going in the intended path. When you include the destination’s address in the get route prefix command, you see output for only that route. This recipe shows that the route 2.2.2.2/24, which was learned from an OSPF router, has a metric of 2 and goes through interface eth0/1 with a next hop of 1.1.1.1. The header lines for the trust-vr are also displayed.
For more information about this route, use the get route id command:
SSG-> get route id 22
route in trust-vr:
------------------------------------------------
id: 22
IP address/mask: 2.2.2.0/24
next hop (gateway): 1.1.1.1
preference: 60
metric: 2
outgoing interface: ethernet0/1
vsys name/id: Root/0
tag: 0
flag: 24010100/00100000
type: OSPF-intra-area
OSPF parameters: area = 0.0.0.0 ospf level 10000
Redistributed to:
status: active (for 10 minutes 42 seconds)This output shows a few more fields for this route. The status field shows that the route is active in the routing table and has been active for 10 minutes, 42 seconds. The type field shows that this route was learned through OSPF intra-area. Also, the OSPF parameters field shows that this route belongs to OSPF area 0, along with the OSPF level that is used internally to identify the best route. The flag displayed is used by development to identify the route in the code.
We have just seen a very simple single-route prefix entry in the routing table. Many times, it is possible that the same route prefix is learned in many ways. Here is an example of a route prefix learned by OSPF, and as a connected route:
SSG-> get route prefix 3.3.3.0/24
IPv4 Dest-Routes for <untrust-vr> (0 entries)
---------------------------------------------------------------------
H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent D: Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv4 Dest-Routes for <trust-vr> (6 entries)
------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
------------------------------------------------------------------
* 7 3.3.3.1/32 eth0/0 0.0.0.0 H 0 0 Root
* 6 3.3.3.0/24 eth0/0 0.0.0.0 C 0 0 Root
21 3.3.3.0/24 eth0/1 1.1.1.1 O 60 3 RootIn this example, we see that the 3.3.3.0/24 subnet is reachable by the eth0/0 and eth0/1 interfaces. The route to interface eth0/0 is a connected route, and the route to interface eth0/1 is learned via OSPF. By virtue of the router preferences, the connected route is active in the routing table and the OSPF route is inactive.
Warning
When you design your network and routing, it is very important that you consider from which zones the routes will be learned. If the same routes are learned from two different interfaces, and each interface belongs to a different zone, the established sessions will fail because ScreenOS software allows the traffic to failover between two interfaces only if they belong to the same zone. In the case of new sessions, the policy lookup would be done, and traffic would be permitted or denied based on the policy.
4.3. View Routes in the Source-Based Routing Table
Solution
The get route source command shows the contents of the routing table:
SSG-> get route source
S: Static P: Permanent
Src-Routes for <trust-vr> (2 entries)
-------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
-------------------------------------------------------------------
* 2 5.5.5.0/24 eth0/0 3.3.3.2 S 20 1 Root
* 1 3.3.3.0/24 n/a vpn-vr S 20 1 Root
Src-Routes for <vpn-vr> (1 entries)
-------------------------------------------------------------------
ID P-Prefix Interface Gateway P Pref Mtr
-------------------------------------------------------------------
* 1 4.4.4.0/24 n/a trust-vr S 20 1Discussion
You have configured source-based routing and would like to view the source-based routing table on the firewall. The source-based routing table is separate from the destination-based routing table, and you have to use the get route source command to view the routes. The output in this recipe shows two VRs that have source-based routes. trust-vr has two entries, and vpn-vr has one entry.
trust-vr has the source route for the 5.5.5.0/24 subnet using the outgoing interface eth0/0 and a next-hop gateway of 3.3.3.2. Any packet coming from the source IP subnet 5.5.5.0/24 and from an interface in the trust-vr matches this route lookup, and traffic is sent out the next-hop gateway 3.3.3.2. No route lookup is done for the destination IP address on the packet. Also, it is important to know that the source-based route lookup is done only for the traffic coming from an interface in that VR. It does not apply to source IP lookups initiated in a different VR.
From ScreenOS version 5.2 and later, the source-based routes can point the next hop to a different VR. In the output given here, the trust-vr has the source route 3.3.3.0/24 with a next hop of vpn-vr. The packet flow for this kind of source route is different. When a packet with a source IP subnet of 3.3.3.0/24 is received in the trust-vr, the source-based route lookup is performed and the next hop is vpn-vr. In the vpn-vr, another route lookup is done for the same packet, but this time the lookup is done for the destination IP address of the packet to forward the packet. This is because the source-based route lookup is done only for the packets that are initiated in that VR. For packets initiated in another VR, the destination IP address is used for the route lookup. A similar source route is configured in the vpn-vr for the 4.4.4.0/24 subnet with a next hop of trust-vr.
For more information about the source route, use the get vr route source id command:
SSG-> get vr trust-vr route source id 2
route in trust-vr:
------------------------------------------------
id: 2
IP address/mask: 5.5.5.0/24
next hop (gateway): 3.3.3.2
preference: 20
metric: 1
outgoing interface: ethernet0/0
vsys name/id: Root/0
tag: 0
flag: 24000040/00000000
type: static
Redistributed to:
Status: active (for 34 minutes 36 seconds)This output shows a few more fields for the route. The status field shows that the route is active in the routing table and has been active for 34 minutes, 36 seconds. The type field shows that this route is a static route. The flag displayed is used by development to identify the route in the code.
You can use the following command to test which route would be matched in the routing table for a source IP address lookup:
SSG-> get vr trust-vr route source ip 5.5.5.5
Source for 5.5.5.5
---------------------------------------------------------------------
trust-vr : => 5.5.5.0/24 (id=2) via 3.3.3.2 (vr: trust-vr)
Interface ethernet0/0 , metric 1In this output, the source IP address 5.5.5.5 received in the trust-vr is sent out via interface ethernet0/0 with a nexthop gateway of 3.3.3.2. The output also shows that the source route ID 2 with a metric of 1 in the trust-vr was matched for this test command.
Here’s another example of testing route matching:
SSG-> get vr trust-vr route source ip 3.3.3.3
Source for 3.3.3.3
---------------------------------------------------------------------
trust-vr : => 3.3.3.0/24 (id=1) via (vr: vpn-vr), metric 1
trust-vr : => 0.0.0.0/0 (id=3) via 8.8.8.2 (vr: vpn-vr)
Interface ethernet0/3 , metric 1In this example, the source IP address 3.3.3.3 received in the trust-vr is sent out via interface ethernet0/3 with a next-hop gateway of 8.8.8.2. Notice that the route lookup was done with a source IP lookup in the trust-vr and matched source route ID 1 with a next hop of vpn-vr, and for the same packet the route lookup was done with the destination IP lookup in the vpn-vr and matched destination route ID 3, with an outgoing interface of ethernet0/3 and a next-hop gateway of 8.8.8.2.
4.4. View Routes in the Source Interface-Based Routing Table
Solution
The get vr route source in-interface command shows the contents of the source interface-based routing table:
SSG-> get vr trust-vr route source in-interface
S: Static P: Permanent
SIBR-Routes for <ethernet0/0>
(2 entries)
--------------------------------------------------------------------
ID IP-Prefix Interface Gateway P Pref Mtr Vsys
--------------------------------------------------------------------
* 1 3.3.3.0/24 n/a untrust-vr S 20 1 Root
4 2.2.2.0/24 eth0/4 7.7.7.1 S 20 1 RootDiscussion
Source interface-based routes are routes for which the source IP traffic should be received on the configured interface. These routes exist only when traffic is received on the expected interface. If it is received on a different interface, the traffic would match other routes, such as source-based or destination-based routes. The difference between source-based and source interface-based routes is that the route lookup for source-based routes matches packets with a source IP address from any interface in that VR, whereas the source interface route lookup matches packets with a source IP address from a particular interface in that VR.
In this output, the trust-vr has one source interface-based route on Ethernet0/0, with a source IP subnet of 3.3.3.0/24 and a next hop of untrust-vr. You see that the route ID 1 is active because of the asterisk in front of the route. We also have a route for a source IP subnet of 2.2.2.0/24 with an outgoing interface of eth0/4 and a next-hop gateway of 7.7.7.1. You see that route ID 4 is not active; this is because the Ethernet interface e0/4 is down. You can use this command to check the interface status:
SSG-> get int e0/4
Interface ethernet0/4:
description ethernet0/4
number 8, if_info 6464, if_index 0, mode route
link down, phy-link down
vsys Root, zone DMZ, vr trust-vrThe source interface-based route lookup’s performance is very similar to that of the source-based route. Please review the source-based route recipe for this discussion.
For more information about the source interface-based route, use the get vr route source in-interface id command:
SSG-> get vr trust-vr route source in-interface id 1
route in ethernet0/0:
------------------------------------------------
id: 1
IP address/mask: 3.3.3.0/24
next hop (vrouter): untrust-vr
preference: 20
metric: 1
outgoing interface: n/a
vsys name/id: Root/0
tag: 0
flag: 24000840/00000000
type: static
Redistributed to:
status: active (for 2 hours 16 minutes 25 seconds)
route --> 3.3.3.0/24 in vr untrust-vr:
SSG->This output shows a few more fields for this route. The status field shows this route is active in the routing table and has been active for 2 hours, 16 minutes, and 25 seconds. The type field shows that this route is a static route. The flag displayed is used by development to identify the route in the code.
4.5. Create Blackhole Routes
Problem
You have a route-based IP Security (IPSec) virtual private network (VPN) tunnel between two sites. You want all traffic to pass through the encrypted tunnel, and you want to ensure that nothing goes outside the tunnel.
Solution
Configure the routers on each side of the tunnel. The router Chicago is on one side of the tunnel:
set interface "ethernet0/0" zone "Trust" set interface "ethernet0/1" zone "Untrust" set interface "ethernet0/2" zone "Untrust" set interface "tunnel.1" zone "Trust" set interface ethernet0/0 ip 192.168.1.1/24 set interface ethernet0/0 nat set interface ethernet0/1 ip 1.1.1.2/24 set interface ethernet0/1 route set interface tunnel.1 ip unnumbered interface ethernet0/0 set ike gateway "NewYork-P1" address 2.2.2.2 Main outgoing-interface "ethernet0/1" preshare "0XncnRYNNmyBzssOlsC5btswLfngijyASg==" sec-level standard set vpn "NewYork-P2" gateway "NewYork-P1" no-replay tunnel idletime 0 sec-level standard set vpn "NewYork-P2" monitor optimized rekey set vpn "NewYork-P2" id 1 bind interface tunnel.1 set route 0.0.0.0/0 interface ethernet0/1 gateway 1.1.1.1 set route 192.168.2.0/24 interface tunnel.1 set route 192.168.2.0/24 interface null metric 200 exit
The router New York is on the other side of the tunnel:
set interface "ethernet0/0" zone "Trust" set interface "ethernet0/1" zone "Untrust" set interface "ethernet0/2" zone "Untrust" set interface "tunnel.1" zone "Trust" set interface ethernet0/0 ip 192.168.2.1/24 set interface ethernet0/0 nat set interface ethernet0/1 ip 2.2.2.2/24 set interface ethernet0/1 route set interface tunnel.1 ip unnumbered interface ethernet0/0 set ike gateway "Chicago-P1" address 1.1.1.2 Main outgoing-interface "ethernet0/1" preshare "0XncnRYNNmyBzssOlsC5btswLfngijyASg==" sec-level standard set vpn "Chicago-P2" gateway "Chicago-P1" no-replay tunnel idletime 0 sec-level standard set vpn "Chicago-P2" monitor optimized rekey set vpn "Chicago-P2" id 1 bind interface tunnel.1 set vrouter "trust-vr" set route 0.0.0.0/0 interface ethernet0/1 gateway 2.2.2.1 set route 192.168.1.0/24 interface tunnel.1 set route 192.168.1.0/24 interface null metric 200 exit
Discussion
This recipe configures routes for the remote network to the tunnel interfaces, and configures a default route to the Internet. To ensure that the traffic is not going in unencrypted, you have to configure the routes to the null interface with a higher metric. Once the tunnel routes are withdrawn when the tunnel goes down, the null interface route becomes active and blackholes all the traffic on the firewall, thus pre-venting the traffic from going in unencrypted.
Figure 4-3 shows the configuration of a firewall in Chicago and New York. The Chi-cago site has a site-to-site IPSec VPN tunnel to the New York site. The 192.168.1.0/24 subnet is on the Chicago Trust network and the 192.168.2.0/24 subnet is on the New York Trust network.
The configuration of the VPN tunnel on the Chicago side shows that the interfaces belong to both the Trust and Untrust zones. We create a tunnel interface bound to the Trust zone, create Phase 1 and Phase 2 for the IPSec tunnels, and bind the tunnel inter-face to the VPN. We use the VPN monitor on the tunnel to change the tunnel interface status to Up or Down. Whether routes are active depends on the tunnel interface status.
To blackhole traffic if the tunnel goes down on the Chicago side, we have configured a default route on the trust-vr, and have two static routes. The first static route points to the tunnel.1 interface, and the second points to the null interface with a metric of 200. The route entry pointing to the null interface is considered to be the blackhole route and has the higher metric, which means that this route is inactive when the tunnel.1 route is active. The blackhole route is active only when the tunnel.1 route is withdrawn from the routing table when the tunnel is down:
set vrouter "trust-vr" set route 0.0.0.0/0 interface ethernet0/1 gateway 1.1.1.1 set route 192.168.2.0/24 interface tunnel.1 set route 192.168.2.0/24 interface null metric 200 exit
The configuration on the New York firewall is similar to that on the Chicago firewall.
Here is how you verify that the configuration is sending the traffic to the intended path. Use the get int tunnel.1 command to see the tunnel interface status:
Chicago-> get int tunnel.1
Interface tunnel.1:
description tunnel.1
number 20, if_info 16168, if_index 1, mode nat
link up
vsys Root, zone Trust, vr trust-vr
admin mtu 1500, operating mtu 1500, default mtu 1500
*ip 0.0.0.0/0 unnumbered, source interface ethernet0/0
*manage ip 0.0.0.0
bound vpn:
NewYork-P2
Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
pmtu-v4 disabled
ping enabled, telnet enabled, SSH enabled, SNMP enabled
web enabled, ident-reset disabled, SSL enabled
DNS Proxy disabled
OSPF disabled BGP disabled RIP disabled RIPng disabled mtrace
disabled
PIM: not configured IGMP not configured
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbpsThis output shows that the tunnel.1 interface is up and is bound to the NewYork-P2 VPN tunnel.
The routing table on the trust-vr shows two routes. However, only one route point-ing to the tunnnel.1 interface is active, indicated by the * in front of the route. The second route with a metric of 200 is not active and is a shadow route:
Chicago->get routeIPv4 Dest-Routes for <trust-vr> (7 entries) -------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys -------------------------------------------------------------------- * 5 0.0.0.0/0 eth0/1 1.1.1.1 S 20 1 Root * 4 1.1.1.2/32 eth0/1 0.0.0.0 H 0 0 Root * 2 192.168.1.1/32 eth0/0 0.0.0.0 H 0 0 Root* 6 192.168.2.0/24 tun.1 0.0.0.0 S 20 1 Root 7 192.168.2.0/24 null 0.0.0.0 S 20 200 Root* 1 192.168.1.0/24 eth0/0 0.0.0.0 C 0 0 Root * 3 1.1.1.0/24 eth0/1 0.0.0.0 C 0 0 Root
Check the status of the IPSec VPN with the get sa command on the device. The status is in the Sta column. A/U means the tunnel is up and active, and the monitor on the tunnel is checking the status of the tunnel:
Chicago-> get sa
total configured sa: 1
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID
00000001> 2.2.2.2 500 esp:3des/sha1 0a40fdf6 3217 unlim A/U -1 0
00000001> 2.2.2.2 500 esp:3des/sha1 37031392 3217 unlim A/U -1 0When we initiate a ping from the Chicago firewall device to the remote network, we see a successful ping response. This demonstrates that the tunnel is up and working:
Chicago-> ping 192.168.2.1 from e0/0 Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 1 seconds from ethernet0/0 !!!!! Success Rate is 100 percent (5/5), round-trip time min/avg/max=4/4/5 ms
Here is the debug flow basic output captured for the successful ping request. We see that the flow has identified the tunnel.1 route as the intended path for sending this traffic. This output also shows you that the packet is going into tunnel 40000001:
Chicago->get db str****** 02095.0: <Trust/ethernet0/0> packet received [128]****** ipid = 6222(184e), @02312f14 self:192.168.1.1/17500->192.168.2.1/1024,1(8/0)<Root> ethernet0/0:192.168.1.1/17500->192.168.2.1/1024,1(8/0)<Root> no session found flow_first_sanity_check: in <ethernet0/0>, out <tunnel.1> chose interface ethernet0/0 as incoming nat if. flow_first_routing: in <ethernet0/0>, out <tunnel.1> search route to (ethernet0/0, 192.168.1.1->192.168.2.1) in vr trust-vr for vsd-0/flag-0/ifp-null[ Dest] 6.route 192.168.2.1->0.0.0.0, to tunnel.1routed (x_dst_ip 192.168.2.1) from ethernet0/0 (ethernet0/0 in 0) to tunnel.1 policy search from zone 2-> zone 2 policy_flow_search policy search nat_crt from zone 2-> zone 2 RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 192.168.2.1, port 5078, proto 1) No SW RPC rule match, search HW rule Searching global policy. Permitted by policy 320002 No src xlate ## 2000-06-21 07:14:11 : NHTB entry search found: vpn none tif tunnel.1 nexthop 192.168.2.1 tunnelid 0x1, flag 0x1, status 4 choose interface ethernet0/1 as outgoing phy if no loop on ifp ethernet0/1. session application type 0, name None, nas_id 0, timeout 60sec service lookup identified service 0. flow_first_final_check: in <ethernet0/0>, out <ethernet0/1> existing vector list 4-3992850. Session (id:48059) created for first pak 4 flow_first_install_session======> flow got session. flow session id 48059 skipping pre-fraggoing into tunnel 40000001.flow_encrypt: pipeline. chip info: PIO. Tunnel id 00000001 (vn2) doing ESP encryption and size =136 ipsec encrypt prepare engine done ipsec encrypt set engine done ipsec encrypt engine released ipsec encrypt done put packet(394c7f0) into flush queue. remove packet(394c7f0) out from flush queue. **** jump to packet:1.1.1.2->2.2.2.2 out encryption tunnel 40000001 gw:1.1.1.1 no more encapping needed flow_send_vector_, vid = 0, is_layer2_if=0 packet send out to 000585caf0a0 through ethernet0/1 **** pak processing end.
When the blackhole route becomes active the traffic is dropped, and you see the following in the routing table:
Chicago->get routeIPv4 Dest-Routes for <trust-vr> (7 entries) ------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys ------------------------------------------------------------------- * 5 0.0.0.0/0 eth0/1 1.1.1.1 S 20 1 Root * 4 1.1.1.2/32 eth0/1 0.0.0.0 H 0 0 Root * 2 192.168.1.1/32 eth0/0 0.0.0.0 H 0 0 Root* 7 192.168.2.0/24 null 0.0.0.0 S 20 200 Root 6 192.168.2.0/24 tun.1 0.0.0.0 S 20 1 Root* 1 192.168.1.0/24 eth0/0 0.0.0.0 C 0 0 Root * 3 1.1.1.0/24 eth0/1 0.0.0.0 C 0 0 Root
This output shows that the null interface route is active and the tun.1 route is inactive. The null interface route is active because the tunnel interface is down, and hence, the route attached to the tunnel interface becomes inactive.
If you check the status of the IPSec VPN with the get sa command on the device and see the status under the STA column, it shows I/I, which means the tunnel is inactive, and the monitor on the tunnel has brought the tunnel down:
Chicago-> get sa
total configured sa: 1
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000001< 2.2.2.2 500 esp:3des/sha1 0a40fdf6 expir unlim I/I -1 0
00000001> 2.2.2.2 500 esp:3des/sha1 37031392 expir unlim I/I -1 0When you initiate a ping from the Chicago firewall device to the remote network, you see that the ping is failing, and there is no usable route on the device:
Chicago-> ping 192.168.2.1 from e0/0 Type escape sequence to abort Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 1 seconds from ethernet0/0 ip 192.168.2.1 is unreachable in vr trust-vr Success Rate is 0 percent.
When you enable debug flow basic, there is no output in the debug for the ping request. This is because the firewall device can identify that traffic destined to this network needs to be blackholed, and hence, it does not generate any debugs:
Chicago-> get db str
Chicago->This recipe shows many features working together on the Juniper firewalls to achieve the traffic blackhole route. See Chapter 10 for information on how to configure route-based IPSec VPNs.
4.6. Create ECMP Routing
Problem
You have configured dynamic routing protocols and can possibly learn equal-cost routes. You want to load-balance the traffic flows using all available paths.
Solution
Enable ECMP on the VR using the following command to load-balance traffic per flow among the equal-cost routes:
SSG-> set vr trust-vr max-ecmp-routes 4
SSG->Discussion
You use ECMP on the VR to allow equal-cost routes to be updated in the route table. This recipe illustrates ECMP with the following topology (see Figure 4-4) that has firewalls in Chicago and New York. Both firewalls are connected to the dynamic routing protocol cloud, which means that both could learn equal-cost routes for their internal networks.
The configuration on the Chicago firewall shows that both are using OSPF as the dynamic routing protocol:
set vrouter "trust-vr" unset auto-route-export set protocol ospf set enable exit set interface "ethernet0/0" zone "Trust" set interface "ethernet0/1" zone "Untrust" set interface ethernet0/0 ip 10.1.1.1/24 set interface ethernet0/0 route set interface ethernet0/1 ip 10.1.2.1/24 set interface ethernet0/1 route set policy id 1 from "Trust" to "Untrust" "Any" "Any" "ANY" permit set policy id 1 exit set vrouter "trust-vr" set max-ecmp-routes 4 set route 0.0.0.0/0 interface ethernet0/1 gateway 1.1.1.1 exit set interface ethernet0/0 protocol ospf area 0.0.0.0 set interface ethernet0/0 protocol ospf enable set interface ethernet0/1 protocol ospf area 0.0.0.0 set interface ethernet0/1 protocol ospf enable
OSPF is enabled on the trust-vr, ethernet0/0 is bound to the Trust zone, and ethernet0/1 is bound to the Untrust zone. The ethernet0/0 interface has an IP address of 10.1.1.1/24 and ethernet0/1 has an IP address of 10.1.2.1/24. OSPF is enabled on both interfaces and is attached to area 0. A simple policy is created to allow traffic from the Trust zone to the Untrust zone.
The max-ecmp-routes 4 configuration command enables ECMP on the VR and allows a maximum of four equal-cost routes to be updated in the route table. This is the maximum number of equal-cost routes you can configure on a single VR.
You can verify whether the equal-cost routes are populated in the routing table using the get route command. Here is the routing table output before enabling ECMP:
Chicago->get routeIPv4 Dest-Routes for <untrust-vr> (0 entries) -------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 IPv4 Dest-Routes for <trust-vr> (8 entries) -------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys -------------------------------------------------------------------- * 25 0.0.0.0/0 eth0/1 1.1.1.1 S 20 1 Root * 19 10.1.2.1/32 eth0/1 0.0.0.0 H 0 0 Root * 4 10.1.1.1/32 eth0/0 0.0.0.0 H 0 0 Root * 29 10.1.5.1/32 eth0/1 10.1.2.100 O 60 1 Root *28 10.1.4.0/24 eth0/1 10.1.2.100 O 60 3 Root* 3 10.1.1.0/24 eth0/0 0.0.0.0 C 0 0 Root * 18 10.1.2.0/24 eth0/1 0.0.0.0 C 0 0 Root *30 10.1.3.0/24 eth0/1 10.1.2.100 O 60 2 RootChicago->
IP subnets 10.1.3.0/24 and 10.1.4.0/24 have only one route learned via OSPF on eth0/1, with a next-hop gateway of 10.1.2.100.
Here is the output of the trust-vr table using the get vr trust-vr command after you enable ECMP on the device:
Chicago->get vr trust-vrRouting Table -------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 Total 10/max entries ID IP-Prefix Interface Gateway P Pref Mtr Vsys ------------------------------------------------------------------ * 25 0.0.0.0/0 eth0/1 1.1.1.1 S 20 1 Root * 19 10.1.2.1/32 eth0/1 0.0.0.0 H 0 0 Root * 4 10.1.1.1/32 eth0/0 0.0.0.0 H 0 0 Root * 29 10.1.5.1/32 eth0/1 10.1.2.100 O 60 1 Root* 32 10.1.4.0/24 eth0/1 10.1.2.100 O 60 3 Root * 33 10.1.4.0/24 eth0/1 10.1.2.200 O 60 3 Root* 3 10.1.1.0/24 eth0/0 0.0.0.0 C 0 0 Root * 18 10.1.2.0/24 eth0/1 0.0.0.0 C 0 0 Root* 30 10.1.3.0/24 eth0/1 10.1.2.100 O 60 2 Root * 31 10.1.3.0/24 eth0/1 10.1.2.200 O 60 2 RootInterfaces -------------------------------------------------------------------- tunnel, hidden.1, l2v, self, ethernet0/0, vlan1 v1-trust, v1-untrust, v1-dmz, ethernet0/2, ethernet0/1 Auto-exporting: Disabled Default-vrouter: Yes Shared-vrouter: Yes nsrp-config-sync: Yes System-Default-route: Not present Advertise-Inactive-Interface: Disabled Source-Based-Routing: Disabled SIBR-Routing: Disabled SNMP Trap: Public Ignore-Subnet-Conflict: DisabledECMP-Routing: Enabled with 4 as maximum routes
Now, IP subnets 10.1.3.0/24 and 10.1.4.0/24 have two active routes via the eth0/1 interface, but with two different next-hop gateways: 10.1.2.100 and 10.1.2.200. The route IDs 32 and 33 show routes for IP prefix 10.1.4.0/24, and the route IDs 30 and 31 show routes for IP prefix 10.1.3.0/24. The traffic flow is now load-balanced between these routes in a round-robin fashion. At the bottom of the output, you see that ECMP routing is enabled.
Tip
It is important to know that traffic load balancing will be done per session and not per packet. So, if there is only one session, all packets for that session will always flow through the same route. When a second session is initiated, it will use the second route and forward the traffic.
Also, remember that when you enable ECMP, the equal-cost routes will be populated in the routing table only when there is a topology change, such as OSPF’s neighbor going down and up. They would not populate for already existing topology calculations.
You can verify how the sessions are being load-balanced using the get session command. Here is an example of two sessions:
id 48047/s**,vsys 0,flag 08000040/0000/0001,policy 1,time 170, dip 0 module 0 if 0(nspflag 801801):10.1.1.10/35968->10.1.4.32/21,6,000c29eeeed6,sess token 4,vlan 0,tun 0,vsd 0,route 3 if 5(nspflag 801800):10.1.1.10/35968<-10.1.4.32/21,6,000585caf0a0,sess token 6,vlan 0,tun 0,vsd 0,route 32id 48050/s**,vsys 0,flag 08000040/0000/0001,policy 1,time 180, dip 0 module 0 if 0(nspflag 801801):10.1.1.10/35970->10.1.4.32/23,6,000c29eeeed6,sess token 4,vlan 0,tun 0,vsd 0,route 3 if 5(nspflag 801800):10.1.1.10/35970<-10.1.4.32/23,6,0010db558d90,sess token 6,vlan 0,tun 0,vsd 0,route 33
Session ID 48047 shows that a File Transfer Protocol (FTP) session was created from 10.1.1.10–10.1.4.32 and is using route ID 32. The second session ID, 48050, shows that a Telnet session between the same hosts is using route ID 33. You have already seen from the routing table that the 10.1.4.0/24 network is reachable via route IDs 32 and 33.
4.7. Create Static Routes for Gateway Tracking
Problem
You want to configure static routes for networks behind a remote router that is reachable through multiple paths.
Solution
Configure static routes with only a next-hop gateway address. You do not include the outgoing interface in this command:
SSG-> set vr trust-vr route 10.10.10.0/24 gateway 10.1.4.32Discussion
This recipe configures static routes between two IP subnets—10.2.1.0/24 and 10.2.2.0/24, which are behind the New York firewall and are reachable through two different OSPF paths from Chicago (see Figure 4-5).
Here is the configuration on the Chicago firewall for the static routes 10.2.1.0/24 and 10.2.2.0/24 reachable via the 10.1.4.32 gateway:
set vrouter "trust-vr" set route 10.10.10.0/24 gateway 10.1.4.32 set route 10.20.20.0/24 gateway 10.1.4.32 exit
If you look at the routing table using the get route command, you will notice that the route entries for the 10.10.10.0/24 and 10.20.20.0/24 IP subnets actually show the next-hop gateway of 10.1.2.100 even though you configured the next-hop gateway for these subnets as 10.1.4.32. This is because the gateway tracking feature identified that, to reach the 10.1.4.32 address, the device needs to use the 10.1.2.100 gate-way. The 10.1.4.0/24 IP subnet is learned from OSPF and is best reachable via 10.1.2.100. Hence, the firewall can update the outgoing interface and the directly connected next-hop gateway for the static routes 10.10.10.0/24 and 10.20.20.0/24.
Chicago->get routeIPv4 Dest-Routes for <untrust-vr> (0 entries) -------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 IPv4 Dest-Routes for <trust-vr> (10 entries) ------------------------------------------------------------------ ID IP-Prefix Interface Gateway P Pref Mtr Vsys ------------------------------------------------------------------ * 25 0.0.0.0/0 eth0/1 1.1.1.1 S 20 1 Root * 19 10.1.2.1/32 eth0/1 0.0.0.0 H 0 0 Root * 4 10.1.1.1/32 eth0/0 0.0.0.0 H 0 0 Root * 51 10.1.5.1/32 eth0/1 10.1.2.100 O 60 1 Root* 50 10.1.4.0/24 eth0/1 10.1.2.100 O 60 3 Root* 3 10.1.1.0/24 eth0/0 0.0.0.0 C 0 0 Root* 55 10.10.10.0/24 eth0/1 10.1.2.100 S 20 1 Root * 56 10.20.20.0/24 eth0/1 10.1.2.100 S 20 1 Root* 18 10.1.2.0/24 eth0/1 0.0.0.0 C 0 0 Root * 52 10.1.3.0/24 eth0/1 10.1.2.100 O 60 2 Root
If a failure occurs in the path to reach 10.1.4.32 and it is not reachable through a dif-ferent path, the entries in the routing table change because the path changes. The following output shows the routing table after the path change. Notice that the 10.10.10.0/24 and 10.20.20.0/24 IP subnets now have a next-hop gateway of 10.1.2.200. This was changed because the 10.1.4.0/24 subnet changed it when the previous path failed. The best route is now via 10.1.2.200. The gateway tracking feature tracks the reachability of the gateways and automatically modifies the immediate next hop.
Chicago->get routeIPv4 Dest-Routes for <untrust-vr> (0 entries) -------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 IPv4 Dest-Routes for <trust-vr> (10 entries) ------------------------------------------------------------------ ID IP-Prefix Interface Gateway P Pref Mtr Vsys ------------------------------------------------------------------ * 25 0.0.0.0/0 eth0/1 1.1.1.1 S 20 1 Root * 19 10.1.2.1/32 eth0/1 0.0.0.0 H 0 0 Root * 4 10.1.1.1/32 eth0/0 0.0.0.0 H 0 0 Root * 58 10.1.5.1/32 eth0/1 10.1.2.200 O 60 2 Root* 57 10.1.4.0/24 eth0/1 10.1.2.200 O 60 3 Root* 3 10.1.1.0/24 eth0/0 0.0.0.0 C 0 0 Root* 61 10.10.10.0/24 eth0/1 10.1.2.200 S 20 1 Root * 60 10.20.20.0/24 eth0/1 10.1.2.200 S 20 1 Root* 18 10.1.2.0/24 eth0/1 0.0.0.0 C 0 0 Root * 59 10.1.3.0/24 eth0/1 10.1.2.200 O 60 2 Root
4.8. Export Filtered Routes to Other Virtual Routers
Solution
Configure static routes with tags and use route maps to export only those routes with specific tags:
set vrouter "trust-vr" set route-map name "tag10_routes" permit 1 set match tag 0.0.0.10 exit set export-to vrouter "vpn-vr" route-map "tag10_routes" protocol static set route 192.168.1.0/24 interface ethernet0/0 gateway 10.1.1.10 tag 10 set route 192.168.20.0/24 interface ethernet0/0 gateway 10.1.1.10 tag 10 set route 192.168.3.0/24 interface ethernet0/0 gateway 10.1.1.10 exit set vrouter name "vpn-vr" id 1025 set vrouter "vpn-vr" unset auto-route-export exit set vrouter "vpn-vr" exit
Discussion
Let’s say you have configured multiple VRs on the firewall and have identified routes that need to be provided to other VRs, and you want to provide only specific IP subnets to other VRs but these are noncontiguous routes, so you can’t aggregate them.
To be able to export these routes, you configure the static routes with a tag and then use the configured route tags as filters to export the routes to other VRs. We configure static routes for IP subnets 192.168.1.0/24 and 192.168.20.0/24 in the trust-vr with a route tag value of 10.
In the trust-vr, we configured the route map named tag10_routes with a permit action and a sequence number of 1. The sequence number is used to define the order in which route maps are applied to the VRs. In the route map tag10_routes, we configured the match criteria of the tag with a value of 10. This is a basic route-map configuration; we can add other match criteria as well.
After configuring the route maps, we then use the set export-to command to export routes to vpn-vr using the route map tag10_routes and a protocol type of static.This command exports the routes matching the criteria configured in the route maps. You should be aware that the routes are exported only if they are active in the routing table.
You can verify the routing tables with the get route command:
SSG->get routeIPv4 Dest-Routes for <untrust-vr> (0 entries) --------------------------------------------------------------------- H: Host C: Connected S: Static A: Auto-Exported I: Imported R: RIP P: Permanent D: Auto-Discovered N: NHRP iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1 E2: OSPF external type 2 trailing B: backup route IPv4 Dest-Routes for <trust-vr> (11 entries) ------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr Vsys ------------------------------------------------------------------- * 8 0.0.0.0/0 eth0/1 10.1.2.200 S 20 1 Root * 4 10.1.2.1/32 eth0/1 0.0.0.0 H 0 0 Root * 2 10.1.1.1/32 eth0/0 0.0.0.0 H 0 0 Root * 10 10.1.5.1/32 eth0/1 10.1.2.200 O 60 2 Root* 12 192.168.20.0/24 eth0/0 10.1.1.10 S 20 1 Root * 7 192.168.3.0/24 eth0/0 10.1.1.10 S 20 1 Root * 5 192.168.1.0/24 eth0/0 10.1.1.10 S 20 1 Root* 9 10.1.4.0/24 eth0/1 10.1.2.200 O 60 3 Root * 1 10.1.1.0/24 eth0/0 0.0.0.0 C 0 0 Root * 3 10.1.2.0/24 eth0/1 0.0.0.0 C 0 0 Root * 11 10.1.3.0/24 eth0/1 10.1.2.200 O 60 2 Root IPv4 Dest-Routes for <vpn-vr> (4 entries) -------------------------------------------------------------------- ID IP-Prefix Interface Gateway P Pref Mtr -------------------------------------------------------------------- * 2 10.200.200.1/32 eth0/3 0.0.0.0 H 0 0* 5 192.168.20.0/24 n/a trust-vr SI 140 1 * 3 192.168.1.0/24 n/a trust-vr SI 140 1* 1 10.200.200.0/24 eth0/3 0.0.0.0 C 0 0 SSG->
Notice that the routing table in the trust-vr has four active static routes: the default route, 192.168.20.0/24, 192.168.3.0/24, and 192.168.1.0/24. If you review the configuration in the trust-vr, you can see only the tagged routes 192.168.20.0/24 and 192.168.1.0/24 with a tag value of 10. Based on the filters applied in the route map, the firewall exports only those routes with a tag value of 10. After the export rule is applied to the trust-vr, you can see that the vpn-br has four routes: two routes generated by the directly connected interface eth0/3, which are the 10.200.200.1/32 host route and the 10.200.200.0/24 network route for the interface; and two static routes from the trust-vr, which are 192.168.20.0/4 and l92.168.1.0/24, with a next-hop gateway of trust-vr and a protocol type of SI, which means static and imported.
4.9. Change the Route Lookup Preference
Problem
You have configured source-based routing on the firewall and want to change the route lookup preference for matching routes.
Solution
You can change the route lookup preference on the VR. The following command changes the preference for source-based routing to 100:
set vr trust-vr route-lookup preference source-routing 100
Discussion
When you have multiple route types such as source-based and source interface-based routes configured on the VR, the default route lookup preference is source interface-based routes (SIBR) first, source-based routes (SBR) next, and destination-based routes (DRT) last.
When a packet arrives on the firewall, the route lookup checks whether SIBR is enabled on the VR. If it is, the firewall looks for the route based on the source IP address of the packet for the incoming interface. You must have a source route configured for that interface for this match to succeed. All the source interface-based routes are stored in the SIBR routing table. When a route matches, the firewall forwards the packet using that path. If no SIBR route is found, it checks to see whether SBR is enabled on the VR.
Next, the route lookup checks whether there is a route in the SBR routing table that matches the packet’s source IP address. The source IP address route can come from any interface in that VR, unlike the SIBR route, which checks only whether the route exists for that incoming interface. If the source IP address matches a route, the packet is forwarded using that path.
If no SBR route is found, the final route lookup is done using the DRT. Here, the match is based on the packet’s destination IP address. If this address matches a route, it is forwarded using that path. If no route is found, the packet is dropped.
Figure 4-6 illustrates the default route lookup preference.
You can change the default route lookup preference behavior by using the set vr trust-vr route-lookup preference command. Here, we want the source-routing preference to have a weight of 100. The higher the weight is, the higher the preference is. So, we change the route lookup order to be SBR, then SIBR, and finally DRT.
You can use the following command to verify the route lookup preference on the VR:
SSG-> get vr trust-vr route-lookup preference
vrouter(trust-vr) route-lookup preference table(sorted by preference):
------------------------------------------------
route-lookup-method preference
------------------------------------------------
Source-IP-lookup 100
SIBR-route-lookup 3
destination-IP-lookup 1
SSG->This output shows that the source IP lookup has a preference of 100, which is higher than the other lookups. Hence, the SBR is the first routing table to be consulted, followed by the SIBR routing table, and finally the DRT routing table.
4.10. Create Permanent Static Routes
Problem
You want to have permanent static routes on the firewall so that the routes are available even if the local interface goes down.
Solution
Configure a static route with the permanent keyword:
SSG-> set route 172.16.10.0/24 interface e0/0 gateway 10.1.1.10
permanentDiscussion
Often, you have situations when your network interface flaps and the applications behind that interface then become unreachable. The problem can be severe when you are using dynamic routing protocols and static route redistribution because it can take a long time for the routes to converge.
To keep the routes available when the interface flaps, you can configure a static route that remains permanently in the routing and is not withdrawn even if the interface associated with that route is down. We configure the route to the 172.16.10.0/24 network that is reachable via the e0/0 interface with a next-hop gateway of 10.1.1.10 and that is available permanently, even if the e0/0 interface goes down.
Keep in mind that if this route is redistributed into an Interior Gateway Protocol (IGP), there is no alternative path to reach this network. You should use this configuration only when there is no possibility of reaching this network through a different path.
Get ScreenOS Cookbook now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
