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.
    • A
      AndrewZ
      last edited by

      Too bad… This issue was fixed in 1.2.3 by the additional package (fit123), but for some reasons it still present in 2.0 !
      I'm running the latest snapshot - 2.0-RC1 (i386) built on Sun Mar 6 03:41:16 EST 2011

      Single WAN is configured for PPPoE, my WAN IP address just changed but I still see the old one (91.79.X.X) in the table:

      
udp 	192.168.5.77:5060 -> 91.79.X.X:5060 -> 213.85.Y.Y:5060 	SINGLE:NO_TRAFFIC 	
udp 	192.168.5.77:5060 -> 91.79.X.X:5060 -> 212.53.Z.Z:5060 	SINGLE:NO_TRAFFIC 	
udp 	192.168.5.210:123 -> 91.79.X.X:24304 -> 213.141.Q.Q:123 	SINGLE:NO_TRAFFIC

      As a result my SIP client cannot register to external servers. I had to manually remove those entries from the table.

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

        Please provide system logs.
        Also check under advanced if you have disabled clearing the state for down gateways.

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

          I have just upgraded to 2.0-RC1 myself and am also seeing this issue. I have seen it twice in the last two days, states with the old IP. When I look at the gateway for information about any downtime it shows there was none when the IP changed. I need to then manually clear the states to get my voip server to reconnect.

          I have not disabled clearing the states for a down gateway. Although since the gateway actually never showed that there was any downtime I don't think it would have mattered.

          Is there a quick hack/fix that can be done to get by at this time? SOmething from the previous Fit123 package or something?

          Also, where and what logs would need to be collected to help resolve this issue?

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

            Advanced setting is correct.

            I've observed successful address change a few minutes ago, with no stale records in the state table.
            GW was marked as "down". I've updated my system to the last snapshot since mt previous post, not sure this is a reason though.

            
Mar 8 23:04:36 	apinger: Starting Alarm Pinger, apinger(51060)
Mar 8 20:04:36 	check_reload_status: reloading filter
Mar 8 20:04:35 	check_reload_status: reloading filter
Mar 8 23:04:35 	apinger: Exiting on signal 15.
Mar 8 23:04:34 	php: : ROUTING: change default route to 91.X.X.1
Mar 8 23:04:33 	apinger: ALARM: GW_WAN(91.X.X.1) *** down ***

            I will keep watching and will simulate address changes manually, but later…

            As a side note - time in the log is incorrect for some of the records, I think it was already mentioned by other members.

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

              @Babblephish:

              Is there a quick hack/fix that can be done to get by at this time? SOmething from the previous Fit123 package or something?

              From my perspective the fix could be very simple.
              So far we have no issues with DynDNS, right? Every time the WAN IP changes router sends an update to the external DynDNS server. If there is no change - there is no update. Right?
              In order to cleanup the stale records we just need to flush the table from the same DynDNS script, before or after sending DynDNS update.

              1 Reply Last reply Reply Quote 0
              • V
                vinsomething
                last edited by

                2.0-RC1 (i386)
                built on Fri Mar 4 22:36:09 EST 2011

                Same problem here.  Repair guy was out and re-routed some cables for my new TV.  Caused the cable modem to drop for a few minutes.  pfSense detected the Gateway go down.  States remained.  Didn't realize it until I tried to make a VoIP call a while later and I had one-way audio.  Had to manually clear states to resolve.

                System:Advanced:Misc:Gateway Monitoring is unchecked.

                In my case my IP remained the same (in case that matters).

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

                  I also hit the same problem.  Simple setup: One WAN (NATed), one LAN.  Cable modem connected to the WAN.

                  The problem occured when the modem started to give IP addresses.  The WAN interface temporarly received an IP of 192.168.100.11.  Few hours later, the WAN got an IP from my ISP.  But states were not cleared correctly:

                  udp 67.205.74.164:5060 <- 192.168.15.25:5060 MULTIPLE:MULTIPLE 
                  udp 192.168.15.25:5060 -> 192.168.100.11:34308 -> 67.205.74.164:5060 SINGLE:NO_TRAFFIC 
                  udp 192.168.15.255:17500 <- 192.168.15.21:17500 NO_TRAFFIC:SINGLE

                  In my case, because of those bad states, my phone adaptaper was not able to register to my SIP provider.  I cleared those states to fix the problem.

                  System:Advanced:Misc:Gateway Monitoring is unchecked.

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

                    OK, I knew I remembered a shell script from a year or so ago to help solve this issue. I just added it to my RC1 system and forced an IP change with success.

                    Here is the old posting.
                    http://forum.pfsense.org/index.php/topic,18053.msg106801.html#msg106801

                    I modified the script myself to simply remove all the states for my voip server with no regard for destination since I have several and the IPs can change from the provider.

                    I also installed the cron package to add the script.

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

                      Same problem again - old ip is in the table with SINGLE:NO_TRAFFIC

                      From the log:

                      
