Configuring multiple networks behind the same interfaceLast modified on 21 Oct, 2022. Revision 9
|Up to date for||
I want to add a second network behind one of my Ethernet interfaces. How can i achieve this?
Lets say we have the following IP and network used on our Dmz interface:
Dmz_IP = 192.168.1.1
Dmz_Network = 192.168.1.0/24
Now we want to add a second IP and network behind the Dmz interface. We want the users behind the new network to be able to use 192.168.2.1 as their default gateway.
Dmz_IP_2 = 192.168.2.1
Dmz_Network_2 = 192.168.2.0/24
In order to achieve this we only need to add one single route in the routing table that looks like this:
Route Dmz Dmz_Network_2 LocalIP=Dmz_IP_2
Local IP is very important to use here. Local IP does **two ** important things:
- It ARP publishes the defined IP address on the selected interface.
- It uses the defined IP address as sender when doing ARP queries towards the defined network.
Machines in the new 192.168.2.0/24 network would reasonably want to use 192.168.2.1 as their default gateway, and this will work fine as we have ARP published it using Local IP.
It also works in the other way around. When the Firewall wants to perform an ARP query towards e.g. 192.168.2.50 it will use 192.168.2.1 as sender IP for this ARP query. And since the source IP then will be part of the 192.168.2.0/24 network, the client will respond without any problems.
What happens if Local IP is not used?
Lets assume that we forgot to set the Local IP on the route. That would mean that when the Firewall performs an ARP query to find 192.168.2.50 it will use the defined IP address on the Dmz interface (192.168.1.1) as sender. The client will get very confused by this as it’s a request from an IP address that is not part of it’s own network, and will reject it.
Also, unless we have manually ARP published 192.168.2.1 on the Dmz interface to make the Firewall responds to ARP queries towards this IP, the clients will be unable to ARP query their “default gateway” and will be unable to reach anything past their local network segment.
To configure multiple IP addresses behind the same interface, see: https://kb.clavister.com/324735780/adding-an-additional-ip-address-to-an-ethernet-interface
Core route the IP address used as Local IP
It is recommended to also Core route the IP address used as Local IP by adding another route looking like this:
Route Core Dmz_IP_2
The reason for this recommendation is because the new IP (Dmz_IP_2 in the example) will then behave the same as an interface IP that belongs to the firewall when it comes to configure IP policies, VPN tunnels, OneConnect and more. It could cause some confusion as why a non-core routed IP must be configured/used differently and there is no disadvantage of Core routing the IP in this scenario.
27 Jan, 2023 ikev2 windows vpn routing splittunneling
9 Dec, 2022 arp core
19 Feb, 2021 core arp
22 Mar, 2021 core ipsec routing
23 Aug, 2022 vmware log ha rarp arp core
17 Jun, 2021 core ipsec routing
23 Aug, 2022 core arp garp
8 Apr, 2021 core sslvpn oneconnect interfaces arp
30 Nov, 2022 core routing
1 Jun, 2022 core routing management
25 Nov, 2022 core routing bgp
23 Aug, 2022 howto core pbr routing netwall isp
15 Dec, 2022 core routing ospf
7 Nov, 2022 core arp log routing
7 May, 2021 core ethernet vlan arp garp
27 Jan, 2021 core stateless routing brokenlink