Old WAN ip still in the state table
-
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. -
2.0-RC1 (i386)
built on Fri Mar 4 22:36:09 EST 2011Same 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).
-
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:SINGLEIn 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.
-
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#msg106801I 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.
-
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 -
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!
-
Try new snapshots and your issue might already be fixed.
-
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
-
@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
-
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?
-
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_ipInstead 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, 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. -
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 -
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 clearedvr1 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
-
Re reading this thread again made my question?
How does your sip use the old ip address?
-
@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).