Mar 18 18:24:15 	php: : phpDynDNS: (Success) IP Address Changed Successfully! (x.x.35.132)
Mar 18 18:24:15 	php: : phpDynDNS: updating cache file /conf/dyndns_wandyndns'xxxxx.homedns.org'.cache: x.x.35.132
Mar 18 18:24:15 	php: : DynDns debug information: x.x.35.132 extracted from local system.
Mar 18 18:24:15 	php: : DynDns: _checkIP() starting.
Mar 18 18:24:15 	php: : DynDns: Current Service: dyndns
Mar 18 18:24:15 	php: : DynDns: DynDns _checkStatus() starting.
Mar 18 18:24:14 	php: : Gateways status could not be determined, considering all as up/active.
Mar 18 18:24:12 	php: : Gateways status could not be determined, considering all as up/active.
Mar 18 18:24:11 	php: : DynDns: DynDns _update() starting.
Mar 18 18:24:11 	php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: x.x.38.167 WAN IP: x.x.35.132
Mar 18 18:24:11 	php: : DynDns: Cached IP: x.x.38.167
Mar 18 18:24:11 	php: : DynDns: Current WAN IP: x.x.35.132
Mar 18 18:24:11 	php: : DynDns debug information: x.x.35.132 extracted from local system.
Mar 18 18:24:11 	php: : DynDns: _checkIP() starting.
Mar 18 18:24:11 	php: : DynDns: _detectChange() starting.
Mar 18 18:24:11 	php: : DynDns: updatedns() starting
Mar 18 18:24:11 	php: : DynDns: Running updatedns()
Mar 18 18:24:11 	apinger: Starting Alarm Pinger, apinger(26077)
Mar 18 15:24:11 	check_reload_status: reloading filter
Mar 18 15:24:10 	check_reload_status: reloading filter
Mar 18 18:24:10 	apinger: Exiting on signal 15.
Mar 18 18:24:09 	php: : ROUTING: change default route to x.x.32.1
Mar 18 15:24:06 	check_reload_status: Rewriting resolv.conf
Mar 18 18:24:06 	apinger: ALARM: GW_WAN(x.x.32.1) *** down ***
Mar 18 18:24:04 	dnsmasq[60480]: no servers found in /etc/resolv.conf, will retry
Mar 18 18:24:04 	dnsmasq[60480]: no servers found in /etc/resolv.conf, will retry
Mar 18 15:23:56 	check_reload_status: Rewriting resolv.conf
                      1 Reply Last reply Reply Quote 0
                      • A
                        AndrewZ
                        last edited by

                        I recently switched from PPP to DHCP on WAN and have the same issue with the stale records.
                        After reading some old posts I noticed that a few workarounds were suggested earlier, all of them use pfctl and run 'by event' or as a cron job.

                        My question is - what will be better or safer way to cleanup the states?
                        pfctl -b {WAN ip}
                        pfctl -k {voip host ip}
                        pfctl -F state -i {WAN interface name}  (interface name seems to be ignored?)
                        or ???

                        Is it OK to call this command from the script defined like this:

                        
 <system><afterfilterchangeshellcmd>/usr/local/bin/reset_states.sh</afterfilterchangeshellcmd></system>

                        Will it be called on DHCP address change?

                        Thanks!

                        1 Reply Last reply Reply Quote 0
                        • 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.