SSL on OpenWRT with Wireguard

Installing and Using OpenWrt
1

Hello everyone,

I have some diffculties to use Wireguard server on my OpenWRT router.

The connection works fine, the VPN is on, but when i want to access my server apps/websites (on https), it gives me en error. No problems for any other websites, only the ones on my server.

"NSURLErrorSecureConnectionFailed"

I guess it's because there is no secure continuity between my secure Wireguard connection and my self hosted SSL websites.

I've tried to put SSL on my router, without any luck, but i might have it wrong.

Thanks in advance for the help.

2

A simple web search shows this is an Apple-specific error.

  • Is your client a MacOS device?
  • Is there some HTTPS proxy involved?
3

Yes i'm on Apple, and my self hosted websites are behind a HTTPS reverse proxy (https://xxx.mydomain.com).

I've seen the problem, so i've simply tried to put Wireguard on my Docker instance on the same server, and everything works fine.

I've concluded there is a problem with OpenWRT.

4

OpenWrt doesn't run an Apple-based OS.

  • This seems to be the issue from a simple web search
  • For clarity, is this proxy running on the OpenWrt?
1 Like
5

I definitely know that :slight_smile:

The reverse proxy is running on Docker like every other apps i got on my server.

1 Like
6

The problem here may be that your Wireguard VPN service doesn't "hairpin" a request for your own public IP back to you properly.

Often it is simplest to cheat and install your website's FQDN in your local DNS as the LAN IP of the server. Then the request never leaves the site. If OpenWrt is your local DNS, this is done by adding the name and IP to /etc/hosts.

2 Likes
7

Example, when i'm connected i got messages like "Your OpenWRT certificate is not valid", from my DAV app.

Do you know how i can add the name and IP on Luci ? Sorry i'm not a great tech guy.

8

Use Network-->DHCP and DNS-- Hostnames tab.
This actually installs a config domain into /etc/config/dhcp. The result is the same though, when you look up your public name from a machine on the LAN at home, it will use the LAN IP.

9

Thank you for the idea, doesn't change anything sadly.

10

Which address are you using and which domain does the certificate include?

11

I can't give you the domains for privacy reasons but you got a point here, the SSL certificates are only for the the domains (behind a reverse proxy) of my server, the ones causing me troubles.

Maybe there is a way to "include" the router inside the certificates ?

12

Nah, you've misconfigured something.

13

The router is irrelevant as it just routing the packets.
The browser will contact the reverse proxy with a name www.kef.wrt and it will expect to get a trusted certificate including that domain.
If the certificate is self signed, the browser will complain.
If the name is signing another domain, the browser will complain.
You can give examples of fictitious domains, as long as you keep consistency and specify which are self signed.

4 Likes
14

My certificates for the reverse proxy domains (a.mydomain.com, b.mydomain.com...) are coming from Letsencrypt, that can be the problem ? I don't have any troubles accessing my HTTPS domains except on this configuration.

The thing i don't understand: it's working perfectly when i put the wireguard server on docker, or directly on the server.

15

What is the topology in both scenarios?
You have OpenWrt router on the edge, then some server in the lan running the reverse proxy and the web servers? The domain names resolve to public IP or private? Which one is it?

16

Yes, my installation is pretty basic like you said.

The domains are resolving with HTTPS (Letsencrypt certificates generated with NginxProxyManager) on port 443 to the private lan adress of the server (192.168.10.20), to the different ports for each app.

Got NginxProxyManager, AdGuard, SearXNG, etc ... all running in a Docker instance, but i guess it's irrelevant.

17

This would seem to suggest there is something running on the OpenWRT device that is intercepting the SSL requests. It'd probably be useful to see the contents of /etc/config/firewall and /etc/config/uhttpd as a minimum. /etc/config/network may also be useful.

2 Likes
18

Yes it seems so, but only for the local network.

Here is the files, uhttpd was empty.

Firewall :

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'

config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'
        option enabled '0'

Network :

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option packet_steering '1'
        option ula_prefix 'fdf9:5119:acc2::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.100.1'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'
        option peerdns '0'
        list dns '45.90.28.154'
        list dns '45.90.30.154'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        list dns '2a07:a8c0:0000:0000:0000:0000:00ae:fae8'
        list dns '2a07:a8c1:0000:0000:0000:0000:00ae:fae8'
        option peerdns '0'

config device
        option name 'wan'
        option macaddr ''

config interface 'wg0'
        option proto 'wireguard'
        option private_key 'XXXX'
        option listen_port 'XXXX'
        list addresses '10.15.15.0/24'

config wireguard_wg0
        option public_key 'XXXX'
        option private_key 'XXXX'
        option preshared_key 'XXXX'
        option endpoint_host 'XX.domain.com'
        option description 'kWG'
        list allowed_ips '0.0.0.0/0'
19

This error message is so generic that nothing can be known about the nature of the error. NSURL is Apple's SSL stack, so you'll only see this on Apple devices. Do non-Apple operating systems work with your sites on the same network situation?

It's possible that NSURL has flagged the combination of a public name with a RFC1918 IP address as suspicious of a man in the middle attack and refuses to connect. But I don't know much about Apple stuff at all.

No it's not that. The whole point of SSL is so the Internet can be treated as the insecure connection it is with eavesdroppers and men in the middle. So SSL does end to end encryption to protect the application data from attacks, not requiring the Internet channel itself to be secure.

20

There is something missing from here.

1 Like