My OMV got hacked, I need help

Zitat von Soma

There's some misunderstandings on this matter.

The reason that OP was hacked, is none other than the fact that the container was running wide open.

When launching Heimdall and reverse-proxy it (be it via SWAG, NPM, whatever) it should be enforced that it should be configured a password access on it:

If people don't do this, anyone who can manage to find the URL, will be able to do any changes they want (which was the case of OP).

If the container is running as an unpriveledge user, the hack won't go too far other than beeing able to change the Heimdall container itself.

The links on the above example point to reverse-proxied services that will require another auth, once clicked. (NOTE: except SCRUTINY but will explain below)

The above example has only default links on Heimdall that point to other proxied services. Clicking those links will open NEW webpages that require another authentication. Hack will be blocked.

Now, let's add some complexity to this:

Imagine that USER created the links with access to extract INFO from the services that the links point to (which required saved USER/PASSWORD) to read some METRICS from those same services.

The HACKER will be able to find more INFO on how to access those services.

As mentioned above, the SCRUTINY service that is seen on that PAGE, once running, is open to the world.

Although it's a not-so-dangerous container, it's still accessible from anyone via WAN (if they figure out the URL), as long as it's running.

With this in consideration, I keep the container down, until I want to see the INFO from it:

Go to OMV GUI, launch the container on Services-> Compose, access the SCRUTINY PAGE, see what I want to see and bring the container down, afterwards.

So, TL:DR;

When running Heimdall, make sure that a USER/PASSWORD is set/created PRIOR to make any hops/links to block any unwanted access.

Alles anzeigen

Agreed. Running wide open is a major security concern, but that was already mentioned above.

My reverse proxy/fail2ban comments along with the mention of only exposing things that you want others to access using a login is the the whole point.

Minimize the attack surface by reducing the number of things exposed to the world, secure it with some kind of authentication, and do it through a reverse proxy so the open open ports are minimized and something like fail2ban can be implemented to monitor the logs and automatically institute bans if someone is hammering to try to get in.

That is the minimum requirement as far as I am concerned, and realistically it's basically what you need in order to make the cloudflare/firewall things that others suggested functional.

The other options like the cloudflare thing can work, but once again to make it effective, something like fail2ban via a connector needs to report failed attempts to cloudflare. Without that you are just masking your wan ip address. The pfsense/opnsense thing can help by instituting a good firewall with lots of control, but once again, unless it is actually handling the reverse proxy and failed login monitoring, it has no way to block someone from hammering.

ToTheRedMoon, why don't you setup a VPN-Connection on your router instead of exposing your docker to the internet?

Zitat von Soma

As mentioned above, the SCRUTINY service that is seen on that PAGE, once running, is open to the world.

Although it's a not-so-dangerous container, it's still accessible from anyone via WAN (if they figure out the URL), as long as it's running.

With this in consideration, I keep the container down, until I want to see the INFO from it:

Go to OMV GUI, launch the container on Services-> Compose, access the SCRUTINY PAGE, see what I want to see and bring the container down, afterwards.

So, TL:DR;

When running Heimdall, make sure that a USER/PASSWORD is set/created PRIOR to make any hops/links to block any unwanted access.

Alles anzeigen

Suggest open to scrutiny developer, perhaps reacts:

[FEAT] add htpasswd or some mechanism to protect webGUI with user/password · Issue #462 · AnalogJ/scrutiny

I use your valuable piece of software on a docker and expose webGUI throught heimdall, I have secure conecction (https), but scrutiny do not ask for…

github.com

Zitat von raulfg3

Suggest open to scrutiny developer, perhaps reacts:

There's always the possibility to add Authelia via SWAG but didn't give it much thought.

It's a simple container that I don't need to have it running full-time,

Zitat von Soma

There's always the possibility to add Authelia via SWAG but didn't give it much thought.

It's a simple container that I don't need to have it running full-time,

Yeah, verbatim, I could not get authelia to work with swag worth a damn!!! But I got it working on NGINX, but then NGINX I could not get it to redirect to my other hosts on different ips, like SWAG could.

