O'Reilly logo

ScreenOS Cookbook by Sunil Wadhwa, Joe Kelly, Ken Draper, David Delcourt, Vik Davar, Stefan Brunner

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

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.

Configuration of the firewall

Figure 4-3. Configuration of the firewall

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 0kbps

This 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 route
	IPv4 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 0

When 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.1
	  routed (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-frag
	  going 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 route
	IPv4 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 0

When 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.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required