PfSense 2.1.3 - Route doesn't survive reboot



  • Hi everybody:

    I have a PFSense 2.1.3-Stable running with this topology:

    LAN1 (192.168.1.0/24 ) –-- em0 (192.168.1.1/24) [PFSense] (190.12.xxx.xxx) bg0 –--- Internet ------ fa4 (181.177.xxx.xxx) [Cisco 881] (192.168.2.1/24) –--- LAN2 (192.168.2.0/24)

    (172.16.0.1/24) gre0 ----- ||GRE|| ------- tun0 (172.16.0.2/24)
    What we are trying to achieve are the following objectives:

    • Create a GRE Tunnel from LAN2 to LAN1
    • Secure the tunnel with IPSEC Transport mode.
    • Route all traffic from LAN2 to LAN1 and to the Internet.

    I tried to use an IPSec Tunnel mode, which worked great...but it won't route all traffic as needed.

    Then, we tried to use a GRE tunnel between the Cisco 881 and PfSense. Added routes to LANs on both sides and it worked great.... until I rebooted the PFsense to test network recovery.

    After reboot, the gre tunnel is UP (I can ping to each side), but the route to LAN2 is not on the Route Table in the pfSense box. I have to manually add it again.

    Have you ran with these problems, too?

    Regards,

    Marco



  • What do you mean by "manually add it again", how are you adding it?



  • Hi cmb,

    Manually adding again is deleting the route and add it up in the System | Routing | Routes in the webconfig. That fixes the issues temporarily until next reboot.

    Now, another issue comes up…the gre0 interface won't get into the RUNNING state. Some reboots yes, some not. It is not reliable. I have to issue a ifconfig gre0 up command to enable it. When it comes up, the static route to LAN2, although defined, is not showing on the route table.

    gre0: flags=9051 <up,pointopoint,running,link0,multicast>metric 0 mtu 1476
            tunnel inet 190.12.82.163 --> 181.177.246.218
            inet 172.16.0.1 --> 172.16.0.2 netmask 0xffffff00
            inet6 fe80::215:17ff:fe0a:f31b%gre0 prefixlen 64 scopeid 0x8
            nd6 options=3 <performnud,accept_rtadv>Routing tables
    
    Internet:
    Destination        Gateway            Flags    Refs      Use  Netif Expire
    default            190.12.xxx.xxx     UGS         1     1465    em0
    10.100.8.197       190.12.xxx.xxx     UGHS        0      208    em0
    localhost          link#6             UH          0        2    lo0
    172.16.0.1         link#8             UHS         0        2    lo0
    172.16.0.2         link#8             UH          0        2   gre0
    190.12.xxx.xxx/29   link#1             U           0        0    em0
    190.12.xxx.xxx     link#1             UHS         0        0    lo0
    192.168.1.0        link#3             U           0      667   bge0
    mf_fw01            link#3             UHS         0        0    lo0</performnud,accept_rtadv></up,pointopoint,running,link0,multicast> 
    

    I've seen this:

    http://www.freebsd.org/cgi/query-pr.cgi?pr=138407
    and
    http://www.freebsd.org/cgi/query-pr.cgi?pr=164475

    From the Cisco side, everything's ok. BTW, this is the config:

    interface Tunnel0
     ip address 172.16.0.2 255.255.255.0
     ip mtu 1476
     keepalive 5 3
     tunnel source CISCO WAN IP
     tunnel destination PFSENSE WAN IP
    
    

    I still have no clue on how to fix this…



  • Cmb,

    I did a few reboots in my testing environment. It has the same issue. Gre0 tunel won't come up after reboot. If it comes up, route is not present in the routing table and has to be manually deleted and added again.

    Just to let you know, the production and testing environment were working with the 2.0.3-Stable a few weeks ago before implementing GRE. We upgraded to 2.1.3 in order to protect us from heartbleed.

    I will be traveling this next week, so I won't be able to create a new lab with a new install…I'll try that the next week. However, what insights can you give me as a workaround?

    Regards,

    Marco



  • That definitely sounds like the circumstance noted in those FreeBSD PRs. The work around there is to run "ifconfig greX up" via shellcmd after boot, and have it manually add the routes that way as well. That's been fixed in 10.x so won't require any workarounds in 2.2.


Log in to reply