Static routes use MAC address as gateway
I try to set a static route between two Netgate appliances, R1 and R2. They are connected via two switches, sw1 and sw2. The connection is as follows: R1 <> sw1 <> sw2 <> R2.
R2 offers DHCP on its LAN interface lagg0.4091. R1 is configured to acquire a DHCP address on the interface igb1.1234. Thus far, both can talk to each other. R2 listens on 192.168.1.1, R2 gets 192.168.1.10.
Using an ssh tunnel I setup R2 to listen on several VLAN IDs on a different interface. I connected a device with IP 10.3.20.22 to one of these VLAN interfaces, 10.3.20.1 (R2).
Now, I wanted to have subnets on both sides talk to each other, 10.0.20.0/24 and 10.3.20.0/24. I guessed a static route would be the way to go. On R1 I configured the interface igb1.1234 as a gateway interface and configured the destination 10.3.20.0/24 behind the gateway.
This results besides others in the following routes (
netstat -rnf inet):
10.3.20.0/24 ac:1f:6b:95:0c:03 US igb1.123 192.168.1.0/24 link#24 U igb1.123 192.168.1.1 ac:1f:6b:95:0c:03 UHS igb1.123
Strangely, it uses the MAC address as a gateway.
When trying to
ping 10.3.20.22, tcpdump on R2 shows ARP requests incoming on lagg0.4091:
ARP, Request who-has 10.3.20.22 tell 192.168.1.10, length 46
I was a little confused at first. But then, this shouldn't happen, should it? AFAIK R1 should just throw the IP packages at 192.168.1.1 and tell it to do with them whatever it deems best with them.
A friend suggested to delete the route and add it manually,
route del 10.3.0/24and
route add 10.3.0.24 192.168.1.1, which I did. And behold, it worked! I could ping the host. The new route showed up as
10.3.20.0/24 192.168.1.1 UGS igb1.123
No MAC address here.
So, my initial approach seemed sensible but didn't work out with pfSense. Can someone explain to me
- what does pfSense do internally when adding a static route? I guess there's a good ratio behind these decisions I just don't understand yet.
- how would I achieve what I intend to do with the proper pfSense workflow?
As the new gateway is now at its final destination and doesn't need this kind of hack anymore, I guess I can close this post.