So I said F it all, I am done.

ONE thing on SWAG; Heimdall. Heimdall has LAN IP for links so inaccessible from Internet, which makes heimdall pointless.

So, I just connect to LAN via Wireguard and it is all there.

Zitat von fbeye

Yeah, verbatim, I could not get authelia to work with swag worth a damn!!! But I got it working on NGINX, but then NGINX I could not get it to redirect to my other hosts on different ips, like SWAG could.

So I said F it all, I am done.

ONE thing on SWAG; Heimdall. Heimdall has LAN IP for links so inaccessible from Internet, which makes heimdall pointless.

So, I just connect to LAN via Wireguard and it is all there.

I use nginx-proxy-manager. I have no problems helping you or anyone else with the setup if I can, by supplying some info. I have no idea about using authelia with it though. I have never tried it.

The basic setup is fairly simple though.

Put it in the same docker network as your docker service that you want to expose.

The host is then set up using HTTP [container name] port.

I recommend enabling the block common exploits option.

The cache assets is optional, but this allows npm to cache static elements for faster access, and the websockets support is usually not needed since most containers are actually running their own web server via http and not using sockets

The access lists allow for restricting access to LAN, WAN, or adding a login to things that don't have a login.

You can also enable ssl and get a lets encrypt cert. If you then enable the force ssl option, all traffic is forced to ssl encryption. No need for HTTPS in the containers since NPM converts to it.

