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

    Not all states are correctly cleared when WAN interface reconnects

    Scheduled Pinned Locked Moved
    2.1.1 Snapshot Feedback and Problems - RETIRED
    3
    4
    1.7k
    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.
    • K
      kswtch
      last edited by

      apinger ICMP states from other pfSense firewalls are not cleared when the WAN interface reconnects and gets a different IP address.

      How to reproduce:
      Install at least two pfSense firewalls. On one firewall configure a WAN interface with PPPOE that will get a different public IP address each time it connects. All other firewalls are connected via LAN to the PPPOE firewall. On all other firewalls configure the PPPOE firewall as a gateway for internet access with some external server IP as the monitor IP. (Different IP for each firewall). Reconnect the PPPOE interface by using the "reconnect" command on the interface page or wait for your provider to reconnect you. (In Germany this happens typically every 24 hours). The apinger state will not be cleared and the gateway will be marked "offline" for all other firewalls.

      Here is a detailed explanation:
      The topological setup looks like this:

      As mentioned above, Site A is configured with PPPOE and gets a different IP address each time the WAN interface reconnects. Sites B and C have Site A configured as a Gateway:

      In the screenshots above, the gateway is marked down because of the old states on pfSense Site A. Just for clarification: Site A had the IP address 79.228.171.193 until 05:00 CET when the provider forced a reconnect and it got the IP address 79.228.171.65.

      Here you can see the old states still active on Site A. Also note that only the apinger states are still there. All other states with the old public IP have been removed.

      The only solution to get the gateways on Site B and Site C up again is to restart apinger on Site B and C or to kill the old states. I chose to kill the states by clicking on the "X"-button next to the state entry. As soon as I do this new states are in the list with the correct Router IP:

      The gateway on Site B and C is up and running again.

      Expected Result:
      When the WAN interface on Site A gets a different IP address, all states containing the old IP should be removed from the table.

      Firmware on all pfSense firewalls is:
      2.1.1-PRERELEASE (i386)
      built on Sat Mar 1 22:10:21 EST 2014
      FreeBSD 8.3-RELEASE-p14

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

        To further narrow this down, it would be useful to also try having:
        A) a client in SiteA LAN doing a ping every 1 second and let it keep running. Does that ping stop being successful and stay being unsuccessful? Does the state for that also hang around in pfSenseA?
        B) another client in SiteA LAN doing a ping every 1 second and let it keep running, then stop it after the WAN address change, and start it again. I expect the old state on pfSenseA will time out and a new state will be started (because the new ping invocation will happen to use a different source port). (Hmmm - this is probably not so useful, the result should be obvious and not under suspicion)

        I suspect that no states are being cleared on WAN IP address change - it is just that other clients do things that give up after a while, the old state times out, an when the client program retries again (the user refreshes their "stuck" browser page…) a new state is established and away it goes.

        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
        • K
          kswtch
          last edited by

          Sorry for taking so long to come back to you.
          I tested the ping scenario you described in (A) with the following result:

          When the PPPOE connection is disconnected, the ping state still exists but the router part in the state has been removed. This looks like the expected behavior.  Because the gateway does not exist anymore, it does not show up in the state.

          Before disconnect:
          10.164.1.230:1 -> 79.228.141.210:17937 -> 173.194.112.248
          After disconnect:
          10.164.1.230:1 -> 173.194.112.248

          Unfortunately, when the PPPOE connection is reestablished the new Gateway is not inserted into the State leaving the ping dead.

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            This is an old issue that hopefully will get resolved on 2.2.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post