Dynamic WAN address not updating on tunnelbroker for a configured IPv6 tunnel
-
Yes.
Same situation - same result - so I decided to weak up this thread instead of creating another one.
Details: as above, and more.
It starts with my pppoe connection that times out - my ISP closes the connection softly after one week exactly.
This is handled ok.tc.newwanip is called to do his work.
This is the end of 'ppp' getting all the IP, DNS, etc.
It just works great..... 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] SECDNS 0.0.0.0 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan_link0] LCP: rec'd Protocol Reject #211 (Opened) 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan_link0] LCP: protocol IPV6CP was rejected 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPV6CP: protocol was rejected by peer 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPV6CP: state change Req-Sent --> Stopped 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPV6CP: LayerFinish 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPCP: rec'd Configure Nak #11 (Ack-Sent) 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPADDR 90.45.8.77 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] 90.45.8.77 is OK 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] PRIDNS 81.253.149.2 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] SECDNS 80.10.246.132 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPCP: SendConfigReq #12 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPADDR 90.45.8.77 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] PRIDNS 81.253.149.2 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] SECDNS 80.10.246.132 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPCP: rec'd Configure Ack #12 (Ack-Sent) 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPADDR 90.45.8.77 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] PRIDNS 81.253.149.2 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] SECDNS 80.10.246.132 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPCP: state change Ack-Sent --> Opened 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] IPCP: LayerUp 2014-06-20 16:12:33 Daemon.Info 192.168.1.1 Jun 20 16:12:36 ppp: [wan] 90.45.8.77 -> 193.253.160.3DHCP, dnsmasqetc kick in:
Note that several dnsmasq logs just get thrown away - it spams ;)
My external DNS servers from my ISP (the IPv4 ones) are set up ok.2014-06-20 16:12:33 User.Notice 192.168.1.1 Jun 20 16:12:36 check_reload_status: Rewriting resolv.conf 2014-06-20 16:12:34 User.Notice 192.168.1.1 Jun 20 16:12:37 check_reload_status: rc.newwanip starting pppoe0 2014-06-20 16:12:34 Daemon.Info 192.168.1.1 Jun 20 16:12:37 ppp: [wan] IFACE: Up event 2014-06-20 16:12:34 Daemon.Info 192.168.1.1 Jun 20 16:12:37 ppp: [wan] IFACE: Rename interface ng0 to pppoe0 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:39 php: rc.newwanip: rc.newwanip: Informational is starting pppoe0. 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:39 php: rc.newwanip: rc.newwanip: on (IP address: 90.45.8.77) (interface: WAN[wan]) (real interface: pppoe0). 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:39 php: rc.newwanip: ROUTING: setting IPv6 default route to 2001:470:1f12:5c0::1 2014-06-20 16:12:36 User.Info 192.168.1.1 Jun 20 16:12:39 dhcpleases: Sending HUP signal to dns daemon(99921) 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: reading /etc/resolv.conf 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using nameserver 2001:470:20::2#53 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using nameserver 80.10.246.132#53 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using nameserver 81.253.149.2#53 2014-06-20 16:12:36 Daemon.Warning 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: ignoring nameserver 127.0.0.1 - local interface 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 31.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 30.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 29.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 28.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 27.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 26.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 25.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 24.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 23.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 22.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 21.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 20.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 19.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 18.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Info 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: using local addresses only for domain 17.172.in-addr.arpa 2014-06-20 16:12:36 Daemon.Warning 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: overflow: 2 log entries lost 2014-06-20 16:12:36 Daemon.Warning 192.168.1.1 Jun 20 16:12:39 dnsmasq[99921]: overflow: 2 log entries lostMy IPv6 (static - it my tunnel side) is set up.
Note that apinger gets SIGHUPed and
that is complains at the end of this part of the log: no more (IPv6) tunnel. Ok, that normal.
Note also: My other DynDNS - a "rfc2136 BIND DNS" starts its update - No detailed logs because part of the DynDNS settings page hasn't a "VerboseLog" option - the DynDNS HE.net Tunnelbroker updater has this option - and its set.
So, the job is done, the mail is send (to me - note: I received that mail !).
BUT: my debug logs on my DNS serveur (a Debian server with bind9) never receives this 'rfc2136' update:20-Jun-2014 17:12:12.162 update: client 2001:470:1f12:5c0::2#1295: updating zone 'brit.test-domaine.fr/IN': deleting rrset $ 20-Jun-2014 17:12:12.179 update: client 2001:470:1f12:5c0::2#1295: updating zone 'brit.test-domaine.fr/IN': adding an RR at$ 20-Jun-2014 17:12:12.240 update: client 2001:470:1f12:5c0::2#14669: updating zone 'brit.test-domaine.fr/IN': deleting rrset$ 20-Jun-2014 17:12:12.240 update: client 2001:470:1f12:5c0::2#14669: updating zone 'brit.test-domaine.fr/IN': adding an RR a$ 20-Jun-2014 17:12:12.241 notify: zone brit.test-domaine.fr/IN: sending notifies (serial 2014012372)This is ME manually updating one hour (17:12 !!) afterwards. Again: these 4 lines is a fragment of the bind9 DNS server - running on my Linux server on the net.
Back to the pfSense logs:
The "HE.net Tunnelbroker" get handled - and is detailed:2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:39 php: rc.newwanip: ROUTING: setting IPv6 default route to 2001:470:1f12:5c0::1 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:40 php: rc.newwanip: ROUTING: setting IPv6 default route to 2001:470:1f12:5c0::1 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:40 php: rc.newwanip: ROUTING: setting IPv6 default route to 2001:470:1f12:5c0::1 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:40 php: rc.newwanip: ROUTING: setting default route to 193.253.160.3 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:40 apinger: SIGHUP received, reloading configuration. 2014-06-20 16:12:36 User.Error 192.168.1.1 Jun 20 16:12:40 php: rc.newwanip: phpDynDNS: updating cache file /conf/dyndns_wan_rfc2136_'brit.test-domaine.fr'_ns.test-domaine.fr.cache: 90.45.8.77 2014-06-20 16:12:37 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: Message sent to gertjan@kroeb.me OK 2014-06-20 16:12:37 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDns: updatedns() starting 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDns (245809): 90.45.8.77 extracted from local system. 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDNS (245809): running get_failover_interface for wan. found pppoe0 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDns (245809): 90.45.8.77 extracted from local system. 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDns (245809): Current WAN IP: 90.45.8.77 Cached IP: 86.221.4.132 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDns (245809): DynDns: cacheIP != wan_ip. Updating. Cached IP: 86.221.4.132 WAN IP: 90.45.8.77 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: DynDNS (245809): DynDns _update() starting. 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 php: rc.newwanip: HE.net Tunnelbroker: DNS update() starting. 2014-06-20 16:12:38 User.Error 192.168.1.1 Jun 20 16:12:41 apinger: ALARM: TUNNELGWv6(2001:470:1f12:5c0::1) *** down ***First, some more fragments from "check_reload_status"
And the "DynDNS " that continues …. and received a "non-documented error", but very essential to "HE.net Tunnelbroker" : "HE.net Tunnelbroker" CAN NOT ping me back, and this is needed if they want to accept my NEW IP.
Note: this "error should be add in /etc/inc/dyndns.class for the "'he-net-tunnelbroker'" case.
But, happily enough, the error (PAYLOAD) is shown: "I can't ping your IP - You don't reply to ICMP".
=> Note : I do have a pass rule on WAN interface that enabled ICMP (IPv4) on "WAN address ".
An we see the end of the script /etc/rc.newwanip.2014-06-20 16:12:48 User.Notice 192.168.1.1 Jun 20 16:12:51 check_reload_status: updating dyndns TUNNELGWv6 2014-06-20 16:12:48 User.Notice 192.168.1.1 Jun 20 16:12:51 check_reload_status: Restarting ipsec tunnels 2014-06-20 16:12:48 User.Notice 192.168.1.1 Jun 20 16:12:51 check_reload_status: Restarting OpenVPN tunnels/interfaces 2014-06-20 16:12:48 User.Notice 192.168.1.1 Jun 20 16:12:51 check_reload_status: Reloading filter 2014-06-20 16:12:51 User.Error 192.168.1.1 Jun 20 16:12:54 php: rc.dyndns.update: phpDynDNS: Not updating brit.test-domaine.fr AAAA record because the IPv6 address has not changed. 2014-06-20 16:12:51 User.Error 192.168.1.1 Jun 20 16:12:54 php: rc.newwanip: DynDNS (245809): DynDns _checkStatus() starting. 2014-06-20 16:12:51 User.Error 192.168.1.1 Jun 20 16:12:54 php: rc.newwanip: DynDNS (245809): Current Service: he-net-tunnelbroker 2014-06-20 16:12:51 User.Error 192.168.1.1 Jun 20 16:12:54 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-20 16:12:51 User.Error 192.168.1.1 Jun 20 16:12:54 php: rc.newwanip: phpDynDNS: (Unknown Response) 2014-06-20 16:12:51 User.Error 192.168.1.1 Jun 20 16:12:54 php: rc.filter_configure_sync: Could not find IPv6 gateway for interface(wan). 2014-06-20 16:12:57 User.Error 192.168.1.1 Jun 20 16:13:00 php: rc.newwanip: Resyncing OpenVPN instances for interface WAN. 2014-06-20 16:12:57 User.Error 192.168.1.1 Jun 20 16:13:00 php: rc.newwanip: Creating rrd update script 2014-06-20 16:12:59 User.Error 192.168.1.1 Jun 20 16:13:02 php: rc.newwanip: pfSense package system has detected an ip change 109.214.189.183 -> 90.45.8.77 ... Restarting packages. 2014-06-20 16:12:59 User.Notice 192.168.1.1 Jun 20 16:13:02 check_reload_status: Starting packagesI guess the WAN IP (IPv4) is up, but routes, rules or whatever aren't stabilized yet, my WAN firewall rule to accept (and reply) ICMP on my WAN IP isn't activated yet.
https://ipv4.tunnelbroker.net/ipv4_end.php ("'he-net-tunnelbroker'") tries to ping me back, it won't receive a reply and flags the error.Note the difference with my DynDNS rfc2136 just a second or so before: the curl_exec() won't even make it to MY Linux server on the net (bind9 - If it did,I should have the traces in the bind9-debug log).
I decided to put on some "sleep(10) on strategics places to see what happens next time.
edit: this didn't work. A more sophisticated system is needed.
I'll try to re-order rc.newwanip.Of course, simply "editing" my two DynDNS entries (without modifying anything) - simply "Safe a Force Update" will do the job just fine (logs and functionality prove it)
edit: several posts on the forum(like this one https://forum.pfsense.org/index.php?topic=38296.msg197621#msg197621 ) tell me that jimp knows all about DynDNS, HE-tunnelbroker and IPv6 :)
-
I'll try to re-order rc.newwanip.
Re ordered rc.newwanip, so that DynSNS stuff gets executed after restart_packages();
This works much better:
diff rc.newwanip rc.newwanip.org 194,199d193 < /* perform RFC 2136 DNS update */ < services_dnsupdate_process($interface); < < /* signal dyndns update */ < services_dyndns_configure($interface); < 216c210,216 < restart_packages(); --- > restart_packages(); > > /* perform RFC 2136 DNS update */ > services_dnsupdate_process($interface); > > /* signal dyndns update */ > services_dyndns_configure($interface);Both the he-tunnelbroker and my DNS server were updated correctly now.
The question is: are there any side effects ?
Note: I have only one package installed: NUT (2.6.5_1 pkg 2.0.2) for UPS management.
Nothing else.Also: this is NOT an IPv6 related issue - this thread should be moved elsewhere.
-
…. 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.
