Hello list, The DynDNS logic seems to work in this wrong order:
1 Figure out the new public IP address for the interface 2 Send notifications to DynDNS targets (services_dyndns.php) 3 Change the interface database entry IP in firewall tables GRITTY DETAILS Please see http://doc.pfsense.org/index.php/Using_IPv6_on_2.1_with_a_Tunnel_Broker#Enable_ICMP Assuming a monitored interface 'WAN' with IP 1.2.3.4 Assuming a firewall rule 'only pass ICMP to WAN's address' Assuming a DynDNS entry of type 'HE.net Tunnelbroker' Assuming that 'WAN's IP now changes to 22.44.66.88 ...a notification is sent to the HE.net Tunnelbroker using the specified HTTP POST to ipv4.tunnelbroker.net/nic/update which immediately sends ICMP requests to the new IP 22.44.66.88. PFSense blocks these ICMP requests because they don't match the rule 'block all ICMP to WAN except 5.6.7.8' WHY ARE THESE VALID ICMP REQUESTS BLOCKED? Because PFSense has not yet updated the 'WAN' alias to the new IP 22.44.66.88 in the firewall tables. This happens a short time later, too late to satisfy Tunnelbroker's link inspection logic. And that's the bug that keeps Tunnelbroker from working for some. The proof is in the logs: 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. ...by the way, when clicking 'Save' or 'Save & Force Update' in the HE.net Tunnelbroker PHP interface 'services_dyndns_edit.php', the WAN IP is correctly changed in the firewall tables before notifying HE.net, so the procedure works correctly then. (SUCKY) WORKAROUND Just allow ICMP to any IP address in the firewall rules for WAN. Regards, Michael _______________________________________________ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