HTTP/2 is the newer HTTP protocols and considered more secure (I can't tell your the exact reasoning though)

The HSTS options are more secure again.

NPM does not support wildcard certs, so you need a cert per host.

Custom locations and advanced are usually not needed, bit do allow for some more advanced things. ie. nextcloud requires some custom locations to be set and some advanced options to be set for it to behave properly when running in a VM. I would assume the docker install would also require them.

If the service is not a docker, but instead a vm or lxc, substitute the ip address in place of the container name. You can also use the ip if the container is not on this docker network, but it is cleaner in regards to LAN traffic if they are on the same docker networ and use the container name.

If you want fail2ban then you deploy the following docker, modifying as required for your setup:

version: "3.7"

services:

   fail2ban:
    image: crazymax/fail2ban:latest
    container_name: fail2ban
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    environment:
      - PUID=1000 #user id
      - PGID=100 #group id
      - TZ=[enter your time zone]
      - F2B_LOG_TARGET=STDOUT
      - F2B_LOG_LEVEL=INFO
      - F2B_DB_PURGE_AGE=180d # days to keep data
#      - SSMTP_HOST=smtp.example.com
#      - SSMTP_PORT=587
#      - SSMTP_HOSTNAME=example.com
#      - SSMTP_USER=smtp@example.com
#      - SSMTP_PASSWORD=
#      - SSMTP_TLS=YES
    volumes:
      - /path/po/persistent/data/fail2ban:/data
      - /path/to/npm/logs/data/logs:/var/log:ro
    restart: unless-stopped   

In the fail2ban persistent data bind, create the following npm-docker.local file in the jail.d, adjusting the maxretry, bantime and findtime to suit your needs:

[npm-docker]
enabled = true
ignoreip = 127.0.0.1/8 192.168.2.0/24
chain = INPUT
action = iptables-nft[type=allports, chain=DOCKER-USER]
logpath = /var/log/default-host_*.log
          /var/log/proxy-host-*.log
maxretry = 5
bantime  = 10800
findtime = 3600

Create this npm-docker.conf file in the filter.d

[INCLUDES]

[Definition]

failregex = ^<HOST>.+" (4\d\d|3\d\d) (\d\d\d|\d) .+$
            ^.+ 4\d\d \d\d\d - .+ \[Client <HOST>\] \[Length .+\] ".+" .+$

and create this iptables-nft.local file in the action.d

## Version 2022/08/06iptables-nft
# Fail2Ban configuration file
#
# Authors: Sergey G. Brester (sebres), Cyril Jaquier, Daniel Black, 
#          Yaroslav O. Halchenko, Alexander Koeppe et al.
#

[Definition]

# Option:  type
# Notes.:  type of the action.
# Values:  [ oneport | multiport | allports ]  Default: oneport
#
type = oneport

# Option:  actionflush
# Notes.:  command executed once to flush IPS, by shutdown (resp. by stop of the jail or this action)
# Values:  CMD
#
actionflush = <iptables-nft> -F f2b-<name>

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = { <iptables-nft> -C f2b-<name> -j <returntype> >/dev/null 2>&1; } || { <iptables-nft> -N f2b-<name> || true; <iptables-nft> -A f2b-<name> -j <returntype>; }
              <_ipt_add_rules>

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = <_ipt_del_rules>
             <actionflush>
             <iptables-nft> -X f2b-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = <_ipt_check_rules>

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables-nft> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = <iptables-nft> -D f2b-<name> -s <ip> -j <blocktype>

# Option:  pre-rule
# Notes.:  prefix parameter(s) inserted to the begin of rule. No default (empty)
#
pre-rule =

rule-jump = -j <_ipt_rule_target>

# Several capabilities used internaly:

_ipt_for_proto-iter = for proto in $(echo '<protocol>' | sed 's/,/ /g'); do
_ipt_for_proto-done = done

_ipt_add_rules = <_ipt_for_proto-iter>
              { %(_ipt_check_rule)s >/dev/null 2>&1; } || { <iptables-nft> -I <chain> %(_ipt_chain_rule)s; }
              <_ipt_for_proto-done>

_ipt_del_rules = <_ipt_for_proto-iter>
              <iptables-nft> -D <chain> %(_ipt_chain_rule)s
              <_ipt_for_proto-done>

_ipt_check_rules = <_ipt_for_proto-iter>
              %(_ipt_check_rule)s
              <_ipt_for_proto-done>

_ipt_chain_rule = <pre-rule><ipt_<type>/_chain_rule>
_ipt_check_rule = <iptables-nft> -C <chain> %(_ipt_chain_rule)s
_ipt_rule_target = f2b-<name>

[ipt_oneport]

_chain_rule = -p $proto --dport <port> <rule-jump>

[ipt_multiport]

_chain_rule = -p $proto -m multiport --dports <port> <rule-jump>

[ipt_allports]

_chain_rule = -p $proto <rule-jump>


[Init]

# Option:  chain
# Notes    specifies the iptables chain to which the Fail2Ban rules should be
#          added
# Values:  STRING  Default: INPUT
chain = INPUT

# Default name of the chain
#
name = default

# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
#
port = ssh

# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp
#
protocol = tcp

# Option:  blocktype
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp-port-unreachable
# Values:  STRING
blocktype = DROP

# Option:  returntype
# Note:    This is the default rule on "actionstart". This should be RETURN
#          in all (blocking) actions, except REJECT in allowing actions.
# Values:  STRING
returntype = RETURN

# Option:  lockingopt
# Notes.:  Option was introduced to iptables to prevent multiple instances from
#          running concurrently and causing irratic behavior.  -w was introduced
#          in iptables 1.4.20, so might be absent on older systems
#          See https://github.com/fail2ban/fail2ban/issues/1122
# Values:  STRING
lockingopt = -w

# Option:  iptables
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables-nft = iptables-nft <lockingopt>


[Init?family=inet6]

# Option:  blocktype (ipv6)
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp6-port-unreachable
# Values:  STRING
blocktype = DROP

# Option:  iptables (ipv6)
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables-nft = ip6tables-nft <lockingopt>

restart fail2ban.

The filter file is a regex expression that looks for 400 errors and passes them to the jail file which takes those values and performs the action file on them.

The action file creates an iptables ban on the host in the DOCKER-USER chain to block the ip's that exceed the the maxretry value within the findtime (in seconds) and bans them for the bantime (in seconds)

UM

Zitat von BernH

I use nginx-proxy-manager. I have no problems helping you or anyone else with the setup if I can, by supplying some info. I have no idea about using authelia with it though. I have never tried it.

The basic setup is fairly simple though.

Put it in the same docker network as your docker service that you want to expose.

The host is then set up using HTTP [container name] port.

I recommend enabling the block common exploits option.

The cache assets is optional, but this allows npm to cache static elements for faster access, and the websockets support is usually not needed since most containers are actually running their own web server via http and not using sockets

The access lists allow for restricting access to LAN, WAN, or adding a login to things that don't have a login.

You can also enable ssl and get a lets encrypt cert. If you then enable the force ssl option, all traffic is forced to ssl encryption. No need for HTTPS in the containers since NPM converts to it.

HTTP/2 is the newer HTTP protocols and considered more secure (I can't tell your the exact reasoning though)

The HSTS options are more secure again.

NPM does not support wildcard certs, so you need a cert per host.

Custom locations and advanced are usually not needed, bit do allow for some more advanced things. ie. nextcloud requires some custom locations to be set and some advanced options to be set for it to behave properly when running in a VM. I would assume the docker install would also require them.

If the service is not a docker, but instead a vm or lxc, substitute the ip address in place of the container name. You can also use the ip if the container is not on this docker network, but it is cleaner in regards to LAN traffic if they are on the same docker networ and use the container name.

If you want fail2ban then you deply the following docker, modifying as required for your setup:

Code: fail2ban docker compose

version: "3.7"

services:

   fail2ban:
    image: crazymax/fail2ban:latest
    container_name: fail2ban
    cap_add:
      - NET_ADMIN
      - NET_RAW
    network_mode: host
    environment:
      - PUID=1000 #user id
      - PGID=100 #group id
      - TZ=[enter your time zone]
      - F2B_LOG_TARGET=STDOUT
      - F2B_LOG_LEVEL=INFO
      - F2B_DB_PURGE_AGE=180d # days to keep data
#      - SSMTP_HOST=smtp.example.com
#      - SSMTP_PORT=587
#      - SSMTP_HOSTNAME=example.com
#      - SSMTP_USER=smtp@example.com
#      - SSMTP_PASSWORD=
#      - SSMTP_TLS=YES
    volumes:
      - /path/po/persistent/data/fail2ban:/data
      - /path/to/npm/logs/data/logs:/var/log:ro
    restart: unless-stopped   

Alles anzeigen

In the fail2ban persistent data bind, create the following npm-docker.local file in the jail.d, adjusting the maxretry, bantime and findtime to suit your needs:

Code: npm-docker.local

[npm-docker]
enabled = true
ignoreip = 127.0.0.1/8 192.168.2.0/24
chain = INPUT
action = iptables-nft[type=allports, chain=DOCKER-USER]
logpath = /var/log/default-host_*.log
          /var/log/proxy-host-*.log
maxretry = 5
bantime  = 10800
findtime = 3600

Create this npm-docker.conf file in the filter.d

Code: npm-docker.conf

[INCLUDES]

[Definition]

failregex = ^<HOST>.+" (4\d\d|3\d\d) (\d\d\d|\d) .+$
            ^.+ 4\d\d \d\d\d - .+ \[Client <HOST>\] \[Length .+\] ".+" .+$

and create this iptables-nft.local file in the action.d

Code: iptables-nft.local

## Version 2022/08/06iptables-nft
# Fail2Ban configuration file
#
# Authors: Sergey G. Brester (sebres), Cyril Jaquier, Daniel Black, 
#          Yaroslav O. Halchenko, Alexander Koeppe et al.
#

[Definition]

# Option:  type
# Notes.:  type of the action.
# Values:  [ oneport | multiport | allports ]  Default: oneport
#
type = oneport

# Option:  actionflush
# Notes.:  command executed once to flush IPS, by shutdown (resp. by stop of the jail or this action)
# Values:  CMD
#
actionflush = <iptables-nft> -F f2b-<name>

# Option:  actionstart
# Notes.:  command executed on demand at the first ban (or at the start of Fail2Ban if actionstart_on_demand is set to false).
# Values:  CMD
#
actionstart = { <iptables-nft> -C f2b-<name> -j <returntype> >/dev/null 2>&1; } || { <iptables-nft> -N f2b-<name> || true; <iptables-nft> -A f2b-<name> -j <returntype>; }
              <_ipt_add_rules>

# Option:  actionstop
# Notes.:  command executed at the stop of jail (or at the end of Fail2Ban)
# Values:  CMD
#
actionstop = <_ipt_del_rules>
             <actionflush>
             <iptables-nft> -X f2b-<name>

# Option:  actioncheck
# Notes.:  command executed once before each actionban command
# Values:  CMD
#
actioncheck = <_ipt_check_rules>

# Option:  actionban
# Notes.:  command executed when banning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionban = <iptables-nft> -I f2b-<name> 1 -s <ip> -j <blocktype>

# Option:  actionunban
# Notes.:  command executed when unbanning an IP. Take care that the
#          command is executed with Fail2Ban user rights.
# Tags:    See jail.conf(5) man page
# Values:  CMD
#
actionunban = <iptables-nft> -D f2b-<name> -s <ip> -j <blocktype>

# Option:  pre-rule
# Notes.:  prefix parameter(s) inserted to the begin of rule. No default (empty)
#
pre-rule =

rule-jump = -j <_ipt_rule_target>

# Several capabilities used internaly:

_ipt_for_proto-iter = for proto in $(echo '<protocol>' | sed 's/,/ /g'); do
_ipt_for_proto-done = done

_ipt_add_rules = <_ipt_for_proto-iter>
              { %(_ipt_check_rule)s >/dev/null 2>&1; } || { <iptables-nft> -I <chain> %(_ipt_chain_rule)s; }
              <_ipt_for_proto-done>

_ipt_del_rules = <_ipt_for_proto-iter>
              <iptables-nft> -D <chain> %(_ipt_chain_rule)s
              <_ipt_for_proto-done>

_ipt_check_rules = <_ipt_for_proto-iter>
              %(_ipt_check_rule)s
              <_ipt_for_proto-done>

_ipt_chain_rule = <pre-rule><ipt_<type>/_chain_rule>
_ipt_check_rule = <iptables-nft> -C <chain> %(_ipt_chain_rule)s
_ipt_rule_target = f2b-<name>

[ipt_oneport]

_chain_rule = -p $proto --dport <port> <rule-jump>

[ipt_multiport]

_chain_rule = -p $proto -m multiport --dports <port> <rule-jump>

[ipt_allports]

_chain_rule = -p $proto <rule-jump>


[Init]

# Option:  chain
# Notes    specifies the iptables chain to which the Fail2Ban rules should be
#          added
# Values:  STRING  Default: INPUT
chain = INPUT

# Default name of the chain
#
name = default

# Option:  port
# Notes.:  specifies port to monitor
# Values:  [ NUM | STRING ]  Default:
#
port = ssh

# Option:  protocol
# Notes.:  internally used by config reader for interpolations.
# Values:  [ tcp | udp | icmp | all ] Default: tcp
#
protocol = tcp

# Option:  blocktype
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp-port-unreachable
# Values:  STRING
blocktype = DROP

# Option:  returntype
# Note:    This is the default rule on "actionstart". This should be RETURN
#          in all (blocking) actions, except REJECT in allowing actions.
# Values:  STRING
returntype = RETURN

# Option:  lockingopt
# Notes.:  Option was introduced to iptables to prevent multiple instances from
#          running concurrently and causing irratic behavior.  -w was introduced
#          in iptables 1.4.20, so might be absent on older systems
#          See https://github.com/fail2ban/fail2ban/issues/1122
# Values:  STRING
lockingopt = -w

# Option:  iptables
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables-nft = iptables-nft <lockingopt>


[Init?family=inet6]

# Option:  blocktype (ipv6)
# Note:    This is what the action does with rules. This can be any jump target
#          as per the iptables man page (section 8). Common values are DROP
#          REJECT, REJECT --reject-with icmp6-port-unreachable
# Values:  STRING
blocktype = DROP

# Option:  iptables (ipv6)
# Notes.:  Actual command to be executed, including common to all calls options
# Values:  STRING
iptables-nft = ip6tables-nft <lockingopt>

Alles anzeigen

restart fail2ban.

The filter file is a regex expression that looks for 400 errors and passes them to the jail file which takes those values and performs the action file on them.

The action file creates an iptables ban on the host in the DOCKER-USER chain to block the ip's that exceed the the maxretry value within the findtime (in seconds) and bans them for the bantime (in seconds)

Alles anzeigen

So, I want to be clear about something. The fail2ban instance mentioned above is solely used for NPM in this configuration? I ask simply for two reasons.

1.) I see in the fail2ban stack that it has an added path to NPM logs, which leads me to believe this fail2ban instance is simply for NPM only

2.) If I wanted to used fail2ban (outside of OMV) I would need to create a second fail2ban container.

