PfSense 2.0 client PC reporting internal IP to internet domain?
-
Have encountered a strange and confusing situation. Was hoping someone might be able to assist. Basically I have a rather simple setup. I'm using my ISPs DNS servers (not OpenDNS or Google DNS) and have disabled the pfSense DNS forwarder service. As a result, I'm able to access the internet without issue. All is good so far…
The issue: this is a windows home server box with which I'm trying to use a custom domain (xxxx.homeserver.com). The issue is that the WHS client PC that is behind the pfSense 2.0 router is reporting an internal IP address (192.168.0.100) to the microsoft DDNS service instead of the internet IP address. As a result, I'm unable to access my PC via http://xxxx.homeserver.com via the internet, but am able to access it behind the router on the LAN as http://192.168.0.100. Therefore I know the web site on the box is configured correctly.
In addition, if I point to http://xxxx.dyndns.org (also mapped to the 192.168.0.100 IP), it successfully resolves to my internet IP and the same PC is accessible. Only in that case, I am using the pfSense dynamic DNS client to update my DYNDNS.org address.
Something appears to be causing the dynamic dns updating service running on the WHS client PC to be registering it's local LAN IP of 192.168.0.100 as it's public address instead of the internet IP. If I browse to http://whatismyip.com from the 192.168.0.100 machine, it does correctly report back my internet IP address.
-
Well, unless you configure the DynDNS client to pull the IP from an external source (like whatismyip.com), then it is going to use the IP assigned to its interface. pfSense has the capability of updating a DynDNS service with the IP of the WAN. When it changes, then it updates the service.
-
My challenge is that WS2008 has a built-in service (Windows Server Domain Name Management) the updates its custom xxxx.homeserver.com domain on the internet with the IP of the PC. Since this PC resides behind the pfSense router, it is passing 192.168.0.100 to the internet domain server. As result, it is not possible to ping xxxx.homeserver.com and return the internet IP address. What options are there to make the PC with internal IP of 192.168.0.100 aware of it's internet IP address so that it passes the internet address to the domain name management service during each update?
-
Podilarius - the DynDNS service is smarter than that. My DynDNS client runs in a Windows VM with an RFC1918 address but my dynamic public IP is still detected and updated correctly.
Miles267 - is there some advantage to using the MS DDNS service rather than your DynDNS account to get remote access to your WHS?
-
Yes, when using the custom MS domain xxxx.homeserver.com, they also provide a free SSL cert that corresponds w/ the registered xxxx.homeserver.com name. Whereas, if I https://xxxx.dyndns.org, my SSL cert cannot be validated.
-
Fair enough. Have you tried https://<yourserver>.homeserver.com?
I'm curios as to how do you know that the internal IP (192.168.0.100) is being sent to the MS DDNS service?
For example, have you done an nslookup on <yourserver>.homeserver.com and does it return your internal IP?
I assume you've done all the port forwarding (TCP 80, 443 and 4125) that WHS needs and you have no other servers trying to use the same ports.</yourserver></yourserver>
-
Biggsy, now that you mention it, I'm not certain that xxxx.homeserver.com is being registered with 192.168.0.100. But when I look at the WHS 2011 registry entries for their built-in DDNS it is showing the last updated IP as 192.168.0.100. In fact, my ports are being forwarded correctly because I am able to access the same web site using https://xxxx.dyndns.org (via port 443, for example). Port 4125 isn't needed for WHS 2011 though it may be for WHS v2. I am curious whether the MS DDNS is being blocked outbound from behind my LAN? I really have no way of seeing what internet address the DDNS client is trying to access as a next step.
-
I don't think the MS DDNS would be blocked outbound from your LAN - not by default anyway. It's probably just an HTTPS connection to the MS server. Try the nslookup and see what's returned.
-
Thanks again for your response and insight. When I use: http://network-tools.com, it returns the following:
67.222.132.199 is a non-cached DNS Server
[67.222.132.199] returned a non-authoritative response in 219 ms:
Answer records
[none]
Authority records
[none]
Additional records
[none] -
That wouldn't be blocked with the default config. The problem is on your Windows system, it has to get the real IP and use it rather than just registering the internal IP it has. How to accomplish that? Not sure, better suited for a Windows-related forum probably.
-
Surely the MS DDNS service is clever enough to use the source address of the updates rather than an internal IP? As has been said this works for other ddns client software running on an internal machine.
Also I would expect a huge majority of WHS installs to be behind a router on a private network.
I assume you aren't testing this from within your LAN. This can cause problems with routing unless you have NAT reflection turned on.
67.222.132.199, this was your real IP when you tested? Does that not mean that it is returning the correct IP and the problem is one of either routing or filtered packets?
Steve
-
67.222.132.199 is probably just the DNS server. Doesn't look like his DynDNS is registering any address for that system.
-