Help - network change has stopped container from working

[beneix]

I made some changes to my network and I have managed to stop the container from working. I have spent a couple of hours trying to trace the problem, but without success. If anyone can suggest things to try, I would be most grateful.

The container has been running without problems on my NAS for a long time. What I changed was:

1. The NAS and all other clients were moved from 192.168.1.0/24 to 192.168.2.0/24.
2. An OpenWRT router was made the main router that hands out IPs and handles the firewall.
3. A Pi-Hole is capturing all DNS traffic

To accommodate these changes for the haugene container, I made sure to update LOCAL_NETWORK to the new subnet. On the old router, I had forwarded port 9091 to the NAS, but now thinking about it I am wondering why this would be needed if the traffic is going in an OVPN tunnel – surely then, no traffic would be going over 9091?

Testing on another client connected to the same firewall zone as the NAS, qbittorrent is working fine (without any port forwards on the router).

Questions:

1. Which ports need to be enabled in the container and opened in the router firewall? Since I see the error message "sitnl_send: rtnl: generic error (-101): Network unreachable" in the log (below), I tried port forwarding 1198 in the router and putting "-p 1198:1198" in the docker command (in addition to "-p 9091:9091"), but it did not make any difference.
2. Do I need to put an exception in iptables so that the traffic from the container does not use the Pi-Hole as DNS server but rather my ISP's DNS servers (or Google's)? How would I do that? (I am just starting to learn iptables.)
3. What else could have gone wrong with my network changes?

This is the console output from my container:

STARTING TRANSMISSION
Provider PIA has a script for automatic port forwarding. Will run it now.
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true
Transmission startup script complete.
2021-10-30 17:49:14 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun0, therefore the route installation may fail or may not work as expected.
2021-10-30 17:49:14 add_route_ipv6(2000::/3 -> :: metric -1) dev tun0
2021-10-30 17:49:14 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-10-30 17:49:14 Initialization Sequence Completed
Running functions for token based port fowarding
Reserved Port: 58964  Sat Oct 30 17:49:21 CEST 2021
transmission auth required
waiting for transmission to become responsive
transmission became responsive
     6     0%   10.11 MB  Unknown      0.0     0.0    0.0  Stopped      ubuntu-21.04-desktop-amd64.iso
Sum:            270.9 MB               0.0     0.0
setting transmission port to 58964
localhost:9091/transmission/rpc/ responded: "success"
Checking port...
Port is open: Yes
#######################
        SUCCESS        
