No default route in routing table

  • After sitting on a couple-months-old 2.0 snapshot for a while, I decided tonite to update to something more current. The auto-updater hadn't been working in a while either, so I went and pulled down the 20100620-2025 Full Update and installed it via the Firmware page on the GUI.

    Upgrade went fine and it rebooted normally. When it was back though, packets weren't passing. This is a basic 1 LAN/1WAN (DHCP to cablemodem) SOHO type firewall  nothing fancy. The GUI Interface Status looked normal - had an IP and Default route showing there. Checking in via SSH though showed that there was no IPv4 default route in the routing table.

    Since this is BETA territory, I started backing up thru a couple earlier images  - 20100618 and 20100617, all with the same effect.  Finally I jumped back a little further to 20100529 and everything came up (so far) normally.

  • Did you get record of your system log when the gateway wasn't being added?  I just upgraded a 2.0 install with DHCP WAN to the most recent snapshot and it's working fine. Way too many changes between 5/29 and now for that to be of much help, but the system log should show something.

  • I can think that the config is not properly suitable for latest snapshot. (since there is no config upgrade in-between BETA changes)
    Can you try going re-saving  your gateways fixes the problem?

  • Unfortunately, no, I didn't manage to capture any logs. SWMBO was in the middle of trying to post some classwork so I was under orders to get it back up ASAP.

    Not sure what you mean about saving the default GW - I'm taking (via DHCP) the default route that Comcast hands me. No config changes. When I get some downtime though, I'll try another snapshot and see if it's repeatable or not. Fortunately this is all running in a a VM so I can just snapshot the working config and roll back pretty quickly if it goes pear-shaped again.


  • Sorry for the long delay. I finally got around to trying another upgrade to the latest snapshot (6/29) and encountered the same issue. This time I did some actual troubleshooting though.

    I found that I still had a Gateway Group defined from a prior experiment using a 3G modem as a backup. It's been working fine under the old image (where I created this config) but not for any of the newer images I tried. When I removed the Gateway Group and re-enabled the cablemodem interface as a default route, it started working correctly again.

  • hi,

    Looks like the box somehow won't let the packets go through even there's a default route provided by pppoe(my case), which appears in kernel routing table but not in pfbox's gateway table, if you go Status->Gateway. It's empty, and that is the problem. I'm on BETA3-20100629-1737.tgz(full)


    Can you try going re-saving  your gateways fixes the problem?

    Yes, that fixes problem. Go System->Routing and click edit then just save and apply.


  • I had a similar issue here which is now resolved thanks to this post. Simple single LAN/DHCP WAN config.  Upgraded from a late April (28?) 2.0 build using: pfSense-Full-Update-2.0-BETA3-20100630-1459.tgz

    I had to go to System->Routing->Gateway->Edit WAN gateway->Check/Select "Default Gateway"->Save to get traffic flowing.


  • hmmmmmmmmmm….still happens to me as of today, well, not just today but every single snap since late May. Re-saving my gateway config is only way to fix the issue. Something doesn't seem to be updated correctly while moving snaps.


  • I'm running 2.0-BETA4  (i386)
    built on Thu Sep 9 19:39:18 EDT 2010
    FreeBSD 8.1-RELEASE

    I have LAN, WAN and OPT1 to OPT4 interfaces including a 3G modem and two wireless (WiFi) NICs. My WAN NIC gets its IP address by DHCP. It is a bit cranky about the physical connection and on a couple of reboots didn't detect carrier. Some time afterwards on one boot and after I had wiggled the cable a bit, the WAN NIC had an IP address but there was no default route in the pfSense box. Next time I rebooted the box the WAN NIC apparently got an IP address immediately and there was a default route (through the WAN interface).

Log in to reply