[solved] SSL certificate for web gui used for other websites behind opnsense?

[Peronia]

Hi,

i have imported a valid SSL certificate for the web gui and set it under System/Settings/Administration for the web gui. Works fine, no problems.

A couple of days ago I noticed that I can't reached my websites (2) locally, but they are online and reachable from externel networks. I got a certificate error, the certificate from opnsense is being used. Logically the common name is invalid.

So I changed the certificate back to the self signed one from installation and same error, only the message changes (certificate is now selfsigned).
I also tried the option listen interfaces. E.g. when I uncheck WAN, the website isn't reachable locally (timeout). Seems strange to me, since this option is only for the web gui from opnsense.

Before the problem appeared I moved to a new apartment, in the old one I don't have this problem because in front of my opnsense was a reverseproxy from the company from which I got the Internet (the reverseproxy overwrites the certificate I think). So the way for a request was: company router->company reverseproxy->opnsense (my router)->reverseproxy (mine, nginx)->webserver.
Now I'm directly connected to the internet (as normal) and the way from a request is: opnsense->reverseproxy(nginx)->webserver and backwards. The correct certificate is set from the reverseproxy and, as I wrote, works smooth outside my network.

But the header from the reverseproxy (e.g. HSTS) are passed throught, only the certificate is modified.

Why I'm sure that the wrong certificate comes from opnsense? I updated only this certificate und can see the changes when I try to connect locally to the websites.

opnsense version: 21.7.3_3-amd64

Can you please help me find the cause for this problem?

[Fright]

Hi

I got a certificate error, the certificate from opnsense is being used. Logically the common name is invalid.

So I changed the certificate back to the self signed one from installation and same error, only the message changes (certificate is now selfsigned).

looks like you hitting on GUI port. not nginx

[Peronia]

Yes, the port is always 443.

But the domains complete different. Like example.com for the webpage and internal.anotherexample.pl for opnsense.

So I use the first domain and become an error with the opnsense certificate.

[Fright]

ah. so your nginx is configured to access the gui through it (there is a server, upstreams are configured, etc.)?
please describe the configuration in more detail.
now looks more like a small misconfig in nat, reflection, nginx or some: you are obviously knocking on the gui, not on the nginx

[Peronia]

No, the web gui is not part of nginx, only the websites are.
The web gui is only local and direct via opnsense available.
For port 80 and 443 exists one nat rule, that forward the traffic to the nginx. These nats only trigger over wan.
So when I want to hit the web gui, the nginx do nothing.
But when I want to see a webpage, the nginx do all the stuff.

[Fright]

