Some routes added in console disappearing
Due to the way a vendor requires a VPN connection to work, I need to add some routes in the shell (and will add them to an rc script once it's stable this way):
route add 10.2.10.0/24 -iface rl0
route add -net x.x.0.0/16 10.2.10.1
route add x.x.108.114 y.y.131.1
In the third route above, the first address is a specific host in the /16 subnet from the route above and the second address is the default gateway of the WAN. This route keeps disappearing. Everything works wonderfully while it's there and then poof! VPN is down because the route has vanished. All other routes that I've added by hand stick around just fine. (There are several others - these are the only ones that affect this specific VPN.) If necessary, I can explain in more detail the network setup involved but it would probably suffice to know what process might be removing routes from the table and why. I'm guessing that it has something to do with the fact that the route points to the default gateway. Unfortunately, the remote VPN endpoint lies within the remote network of the VPN so I need a more specific route to just the endpoint.
Thanks in advance for any insights…
Anything in the system log at the time?
Any reason you can't put that last route in as a static route in the GUI?
There is nothing in the log involving routes other than the add/deletes for pptp VPN connections.
I didn't use the "static routes" in the GUI because I wanted to keep all of my manually added routes in the same place - namely my rc scripts since the -iface rules can't be added in the GUI. Hm. It doesn't appear that I can put the x.x.0.0/16 -> 10.2.10.1 route in the static routes GUI unless I already have the -iface route for 10.2.10.0/24. I mean, I can put it in, but it doesn't show up in the routing tables. I guess that makes sense, actually.
Feb 21 14:51:28 kernel: arplookup 10.2.10.1 failed: host is not on local network
Feb 21 14:51:28 kernel: arpresolve: can't allocate route for 10.2.10.1
until I use "route add 10.2.10.0/24 -iface rl0" in a shell - then all is well.
That leads to the next question:
LAN x.x.0.0/16 10.2.10.1 To pfSense2 for VPN NAT
WAN x.x.108.114/32 x.x.131.1 For VPN endpoint
in the GUI. Maybe they will persist better in there. However, the first of those routes will fail to add until the -iface rule is added by the rc script. How do I ensure that the rc script runs first? What's best practice for custom start scripts in pfSense?
Look at the shellcmd package, you could try setting your script (or the commands directly) up as a shellcmd there, or perhaps an earlyshellcmd.
I suspect something is coming along and resetting the routes on WAN, which isn't surprising, but it's really hard to say. You should see something in the logs about the time the routes disappear.
You might try adding a call to your script at the end of rc.newwanip as well.
Thanks for your help. :) I'l try your suggestions… ...and wait patiently for the day when 2.0 is final and I can bind additional addresses to the actual interfaces and eliminate the need for some of these workarounds.