#######################
Port: 58964
Expiration Sat Jan  1 03:48:02 CET 2022
#######################
Entering infinite while loop
Every 15 minutes, check port status
Starting container with revision: 47f32618629b0144f492b9116f77978d4c991712
Creating TUN device /dev/net/tun
Using OpenVPN provider: PIA
Provider PIA has a custom setup script, executing it
Downloading OpenVPN config bundle openvpn into temporary file /tmp/tmp.hEndPA
Extract OpenVPN config bundle into PIA directory /etc/openvpn/pia
Starting OpenVPN using config france.ovpn
Modifying /etc/openvpn/pia/france.ovpn for best behaviour in this container
Setting OpenVPN credentials...
adding route to local network 192.168.2.0/24 via 10.0.3.1 dev eth0
2021-10-30 17:49:47 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'aes-128-cbc' to --data-ciphers or change --cipher 'aes-128-cbc' to --data-ciphers-fallback 'aes-128-cbc' to silence this warning.
2021-10-30 17:49:47 OpenVPN 2.5.2 x86_64-alpine-linux-musl [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on May  4 2021
2021-10-30 17:49:47 library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10
2021-10-30 17:49:47 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2021-10-30 17:49:47 CRL: loaded 1 CRLs from file -----BEGIN X509 CRL-----
<text redacted, my comment>
-----END X509 CRL-----

2021-10-30 17:49:47 TCP/UDP: Preserving recently used remote address: [AF_INET]191.101.31.41:1198
2021-10-30 17:49:47 UDP link local: (not bound)
2021-10-30 17:49:47 UDP link remote: [AF_INET]191.101.31.41:1198
2021-10-30 17:49:47 [paris412] Peer Connection Initiated with [AF_INET]191.101.31.41:1198
2021-10-30 17:49:47 sitnl_send: rtnl: generic error (-101): Network unreachable
2021-10-30 17:49:47 TUN/TAP device tun0 opened
2021-10-30 17:49:47 /sbin/ip link set dev tun0 up mtu 1500
2021-10-30 17:49:47 /sbin/ip link set dev tun0 up
2021-10-30 17:49:47 /sbin/ip addr add dev tun0 10.1.112.101/24
2021-10-30 17:49:47 /etc/openvpn/tunnelUp.sh tun0 1500 1553 10.1.112.101 255.255.255.0 init
Up script executed with tun0 1500 1553 10.1.112.101 255.255.255.0 init
Updating TRANSMISSION_BIND_ADDRESS_IPV4 to the ip of tun0 : 10.1.112.101
Updating Transmission settings.json with values from env variables
Using existing settings.json for Transmission /data/transmission-home/settings.json
Overriding bind-address-ipv4 because TRANSMISSION_BIND_ADDRESS_IPV4 is set to 10.1.112.101
Overriding blocklist-enabled because TRANSMISSION_BLOCKLIST_ENABLED is set to true
Overriding blocklist-url because TRANSMISSION_BLOCKLIST_URL is set to https://github.com/sahsu/transmission-blocklist/releases/download/1.0.0/blocklist.gz
Overriding download-dir because TRANSMISSION_DOWNLOAD_DIR is set to /data/completed
Overriding incomplete-dir because TRANSMISSION_INCOMPLETE_DIR is set to /data/incomplete
Overriding rpc-authentication-required because TRANSMISSION_RPC_AUTHENTICATION_REQUIRED is set to true
Overriding rpc-password because TRANSMISSION_RPC_PASSWORD is set to [REDACTED]
Overriding rpc-port because TRANSMISSION_RPC_PORT is set to 9091
Overriding rpc-username because TRANSMISSION_RPC_USERNAME is set to transmission
Overriding watch-dir because TRANSMISSION_WATCH_DIR is set to /data/watch
sed'ing True to true

-------------------------------------
Transmission will run as
-------------------------------------
User name:   root
User uid:    0
User gid:    0
-------------------------------------

STARTING TRANSMISSION
Provider PIA has a script for automatic port forwarding. Will run it now.
If you want to disable this, set environment variable DISABLE_PORT_UPDATER=true
Transmission startup script complete.
2021-10-30 17:49:47 WARNING: OpenVPN was configured to add an IPv6 route. However, no IPv6 has been configured for tun0, therefore the route installation may fail or may not work as expected.
2021-10-30 17:49:47 add_route_ipv6(2000::/3 -> :: metric -1) dev tun0
2021-10-30 17:49:47 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2021-10-30 17:49:47 Initialization Sequence Completed
Running functions for token based port fowarding
Reserved Port: 21954  Sat Oct 30 17:49:54 CEST 2021
                                                                                                   transmission auth required
waiting for transmission to become responsive
transmission became responsive
 6     0%   10.11 MB  Unknown      0.0     0.0    0.0  Stopped      ubuntu-21.04-desktop-amd64.iso
                                                                 Sum:            270.9 MB               0.0     0.0
setting transmission port to 21954
localhost:9091/transmission/rpc/ responded: "success"
Checking port...
Port is open: Yes
#######################
SUCCESS        
#######################
Port: 21954
Expiration Sat Jan  1 03:48:35 CET 2022
#######################
Entering infinite while loop
Every 15 minutes, check port status

[pkishino]

No ports on the router need to be opened.. it’s all through the vpn tunnel. DNS is fine, based on your logs it looks fine, what is the problem?
Port check succeeds, vpn tunnel is successfully up etc..

[beneix]

SOLVED: The problem had nothing to do with haugene. My QNAP NAS has an annoying feature where they have a daemon that kills other OpenVPN processes than those created by the system's own OpenVPN app. I had resolved this a year ago by commenting out the correct line in /etc/daemon_mgr.conf, but a recent firmware update of the NAS that happened to coincide with my network changes had undone my change to /etc/daemon_mgr.conf. After again taking that line out of the /etc/daemon_mgr.conf file, doing "killall daemon_mgr" and starting it again with /sbin/daemon_mgr, everything is working again.

[pkishino]

ah yes, didn't see you mention Qnap in the first post..