Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Lessons learned from 1.2.3 upgrade to 2.0 RC3

    Scheduled Pinned Locked Moved General pfSense Questions
    3 Posts 2 Posters 1.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • R
      raivisr
      last edited by

      Just wanted to share how it all went.

      I have 3 boxes running and connecting 3 remote offices each in it's own country. Each office has 2 separate internet connections and over those there are 2 openvpn tunnels between every two offices. I use policy based routing with failover and tap tunnels with taps defined as OPT interfaces, so that is not really a typical setup. Besides there is pptp server with radius authentication (MS IAS as backend) and BGP routing with OpenBGPD.
      It all was running fine until one customer that has ipsec tunnel to one of the offices wanted to push more than one subnet over that tunnel, which called for an upgrade as this customer was not willing to set up multiple tunnels and supernetting was not an option too. And they needed that "yesterday" as always.

      Lesson number 1:
      I tried to upgrade remote system and that lead to pfSense box being down until remote location admin came to work next morning. pfSense was stuck at assign interfaces dialog on console. No way I am upgrading any pfSense remotely again :)

      Lesson number 2:
      Names of tap interfaces have changed, what used to be tap1..tap4 now is ovpns1..2 for servers and ovpnc1..2 for clients. Had to recreate all my OPT interfaces.

      Lesson number 3:
      My openvpn tunnels used to pass all traffic in all directions with simple pass any to any rule. Now I got into problem, upgraded pfSense wouldn't let traffic get back to originator when policy based routing was used. Connections made from lan behind pfSense 2.0 wourked like a charm, but not those made from lans with old pfSense, return traffic would get stuck in upgraded router. It worked ok with static routes, but not with policy based routing. Apparently there is new advanced option that by default blocks all IP traffic with IP options set even if you create rule "pass any to any." So until I figured that I need to check that "Do not block IP with options" checkbox in advanced options on my "pass any to any" rule it wasn't really "pass any to any" rule.

      Lesson number 4:
      PPTP server config got messed totally up. Instead of RADIUS server IP and secret I got "1" and there was no way I could fix that from GUI. Remedy was simple - a) console b) vi /conf/config.xml c) dd on all lines between <pptpd>and</pptpd> d) reboot e) recreate config from GUI.

      Lesson number 5:
      Never try to assign gateway with ip the same as on interface itself. That leads unresponsive system that does not boot up properly, reboot into safe mode, fsck, and manual editing of config.xml :)

      Lesson number 6:
      For some reason 2.0 does not support md5 authentication between peers in BGP, it was giving me errors like "could not create pfkey" and PF_KEY not supported. Had to roll back to unauthenticated bgp sessions, but that is not a big deal as it all is on internal network.

      After two sleepless nights now everything is back as it was with added bonus of multiple subnets in single ipsec tunnel.

      wbr
      RR

      1 Reply Last reply Reply Quote 0
      • J
        jlepthien
        last edited by

        Well all I can say is that no one should be doing it the way you did…I as an admin ALWAYS test such scenarios before I'd do a remote update on a production environment...

        | apple fanboy | music lover | network and security specialist | in love with cisco systems |

        1 Reply Last reply Reply Quote 0
        • R
          raivisr
          last edited by

          @jlepthien:

          Well all I can say is that no one should be doing it the way you did…I as an admin ALWAYS test such scenarios before I'd do a remote update on a production environment...

          Me too. But living where I live and dealing with what I have to deal with I didn't have an option this time :)

          1 Reply Last reply Reply Quote 0
          • First post
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.