sorry, still confused with the config (gui and nginx cannot seat on the same socket. so if it works somehow, probably nginx listening other port and rdr-rule passes external traffic to this one. and you use nat reflection to access your sites by external address from lan. but im guessing now).
cant suggest anything without config understanding (

[Peronia]

See attachment.
Fact 1: external client want to see my website: external client -> internet -> my opnsense (over WAN port 443/80) -> nginx (redirect port 80 to 443, get data from webserver over port 80, encrypt them and send back over port 443). Works fine.

Fact 2: internal client want to see my website: opnense (over LAN on port 443/80) -> internet (over WAN, resolv domain to external IP and connect with it) -> opnsense (over WAN port 443/80) -> nginx (redirect port 80 to 443, get data from webserver over port 80, encrypted them and send back over port 443).
Don't work. I got the certificate from the web gui from opnsense. When i accept it, i can see the webpage, but with wrong certificate.

Fact 3: internal client want to see the web gui from opnsense: opnense (over LAN on port 443/80) -> opnsense (redirect port 80 to 443).
Works fine (with right certificate).

Fact 4: external client want to see the web gui from opnsense: external client -> internet -> my opnsense (over WAN port 443/80) -> nginx (don't know any destination for the web gui) -> error
Is as it should.

Maybe this helps?

[Fright]

ah, sorry, when you mentioned nginx i was totally sure that you use nginx plugin on opnsense. so nginx is a separate host.
then
0. is nat reflection enabled?
1. when you nslookup your "example.com" on internal client to what ip it resoves? (internal or opnsense wan?)
2. does an initial packet from an internal client with 'wan ip' destination appear on the internal opn interface?
3. does nginx sees this connection from internal client?

header from the reverseproxy (e.g. HSTS) are passed throught, only the certificate is modified

this is a little confusing. if the browser does not accept the certificate and the trust is not forced, then the server headers should not be visible in the browser console imho.

if you force browser to trust this cert, what you see in browser? gui login (or dns rebinding message)?

the old one I don't have this problem because in front of my opnsense was a reverseproxy from the company from which I got the Internet (the reverseproxy overwrites the certificate I think). So the way for a request was: company router->company reverseproxy->opnsense (my router)->reverseproxy (mine, nginx)->webserver.

looks like nat reflection not enabled (it was not required with the previous connection scheme)

[Peronia]

Okay okay:

• No, nat reflection was disabled. I enabled it and all is like expected.
• I tried this before and after turn on nat reflection, same outup: external IP
• I have not tried
• I have not tried

HSTS don't show up in the console. I saw it throught the message for an invalid certificate from the browser. He says that HSTS is on and I can't create an exception for that website.
When I forced to trust, I saw the normal website, only with an invalid certificate.

I turned nat refelection in the system for all connections on. Now I can see my websites with the right certificate and visit my teamspeakserver over the domain (previously only via internal ip possible).

But when I take a look at https://docs.opnsense.org/manual/nat.html, I don't get it, why nat reflection solves my problem. I will use the external IP, to pass my nginx and see the website with the right certificate. Or is it vice versa?

[Fright]

But when I take a look at https://docs.opnsense.org/manual/nat.html, I don't get it, why nat reflection solves my problem.

hm
docs quote:

NAT reflection: When a client on the internal network tries to access another client, but using the external IP instead of the internal one (which would the most logical), NAT reflection can rewrite this request so that it uses the internal IP, in order to avoid taking a detour and applying rules meant for actual outside traffic.

isn't that what you were trying to achieve? access local server by firewall public (instead of using split DNS)?
without reflection (or manual hairpinning) traffic from the internal client is not tranlated and therefore is routed directly to the external interface of the OPN (in this case, to port 443, where the gui is waiting for it). this was not required before the apartment was changed, as then the traffic really left the OPN, reached the company's equipment and returned with the source address of the company's reverse proxy.

HSTS don't show up in the console. I saw it throught the message for an invalid certificate from the browser. He says that HSTS is on and I can't create an exception for that website.

This can be explained by the fact that you previously successfully connected to the site, browser received the HSTS header with the max-age parameter and saved it to the store. so when you access gui by the external web-server fqdn there was actually no header, the browser took it from the store. for chrome you can check store at chrome://net-internals/#hsts
so HSTS worked as expected)

When I forced to trust, I saw the normal website, only with an invalid certificate.

I can neither understand nor explain this. everything suggests that if reflection was disabled, when the internal client accessed an external address (and hsts restriction not applied), a gui or a dns rebinding alert should have been seen imho

I will use the external IP, to pass my nginx and see the website with the right certificate. Or is it vice versa?

did not quite understand the question. please explain

[Peronia]

isn't that what you were trying to achieve? access local server by firewall public (instead of using split DNS)?
without reflection (or manual hairpinning) traffic from the internal client is not tranlated and therefore is routed directly to the external interface of the OPN (in this case, to port 443, where the gui is waiting for it). this was not required before the apartment was changed, as then the traffic really left the OPN, reached the company's equipment and returned with the source address of the company's reverse proxy.

Than NAT reflection act's in both ways? Since I don't wan't to use the internal over the external address , I want to use the external over the internal address.

did not quite understand the question. please explain

From the docs, I see NAT reflection works to use the internal over the public address. Make sense, but thats not my goal (see above). So NAT reflection works in both ways? Internal over public and public over internal (sounds strange to me, but maybe...)?

[Fright]

I want to use the external over the internal address.

sorry, I don't fully understand the question
without reflection, you have only one rule that translates (redirects) a request 'from the external clients to the external interface on port 443' to the address of your internal nginx and port 443.
When you enable reflection, additional rules are created that translate requests from 'internal clients to internal interfaces and port 443' to the address of your internal nginx and port 443. When you additionally enable the "Automatic outbound NAT for Reflection" option, additional nat rules are created that change the address of the internal client to the address of the corresponding internal interface.
reflection does not make any changes to the initial rdr (Port Forward) rules. nothing changes for external clients