I guess I just am confused a little bit.. I have it up and running as is and it appears to be fine thus far, I am just curious how I would implement this instance to my other containers, or if I would not, and create a different fail2ban.

Oh it seems I was wrong.. It appears I add as many volumes/locations for whatever log files for whatever containers I want added. Interesting.

Yes. you can configure it to watch whatever logs you want by giving it access to the logs and creating the appropriate jail and filter config files. The default config I posted is a basic monitor for any proxy host that is reporting a 400 group or 300 group error, which includes some unauthorized, bad request, bad redirects, etc.

Depending on the host though, this may not be enough and further jails and filters may be required. For example, my nextcloud instance monitors it's own logs with fail2ban, but uses a different jail and filter, because the nextcloud logs are a lot more complicated and it doesn't log just the basic error code. I guess i could pull it in under a single fail2ban instance used with NPM, but I just haven't done it yet. Also my nextcloud is not a docker container. It runs as an lxc vm which I recently converted to from a full qcow2 vm, so the config has changed a bit and I haven’t gone back to figure out the access and assess if it would be better to handle at the NPM level or the vm level due to the tangly nature of the nextcloud logs.

I do have plans to investigate this, but have to try to get through the next month or two of upgrades at the office before I will have the time to investigate.

[nextcloud]
backend = auto
enabled = true
port = 80
protocol = tcp
filter = nextcloud
maxretry = 10
bantime = 10800
findtime = 43200
logpath = /mnt/ncdata/nextcloud.log
action = iptables[name=nextcloud, port=http, protocol=tcp]

