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

    All packages restart after a DHCP renew

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    10 Posts 7 Posters 3.3k 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.
    • dotOneD
      dotOne
      last edited by

      Last sunday I upgraded one of my firewalls to 2.1.3
      The upgrade went fine but now all packages are restarted after a DHCP renew.
      My provider has a maximum lease time of 2 hours thus all packages are started every hour as the DHCP client renews its IP address on the half of the maximum lease time.

      Strange thing is that a new default route is set but it's the same as the current one.
      The provides offers a fixed IP address and a fixed /48 IPv6 network.
      The other thing that is strange is that on IPv6 a changed link-local address is detected which isn't true.

      I'm running PPPoE and over this PPPoE connection both IPv4 snd IPv6 are running.
      IPv4 is getting a regular public IP and IPv6 is running DHCP-PD
      DHCPv6 is only requesting a prefix.
      There is an IPv6 alias on the interface which is used in HAproxy to hide some servers behind a single IPv6 and for IPv6 OpenVPN connections.

      May 7 08:02:55 snort[94075]: [1:2008578:6] ET SCAN Sipvicious Scan [Classification: Attempted Information Leak] [Priority: 2] {UDP} 173.242.117.182:5066 -> cccc.dddd.237.67:5060
      May 7 08:22:31 php: rc.newwanipv6: ROUTING: setting default route to 194.109.5.175
      May 7 08:22:31 check_reload_status: Reloading filter
      May 7 08:22:37 php: rc.newwanipv6: Forcefully reloading IPsec racoon daemon
      May 7 08:22:37 php: rc.newwanipv6: Resyncing OpenVPN instances for interface WAN.
      May 7 08:22:37 kernel: ovpns2: link state changed to DOWN
      May 7 08:22:37 check_reload_status: Reloading filter
      May 7 08:22:37 kernel: ovpns2: link state changed to UP
      May 7 08:22:37 check_reload_status: rc.newwanip starting ovpns2
      May 7 08:22:38 kernel: ovpns3: link state changed to DOWN
      May 7 08:22:38 php: rc.newwanipv6: Creating rrd update script
      May 7 08:22:38 kernel: ovpns3: link state changed to UP
      May 7 08:22:38 php: rc.newwanipv6: pfSense package system has detected an ip change -> fe80::230:18ff:fea5:3658%em0 … Restarting packages.
      May 7 08:22:38 check_reload_status: Starting packages
      May 7 08:22:38 check_reload_status: rc.newwanip starting ovpns3
      May 7 08:22:40 php: rc.newwanip: rc.newwanip: Informational is starting ovpns2.
      May 7 08:22:40 php: rc.newwanip: rc.newwanip: on (IP address: 10.0.8.1) (interface: []) (real interface: ovpns2).
      May 7 08:22:40 php: rc.newwanip: pfSense package system has detected an ip change -> 10.0.8.1 … Restarting packages.
      May 7 08:22:40 check_reload_status: Starting packages
      May 7 08:22:41 php: rc.newwanip: rc.newwanip: Informational is starting ovpns3.
      May 7 08:22:41 php: rc.newwanip: rc.newwanip: on (IP address: 10.0.18.1) (interface: []) (real interface: ovpns3).
      May 7 08:22:41 php: rc.newwanip: pfSense package system has detected an ip change -> 10.0.18.1 ... Restarting packages.
      May 7 08:22:41 php: rc.start_packages: Restarting/Starting all packages.
      May 7 07:22:46 php: rc.start_packages: No pfBlocker action during boot process.
      May 7 07:22:46 php: rc.start_packages: No pfBlocker action during boot process.
      ….
      ....

      And the interfaces

      ifconfig em0
      em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
              options=4219b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso>ether 00:30:18:a5:36:58
              inet6 fe80::230:18ff:fea5:3658%em0 prefixlen 64 scopeid 0x1
              nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
              status: active

      ifconfig pppoe0
      pppoe0: flags=89d1 <up,pointopoint,running,noarp,promisc,simplex,multicast>metric 0 mtu 1492
              inet6 fe80::230:18ff:fea5:3658%pppoe0 prefixlen 64 scopeid 0xb
              inet6 aaaa:bbbb:93ab:0:cccc:dddd:237:67 prefixlen 128
              inet6 fe80::290:bff:fe32:5b2f%pppoe0 prefixlen 64 scopeid 0xb
              inet 212.238.237.67 –> 194.109.5.175 netmask 0xffffffff
              nd6 options=3<performnud,accept_rtadv></performnud,accept_rtadv></up,pointopoint,running,noarp,promisc,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso></up,broadcast,running,simplex,multicast>

      Andre

      1 Reply Last reply Reply Quote 0
      • dotOneD
        dotOne
        last edited by

        When taking a closer look it seems that the old IP address is not known.
        This is strange since the link is working and the WAN (PPPoE) interface has its IP addresses.
        To prevent all packages from restarting I commented out the call to restart the packages in rc.newwanip and rc.newwanipv6
        For now this can be safely done since my provider hands out static addresses, but I want to get it solved.

        May 7 08:22:38    php: rc.newwanipv6: pfSense package system has detected an ip change missing ip address ->  fe80::290:bff:fe32:5b2e%em0 … Restarting packages.
        May 7 08:22:38    check_reload_status: Starting packages

        May 7 08:22:40 php: rc.newwanip: rc.newwanip: Informational is starting ovpns2.
        May 7 08:22:40 php: rc.newwanip: rc.newwanip: on (IP address: 10.0.8.1) (interface: []) (real interface: ovpns2).
        May 7 08:22:40 php: rc.newwanip: pfSense package system has detected an ip change missing ip address -> 10.0.8.1 … Restarting packages.

        ifconfig em0
        em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                options=4219b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso>ether 00:30:18:a5:36:58
                inet6 fe80::230:18ff:fea5:3658%em0 prefixlen 64 scopeid 0x1
                nd6 options=3 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
                status: active

        ifconfig pppoe0
        pppoe0: flags=89d1 <up,pointopoint,running,noarp,promisc,simplex,multicast>metric 0 mtu 1492
              inet6 fe80::290:bff:fe32:5b2f%pppoe0 prefixlen 64 scopeid 0xb
                inet ccc.ddd.237.67 –> 194.109.5.175 netmask 0xffffffff
                inet6 aaaa:bbbb:93ab:0:cccc:dddd:237:67 prefixlen 128              <– IPv6 alias address
                nd6 options=3 <performnud,accept_rtadv></performnud,accept_rtadv></up,pointopoint,running,noarp,promisc,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,tso4,wol_magic,vlan_hwtso></up,broadcast,running,simplex,multicast>

        Also in the VPN interfaces the ' old'  IP address is unknown. This is even stranger as these are static addresses

        1 Reply Last reply Reply Quote 0
        • P
          phil.davis
          last edited by

          I am guessing that this behavior is due to the variable typo in /etc/rc.newwanip
          It was corrected after 2.1.3-release by https://github.com/pfsense/pfsense/commit/38f6f50a84e78eddbe4d639914422789ad0057d5
          Maybe fixing that will be of some help?

          As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
          If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

          1 Reply Last reply Reply Quote 0
          • dotOneD
            dotOne
            last edited by

            Changed it by hand.
            Let's wait a few days and see if it stabilizes.

            Thnx.

            1 Reply Last reply Reply Quote 0
            • B
              beckerwilliams
              last edited by

              I've been having increasing disconnects and lots of WAN IP switching to 192.168.100.x errors. I corrected /etc/rc.newwanip by hand - which reduced the number of 'all services restarting' errors, but continued to see increasing WAN IP changes between my provider and that provided by my SB 6141 cable modem.

              After experiencing the issues above, many WAN disconnects, loss of Cable Provider DHCP, seeing error logs in my cable modem - and having my family yell at me about keeping our Internet up, and after reading various forums, I was going to make my WAN IP static - based on the pretty consistent address I get - Before I did so I noticed I had put what I thought was the WAN MAC into the 'MAC' form in the WAN Interface. Before I tried the static, I eliminated the unneeded MAC address from 'Interfaces->WAN' in the UI.

              The address switching between my cable modem's default range and my cable provider has stopped. CPU utilization has fallen. And in general everything feels smoother.

              BOTTOM LINE: Don't configure a MAC address in the interface unless you have a clear reason to do so. I suspect it was an incorrect mac, perhaps entered accidentally by clicking 'Insert My MAC Address,' which uses the MAC of the machine you're logged into the interface with, rather than your pfsense's box.

              1 Reply Last reply Reply Quote 0
              • C
                Cino
                last edited by

                @phil.davis:

                I am guessing that this behavior is due to the variable typo in /etc/rc.newwanip
                It was corrected after 2.1.3-release by https://github.com/pfsense/pfsense/commit/38f6f50a84e78eddbe4d639914422789ad0057d5
                Maybe fixing that will be of some help?

                It hasn't helped me for the last week.. I ended up commenting out the package restart function also. My WAN V4/V6 are both dynamic but unless my cable modem is offline for a week, I always renew to the same IPs.. Too bad there isn't an option to turn it on and off under the Advance-Miscellaneous menu..

                1 Reply Last reply Reply Quote 0
                • dotOneD
                  dotOne
                  last edited by

                  The same for me, removing the type didn't help at all.
                  So commenting out the the restart in the /etc/rc.newwanip and /etc/rc.newwanip6 is the way to go for now.

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

                    This is still happening in 2.1.5-RELEASE (amd64), btw. Commenting out the restart package command for now (edit: I'm only commenting that out in rc.newwanipv6). Can post logs if anyone's interested.

                    Edit2: Oh, done rc.newwanip now too.

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

                      this has been discussed many times if you do a search for newwanip

                      Apparently some packages require the restart before they can work with new IP ( kind of sucks … would be nice to just "notify" the packages or whatever instead of "restart" so thats why it's there, even tho it can completely screw you over if you are running openvpn with OSPF for example with crappy secondary "backup" links that are restarting constantly.

                      1 Reply Last reply Reply Quote 0
                      • D
                        dugeem
                        last edited by

                        Check out the bug report in https://redmine.pfsense.org/issues/3669

                        Note that there are 2 parts to the restarting fix:

                        First part relates to IPv4 script /etc/rc.newwanip - this fix is rolled into 2.1.4 and later.
                        Second part relates to IPv6 script /etc/rc.newwanipv6 - appears to be awaiting review (despite ticket being marked Resolved). Also impacts 2.2 release

                        In the meantime it is easy to manually apply the fix and stop the restarts.

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