I do have a test LAN with its own IP range and I want to reach that test LAN from my productive LAN.
For that, I have a software router based on pfSense, which has one virtual network interface in my production LAN and one in the test LAN. On my main router I added a static route for that.
About two weeks ago, that setup suddenly did no longer work. At least from all Linux and Mac OS based machines, I was unable to reach IP addresses in the test LAN. From Windows machines this still did work.
To be able to explain it a bit better, let us assume the following IP addresses:
|
1 2 3 4 5 6 |
Production network: 10.1.1.0 Test network: 10.1.2.0 IP address main router: 10.1.1.1 IP address pfSense (in production network): 10.1.1.130 IP address pfSense (in test): 10.1.2.1 Static route on main router: 10.1.2.0 via 10.1.1.130 |
The message I got, if I tried to ping an address in the test LAN (e.g. from a machine with IP 10.1.1.120), was something like
|
1 2 |
ping 10.1.2.10 From 10.1.1.120: icmp_seq=6 Redirect Host(New nexthop: 10.1.1.1) |
So it is quite normal that the main router sends the client an ICMP redirect, because there is a more direct route to the 10.1.2.0 network via the pfSense virtual router on 10.1.1.130. So no need to go first to 10.1.1.1.
The Windows machines were still correctly responding to these ICMP redirects, the Linux and Mac OS machines did not.
I have no idea what might have changed, in either my network configuration or in Linux/Mac OS, that this no longer worked. Maybe there was some kind of patch currently delivered to Linux and Mac OS which disabled that.
However, because ICMP redirects could be a potential security whole, I decided that all machines in the production LAN should get a direct the static route to the test network. As all my devices are using DHCP to configure the network parameters automatically (also the ones which should have a fixed IP address!), I was able to just push the static route via the DHCP “classless static routing” option. So no need to configure it on every single device. This should work with most of the current devices.
The DHCP option for classless static routing is “121” and you need to use a special syntax for that:
|
1 |
121,subnetmask,netaddress,router address |
So for the example above (class C network, network 10.1.2.0/24, address of the router 10.1.1.130) it is:
|
1 |
121,24.10.1.2,10.1.1.130 |
Here are the steps for DNSMASQ (the DHCP server I am using on my OpenWRT based router):
- Edit “/etc/config/dhcp”
- Add the following dhcp_option line to your DHCP LAN definition:
|
1 2 3 4 5 |
... config dhcp 'lan' ... list dhcp_option '121,24.10.1.2,10.1.1.130' ... |
- Restart DNSMASQ:
/etc/init.d/dnsmasq restart
Now as soon as a device renews its DHCP configuration, it should also get a static route to the 10.1.2.0/24 network via 10.1.1.130.
Update:
If you add a “classless static routing” option, then Linux machines ignore the default gateway and only set the routes added via the classless static routing. So you need to set also the default gateway like that (default gateway is 10.1.1.1):
|
1 2 3 4 5 |
... config dhcp 'lan' ... list dhcp_option '121,24.10.1.2,10.1.1.130,0.0.0.0/0,10.1.1.1' ... |