I have a very weird situation perhaps you all can help with.
I’m running OS X server which has CardDAV and CalDAV services to various Macs and iOS devices.
Occasionally, I’m seeing that a device inside the LAN (which is making a request to the server over SSL on port 8443) is coming up with a “certificate mismatch error” and when I look at the certificate details, i’m seeing “captive-portal.peplink.com”.
Captive Portal is disabled
The IP address that is accessed has Inbound Access / Port forwarding set up properly.
This issue only happens on devices on LAN. For example on my iPhone, I can trigger the error on WiFi on the LAN, but if I turn off WiFi and use the cellular network (which is then accessing via WAN) I don’t see it happen.
Theories:
DNS problem? If for some reason the Peplink was returning its own IP address (instead of the IP address of my server) then I could see how it would deliver the wrong SSL certificate. I did make some DNS changes about to weeks ago, but have rebooted everything multiple times since then.
Inbound Access / Port Forwarding bug? Could it be that in some cases, a device on the LAN does not receive the benefits of port forwarding when accessing an IP address and Port that is on the WAN side?
I’m stumped here - anyone else seen similar issues?
Based on my understanding, OS X server is located at LAN side of Balance router. When client on LAN side making a request to the server over SSL on port 8443, certificate error showed. However, this never happen if client access the server from WAN. Do correct if I am wrong.
Can you share what is the URL for LAN and WAN user to access the OS X server? If LAN and WAN users accessing it with a domain name, Do let me know the IP resolved by LAN and WAN client.
Yes, I believe you have it right. I’m pretty sure that the client is using a DNS lookup to get the WAN IP rather than the LAN IP. If the client were using the LAN IP I would not expect Port Forwarding to work.
Unfortunately this is mostly happening on the iOS client so I’m able to get much debugging info (such as the actual IP address it’s querying). I’ll do more testing to see if I can isolate the issue.
Additional info:
I have 2 cable modems
modem “A” has 5 static IP addresses (4 of which are set up in Network/WAN/Additional Public IP Settings).
modem “B” has a dynamic IP address
Port forwarding is set to use only “Interface IP” on modem “A”.
Since the issue seems to come and go, i wonder if it could be something like this:
iOS client tries to access the WAN:Port info
The PepLink chooses to send the request out on Modem A
The request works.
But Later:
iOS client tries to access the WAN:Port info
The PepLink chooses to send the request out on Modem B
The request fails since Port Forwarding doesn’t work?
Update: I just realized this may be my own fault. When I first put the Peplink into service, I was worried about some protocols not being happy over dual WAN system, so I put in an Outbound rule:
Network/Outbound/Policy/ Enforced WAN1 / IP Address=<my server LAN IP> / Destination:Any / Port:Any
Unfortunately a few weeks ago, I changed the IP addresses on all my servers on the LAN, and I forgot to update the IP address in this rule.
So this may very well be my fault due to a misconfiguration.
I’ve updated the rule to the correct IP address and will see if that fixes the problem. I’ll report back when I know more.
To follow up - this was a combination of two problem - the misconfiguration above, and a very sticky DNS cache in OS X 10.10.x - even months after I had fixed the configuration problem, one of my machines kept pulling the wrong IP address for a DNS lookup.
Even weirder, the wrong DNS lookup was app-specific: I could try the server’s DNS name in Safari and it would fail (deliver the wrong IP address) but if I tried CURL from the command line, it would work, but DIG would return the right address. Apparently OS X has more than one DNS cache and they can get out of sync. Ugh.
Eventually I did something and got the DNS cache to clear, and now it all works normally.