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:

Option 1: DENY policy to block RFC 1918 address ranges

Configure Address Objects for RFC 1918 and an 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

Configure the firewall policy to DENY (BLOCK) traffic from the WAN for 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).

Option 2: ACCEPT Policy excluding RFC 1918 address ranges

Similar to Option 1, but instead of a deny policy it is possible to create an address group allowing all addresses and excluding the RFC 1918 address ranges. This can be done using the address group from Option 1.

This simplifies the configuration: only one 'ACCEPT' firewall policy is needed, rather than a 'DENY' policy for the RFC 1918 address range followed by an 'ACCEPT' policy allowing traffic to the Internet.

In the GUI, go to Policy & Objects -> Addresses, select Create New -> Address Group and create an address group with 'all' as a member. Then select 'Exclude members' and the RFC 1918 address group. This will create an address group for every IP address except all the private IP address ranges.

Example configuration on the CLI:

config firewall addrgrp
edit "G - ALL PUBLIC ADDRESS RANGES"
set member "all"
set exclude enable
set color 10
set exclude-member "G - ALL PRIVATE ADDRESS RANGES"
next
end

This address group can now be used for an 'ACCEPT' policy for traffic destined to the Internet.

In the GUI, Policy & Objects -> Firewall Policy -> Create new. When creating the policy select the incoming interface, the outgoing WAN interface.

The source addresses can be the LAN addresses, the RFC 1918 address group, or 'all'. For the destination, use the address group that excludes all the RFC 1918 addresses. Configure the schedule and service, enable NAT.

On the CLI:

config firewall policy
edit 0

set name "Allow_Public_Ranges_Only"
set srcintf "any"
set dstintf "WAN_LAG"
set action accept
set srcaddr "all"
set dstaddr "G - ALL PUBLIC ADDRESS RANGES"
set schedule "always"
set service "ALL"
set nat enable
next
end

Option 3: Blackhole routes

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, the 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.

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

You are leaving our website