Network configuration blocking 8.8.8.8, while keeping SolarEdge inverter monitoring functional.

Summary

Problem

During the summer holiday two out three of my SolarEdge inverters stopped showing production data in the SolarEdge monitoring environment.

Root cause

The root cause turned out to be the inverter started to exclusively use 8.8.8.8 -which I have blocked on my network- as DNS server even when DHCP provides an alternative DNS server.

Solution

Redirect DNS & ICMP traffic targeting 8.8.8.8 to my local DNS server / router.

Details

Problem

Looking at the logs from my pfSense router and posts by others, it became clear the inverter was exclusively using 8.8.8.8 as DNS server, even when DHCP provides an alternative DNS server (my local DNS resolver). As I have blocked public DNS servers at the IP level the SolarEdge inverters could no longer resolve domain names, and hence the inverters effectively stopped uploading production data to the SolarEdge monitoring environment.

This behavior disrupts several critical network management practices:

1. Privacy: Many users prefer not to rely on Google DNS for all device traffic. For example, discussions on the following forums highlight the widespread desire to avoid dependency on external DNS providers:
   • https://www.reddit.com/r/PFSENSE/comments/milgjm/prevent_hardcoded_dns_on_google_wifi/
   • https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server
   • https://gathering.tweakers.net/forum/list_messages/2117968?data%5Bfilter_keywords%5D=8.8.8.8
2. Security: Local DNS solutions (e.g., Pi-hole, pfBlocker-NG, or DNS4EU) are essential for blocking malware, ads, and trackers. Hardcoding 8.8.8.8 undermines these protections.
3. Reliability: If 8.8.8.8 is blocked or redirected (e.g., for logging or filtering), the inverter fails to connect to SolarEdge’s monitoring servers, leading to data loss and operational disruptions.

Mitigation

To mitigate this issue, I implemented a pfSense Port Forward rule with the following settings:

• Protocol: ANY (to capture both DNS and ICMP traffic to 8.8.8.8). (The LLM assistant I was using insisted that redirecting ICMP traffic wasn’t possible—but it is! 😊 A good reminder not to blindly trust LLM output.)
• Destination: 8.8.8.8.
• Redirect Target IP: 192.168.1.1 (my local DNS server).

Verification:

• Running nslookup logs.netflix.com 8.8.8.8 returns 10.10.10.1 (the pfBlocker-NG virtual IP address), confirming that DNS requests are being redirected and filtered locally.
• Disconnecting the WAN cable and pinging 8.8.8.8 still replies from 192.168.1.1, proving that ICMP traffic is also redirected to my router.
• The blue LED lit up, and monitoring data resumed flowing to SolarEdge’s servers.

Limitations and future work

• This workaround is fragile because it relies on the inverter using unencrypted DNS on port 53. If SolarEdge transitions to DNS over TLS (DoT, port 853) or DNS over HTTPS (DoH, port 443), this solution will almost certainly fail.
• The forward could be set more fine-grained forwarding DNS and ICMP traffic only, clarifying that other traffic to 8.8.8.8 remains blocked.
• I contacted SolarEdge, explained the problem and requested the following improvements:
  • Respect DHCP DNS settings Allow the inverter to use the DNS server provided via DHCP, as is standard for modern networked devices.
  • Transparency on DNS usage Document which DNS servers the inverter uses and under what conditions.
  • Future-proofing for DOT/DOH If SolarEdge adopts DNS over TLS (DoT) or DNS over HTTPS (DoH), ensure users can specify their own DoT/DoH servers.
• While SolarEdge did reply (offering to downgrade the firmware version on my inverters to mitigate the problem) SolarEdge did not acknowledge my requests. I’ll stick to my containment for now. If you suffer from the same issue then use this knowledge to your advantage.