Technical Tip: Prevent RFC 1918 (LAN subnets) network traffic from exiting the WAN interface

agrakov · ‎08-23-2022

Description

This article prevent RFC 1918 (LAN subnets) network traffic from exiting the WAN interface.

Scope

All FortiOS.

Solution

Prevent RFC 1918 (LAN subnets) network traffic from exiting the WAN interface.

RFC 1918 private address blocks are:

10.0.0.0 - 10.255.255.255 (10/8 prefix)

172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

If the FortiGate WAN connection indicates a public IP address, then - General best practices to prevent RFC 1918 leave the WAN interface – just by simple reason to keep the LAN information behind the unit.

Note.

Depending on network topology, some scenarios exist where it is better to do not block RFC 1918 to leave the WAN interface, such as downstream FortiGate, or if the ISP uses private ranges.

To block RFC 1918 traffic leaving the WAN interface, it is necessary to configure the following:

1) Configure Address Objects for RFC 1918 and address group for the subnets. It is possible do it from the GUI or CLI.

From the GUI:

Go to Policy & Objects -> Addresses, select Create New -> Address and add address objects for RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

From CLI:

# config firewall address

edit "PRIVATE ADDRESS RANGE - LAN - 10.0.0.0/8"

set color 10

set subnet 10.0.0.0 255.0.0.0

set color 10

set subnet 172.16.0.0 255.240.0.0

set color 10

set subnet 192.168.0.0 255.255.0.0

Go to Policy & Objects -> Addresses, select Create New -> Address Group and include address objects that we previously created.

From CLI:

# config firewall addrgrp

edit "G - ALL PRIVATE ADDRESS RANGES"

set member "PRIVATE ADDRESS RANGE - LAN - 10.0.0.0/8" "PRIVATE ADDRESS RANGE - LAN - 172.16.0.0/12" "PRIVATE ADDRESS RANGE - LAN - 192.168.0.0/16"

set color 10

2) Configure Firewall policy to DENY (BLOCK) traffic distant to WAN for the RFC 1918 subnets.

Example of configured policy:

- 'Incoming Interface' will be the LAN interface, or it is possible to use ANY (depending on the network topology).

- 'Outgoing Interface' will be the WAN interface.

- 'Source' will be the LAN subnets or it is possible to use the address group for RFC 1918.

- 'Destination' will be RFC 1918 ('G - ALL PRIVATE ADDRESS RANGES'):

'Schedule' always.

'Service' ALL.

'Action' DENY.

Example of configured policy from CLI:

# config firewall policy

edit 0

set name "BLOCK RFC 1918 via WAN"

set srcintf "any"

set dstintf "WAN_LAG"

set srcaddr "G - ALL PRIVATE ADDRESS RANGES"

set dstaddr "G - ALL PRIVATE ADDRESS RANGES"

set schedule "always"

set service "ALL"

set logtraffic all

set comments <----- Block private network to pass private network traffic over WAN (ISP).

end

Method 2 with Blackhole route

From CLI add 3 static routes for RFC 1918 with the blackhole enable.

The distance should be 254, allowing other static entries with lower Administrative distances to be preferable.

# config router static
edit 0
set dst 10.0.0.0 255.0.0.0
set distance 254
set blackhole enable
next
edit 0
set dst 172.16.0.0 255.240.0.0
set distance 254
set blackhole enable
next
edit 0
set dst 192.168.0.0 255.255.0.0
set distance 254
set blackhole enable
next
end

Or via GUI:

Go to Network' -> Static Routes, select 'Create NEW' and add RFC 1918 networks.

In the Destination field, it is possible to use Subnet or Named Addresses for RFC 1918 with Administrative Distance 254 and interface Blackhole.

Expected behavior without blackhole routes:

When the FortiGate has an active route for the Private LAN it will be passed with the corresponding interface, if the LAN/VPN interface goes down, then the active route will be removed from the FortiGate routing table, and the traffic will be sent via the default route.

Blackhole routes are helping to prevent traffic from leaving via the default route.

By adding Blackhole routes FortiGate is being told to drop the requests silently if there are no more specific routes.

There are some specific scenarios, where ISP has the private IP address for the gateway and if the PC from the LAN will try to send some traffic for the gateway IP (let’s say NetBIOS traffic etc), then the traffic will reach the GW and, in this case, Blackhole will not make an effect on it, as the more specific route is active.

# get router info routing-table all

Routing table for VRF=0

S* 0.0.0.0/0 [5/0] via 10.11.12.169, ppp6, [1/0]
C 10.11.12.169/32 is directly connected, ppp6

With method 1, that traffic will be blocked.

Note.

It is possible to use both methods at the same time, there is no harm in it.

When configuring Dynamic routing protocols, local static routes will be considered preferable as they're 'local' on this device.