[SOLVED] Weird SSL issue
-
I'm hoping this is the right place for this, couldn't see anywhere else more apropos.
We're NATing an internal/external webserver behind a 2.3.2 install. Internally, everything is great. Externally however, the pfSense install appears to be MITMing and it's causing grief - it's using an HSTS self-signed server cert. None of the other external website/SSL NATs are exhibiting this issue, just this one.
Any hints? NAT reflection is disabled, I've tried disabling Squid (not that we had SSL MITM enabled).
-
so your saying you have https (443) forwarded to an internal server, lets call it 192.168.1.100. So when I hit your public IP say 1.2.3.4 via https I am getting a different cert? Than what your server is using?
-
Precisely John.
Being somewhat specific, the Internet talks to a vIP of x.x.x.245 (/24), and that is NATed to 10.0.0.11 on the "green" (internal) network. 10.0.0.11 has a valid current certificate on it and internally that's what you "see" when you go to https://blah.example.com (internal DNS points at 10.0.0.11).
Externally, https://blah.example.com points at x.x.x.245 (totally separate DNS) and you "see" the pfSense web GUI cert (I've checked multiple times now) and you get no further than that due to the self-signed HSTS nature of the cert. I've done a packet cap, the traffic arrives normally on WAN, but nothing comes out on the LAN interface, but the NAT/rule is in there and hadn't changed in a good few weeks (replaced it today to see if anything would be different; it wasn't - according to AutoConfigBackup, the last change I can definitely attribute to something in the firewall section was 10 August).
-
can you post your wan rules and your forwards.. And if you don't mine can you send me the actual fqdn via pm and I can check from public.
Do you have anything that could reorder your rules? Say for example pfblocker likes to do a reorder of the rules, etc..
-
Oh, I feel like such a fool. Turns out our internal DNS service (WINS as well) was not running (following a server restart on Tuesday), but we didn't notice until this morning after restarting a few other servers and they refused to let us log in after. I would guess either the firewall was trying to lookup the IP of the web server(s), getting no response and trying to be helpful, or the web server(s) were trying to do lookup(s), getting no response and giving up.
Many apologies John, please accept a karma for your troubles.
