Dynamic WAN address not updating on tunnelbroker for a configured IPv6 tunnel
-
…. lost my pppoe WAN IP.
The modified rc.newwanip got executed.But, no way, neither my "RFC 2136 DNS", neither "'he-net-tunnelbroker'" got updated.
The first: the curl never made it to my site.
The latter:2014-06-23 14:03:27 User.Error 192.168.1.1 Jun 23 14:03:34 php: rc.newwanip: DynDNS (245809): DynDns _checkStatus() starting.
2014-06-23 14:03:27 User.Error 192.168.1.1 Jun 23 14:03:34 php: rc.newwanip: DynDNS (245809): Current Service: he-net-tunnelbroker
2014-06-23 14:03:27 User.Error 192.168.1.1 Jun 23 14:03:34 php: rc.newwanip: phpDynDNS: PAYLOAD: -ERROR: IP is not ICMP pingable. Please make sure ICMP is not blocked. If you are blocking ICMP, please allow 66.220.2.74 through your firewall.
2014-06-23 14:03:27 User.Error 192.168.1.1 Jun 23 14:03:34 php: rc.newwanip: phpDynDNS: (Unknown Response)
2014-06-23 14:03:28 User.Notice 192.168.1.1 Jun 23 14:03:35 check_reload_status: Reloading filterInteresting:
The last line:2014-06-23 14:03:28 User.Notice 192.168.1.1 Jun 23 14:03:35 check_reload_status: Reloading filtercame in just to late ??
I'll:
filter_configure(); /* perform RFC 2136 DNS update */ services_dnsupdate_process($interface); /* signal dyndns update */ services_dyndns_configure($interface); } else /* signal filter reload */ filter_configure(); ?> -
Putting
filter_configure();
above DynDNS handling was being proposed before https://forum.pfsense.org/index.php?topic=72862.0
-
Seem to have the same or similar issue with a HE tunnel broker link.
Has there been a consensus established on how to fix this properly?Things used to work just fine until I installed 2.1.4, and now nada on the IPv6 tunnel front.
-
Things used to work just fine until I installed 2.1.4, and now nada on the IPv6 tunnel front.
The code involved when updating DynDNS and "RFC2136 DNS" didn't change the last versions.
The same behavior could show up before.Its more some race condition: for example, to validate upon "he-net-tunnelbroker" our IP-WAN has to reply on pings.
It doesn't when "DynDNS" runs (again: "he-net-tunnelbroker") and a couple of lines ahead in the 'rc.newwanip' scripts a "filter_configure();" rebuilds the firewall rules with our new IP-WAN. Then, our IP-WAN replies to ICMP (needed for "he-net-tunnelbroker" to validate our IP-WAN).I guess for the same reason my "RFC2136 DNS" just doesn't finds its way out tp my 'bind9' server neither.
My logs on my "bind9 linux server" do not show any traces of the curl call.Try my patch.
-
Just to add another datapoint: I had the same problem and the patch helped. Does not seem to have adverse side effects.
-
Thanks for the feed back.
Using the patch myself, for the last 3 weeks I had several IP Wan renews, and no issues what so ever.
Both my "RFC2136 DNS" and DynDNS got updated fine now. -
I can confirm this behavior. When my WAN connection drops, 2(!) other DynDNS services are updated reliably, only the HE Tunnel Dyn DNS is NOT updated. Reproducable (every morning).
After reboot: All DynDNS are correctly updated
After WAN drop: All DynDNS except HE are updated
After manual update of HE: Everything up and running again.Is there a way to trigger the update via cron, as a workaround?
-
I can confirm this behavior. When my WAN connection drops, 2(!) other DynDNS services are updated reliably, only the HE Tunnel Dyn DNS is NOT updated. Reproducable (every morning).
Apply my patch proposed above - and check again.
After reboot: All DynDNS are correctly updated
Same thing for me - this always worked … as advertised ;)
@dkrizic:After WAN drop: All DynDNS except HE are updated
I just tested that !
Ripped out the ADSL phone cable out of the wall.
Put it back in 30 seconds later.
Connection came back - my DynDNS (HE Tunnelbroker) and RFC (private server with 'DNS bind') was synchronised well - two mails from my pfSEnse box confirmed this.After manual update of HE: Everything up and running again.
This is & was working for me - that's what I used to force the updates.
Is there a way to trigger the update via cron, as a workaround?
Login by SSH in your pfSEnse box.
Take the option 8), the Shell access.Type
viconfig
(be carefull, you are using vi here :) )<pfsense><version>10.1</version> <lastchange><theme>pfsense_ng</theme> <system><developerspew>1</developerspew></system></lastchange></pfsense>ADD the line
<developerspew>1</developerspew>Save
(that is
ESCAPE:wq
==> 4 key strokes)If your pfSEnse box can send mails to you, you will receive a mail around midnight.
The one that send the mail is the DYNDNS cron task ;)Anyway, my path works for me:
The end of /etc/ rc.newwanip look like this:/* reload igmpproxy */ services_igmpproxy_configure(); /* restart snmp */ services_snmpd_configure(); restart_packages(); filter_configure(); sleep(5); log_error("rc.newwanip: Go for DynDNS ..."); /* perform RFC 2136 DNS update */ services_dnsupdate_process($interface); /* signal dyndns update */ services_dyndns_configure($interface); } else /* signal filter reload */ filter_configure(); ?>Save.
Now you can forget about this issue :)
-
Hi,
don't worry about the vi, it is my favorite editor. I patched /etc/rc.newwanip as you suggest:
194,199d193 < /* perform RFC 2136 DNS update */ < services_dnsupdate_process($interface); < < /* signal dyndns update */ < services_dyndns_configure($interface); < 216a211,220 > > filter_configure(); > > sleep(5); > > /* perform RFC 2136 DNS update */ > services_dnsupdate_process($interface); > > /* signal dyndns update */ > services_dyndns_configure($interface);I will test it.
I test it with another problem I have: After WAN drop, the Squid Reverse Proxy does not listen on the WAN interface anymore. The generated file
/usr/pbi/squid-i386/etc/squid/squid.conf
contains the WAN IP and needs to be updated after a WAN drop. I found a workaround by not listening on WAN anymore and forward WAN -> Localhost with NAT rules. But this is another topic.
Thanks, I will keep you updated.
-
Just to keep you updated… It works, today morning IPv6 was up and running, but there is one thing strange: The "Dynamic DNS" panel shows the wrong (old) IP in red. But I just saw, that there were some fixes for the upcoming 2.2, so I am relaxed.