[Definition]
_groupsre = (?:(?:,?\s*"\w+":(?:"[^"]+"|\w+))*)
failregex = ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Login failed:
            ^\{%(_groupsre)s,?\s*"remoteAddr":"<HOST>"%(_groupsre)s,?\s*"message":"Trusted domain error.
datepattern = ,?\s*"time"\s*:\s*"%%Y-%%m-%%d[T ]%%H:%%M:%%S(%%z)?"

Oh alright that makes sense! Thank you for posting that.

Just saw this one now:

Zitat von fbeye

Heimdall has LAN IP for links so inaccessible from Internet, which makes heimdall pointless.

This is not correct:
When editing the HOP, just use the URL you want it to point to:

If your SWAG is reverse-proxying that service and your ROUTER does allow it (hairpinning), you'll be using only HTTPS links, and not LAN.

Zitat von Soma

Just saw this one now:

This is not correct:
When editing the HOP, just use the URL you want it to point to:

If your SWAG is reverse-proxying that service and your ROUTER does allow it (hairpinning), you'll be using only HTTPS links, and not LAN.

Morning. I did get this figured out a bit back… Though I went from SWAG to NGINX. Initially the issue was me not having local DNS correctly so what I meant was, at the time, I can’t access links when I remote in cause my internet doesn’t understand the LAN IP’s to connect to…. I resolved this in 2 ways, one was like you show changing the ips to host names and having local dns (using Opnsense unbound for local queries) and then also if I were to connect/remote via WireGuard I am “on the lan”.

It was my lack of understanding initially. Thank you for the response!