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

    Old WAN ip still in the state table

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    20 Posts 7 Posters 6.4k 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.
    • E
      eri--
      last edited by

      Try new snapshots and your issue might already be fixed.

      1 Reply Last reply Reply Quote 0
      • H
        heper
        last edited by

        i have a problem that might be related but am not sure…..

        multiwan setup on failover

        for some reason it started sending traffic out on the tier 2 opt IF while the tier 1 wan is online ... this occured after wan received a new ip lease after electrical failure of multiple hours.

        going into the routing menu and saving the gateway solves the problem till one of the gateways goes offline for a brief moment and then the same thing happens again.

        i'm running one of the early RC1 snapshots btw

        1 Reply Last reply Reply Quote 0
        • A
          AndrewZ
          last edited by

          @ermal:

          Try new snapshots and your issue might already be fixed.

          I'm now on 2.0-RC2 (i386) built on Thu May 19 20:23:36 EDT 2011, will see how it will behave.
          With the previous version(s) it seems the issue was still there.

          Thanks

          1 Reply Last reply Reply Quote 0
          • A
            AndrewZ
            last edited by

            With 2.0-RC2 (i386) built on Fri May 20 12:55:52 EDT 2011  the problem was still there.

            If it will not be fixed - what is the best way to clean up the states using the script?

            1 Reply Last reply Reply Quote 0
            • P
              Perry
              last edited by

              If it will not be fixed - what is the best way to clean up the states using the script?

              To only kiil voip states IMO
              /sbin/pfctl -k $local_voip_ip -k $provider_voip_ip

              Instead of using afterfilterchangeshellcmd you can watch states with a cron job

              #!/bin/sh
              local_voip_ip=''
              provider_voip_ip=''
              # Write phone states to file
              /sbin/pfctl -s state | grep $local_voip_ip > /tmp/statetmp.status
              # Kill VOIP phone states if in wrong state
              awkrepley3=`awk '/'$local_voip_ip'/ && /'$provider_voip_ip'/ && /SINGLE/ {print "down"}' /tmp/statetmp.status`
                if [ "${awkrepley3}" = "down" ] ; then
                  /sbin/pfctl -k $local_voip_ip -k $provider_voip_ip
                  echo "states frozen kill them" | logger  
                fi
              

              /Perry
              doc.pfsense.org

              1 Reply Last reply Reply Quote 0
              • A
                AndrewZ
                last edited by

                Perry, thanks a lot!

                How can I use an alias instead of an IP address in local_voip_ip='' ? Is it safe to add a port number there?
                Is it OK to leave provider_voip_ip='' empty or it will be better to remove "-k $provider_voip_ip" completely?
                I cannot put all the provider's IPs there, and, actually, do not want to do so.

                1 Reply Last reply Reply Quote 0
                • P
                  Perry
                  last edited by

                  If it's not a single voip phone and local and remote ip's isn't static maybe you should just clear all states. Different ways to use pfctl can be found here.
                  http://www.freebsd.org/cgi/man.cgi?query=pfctl&apropos=0&sektion=8&manpath=FreeBSD+8.1-RELEASE&format=html

                  /Perry
                  doc.pfsense.org

                  1 Reply Last reply Reply Quote 0
                  • A
                    AndrewZ
                    last edited by

                    If it's not a single voip phone and local and remote ip's isn't static maybe you should just clear all states. Different ways to use pfctl can be found here.

                    I think I've started from such approach.

                    
                    [2.0-RC2][admin@gw.lan]/root(2): pfctl -F state -i vr1                                                                                                                       
                    0 states cleared
                    
                    

                    vr1 is my WAN and it seems that I cannot flush just this interface and have to flush all. Is it a known bug?

                    Going back to my earlier questions:

                    • what is better or safer: -b or -k or -F ?
                    • is it OK to use afterfilterchangeshellcmd? will it be called on every DHCP address change?

                    And how can I refer in my script to:

                    • the host alias I've defined, like 'pbx'
                    • ip address of the WAN interface (to use with -b)

                    Thanks

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

                      Re reading this thread again made my question?

                      How does your sip use the old ip address?

                      1 Reply Last reply Reply Quote 0
                      • A
                        AndrewZ
                        last edited by

                        @ermal:

                        How does your sip use the old ip address?

                        It doesn't. The stale state records are preventing client-to-server communication. Client keeps sending packets to server and get no response until the sates are cleared manually.
                        The problem is known for quite a long time, in 1.2.3 it was 'fixed' by installing fit123 package (similar to the cron-based solution your suggested earlier).

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