xorinzor

Members
  • Content Count

    77
  • Joined

  • Last visited

Everything posted by xorinzor

  1. Disabling and re-enabling doesn't work for me, I've done that in the past for some other reasons, but this container always has had the same problem. Still unresolved, I don't believe it has anything to do with the custom networks since all of my other containers work with custom networks just fine.
  2. Can you post the output of the commands that have been mentioned in previous replies? Could help establish a baseline. I think everyone here is roughly having the same problem.
  3. I recently got a managed switch and have since been playing around with it, configuring different vlans to make my network more secure. For example, the management interfaces from the router and managed switch can only be accessed via the management vlan. This vlan doesn't have internet access however (by design). If I configure the untagged vlan from unraid to be this management vlan, and have another vlan for docker I'd be able to restrict access to the unraid interface too. If I make the management-vlan the untagged vlan for unraid (ie: it's main eth0 interface)
  4. This is a support topic for Wireguard, I'm afraid your issue lies somewhere else. I don't even think it's related to Unraid, you could create a topic here, or maybe some other forum.
  5. Hm, even those settings are the same as mine. Did you get to test a connection to wireguard via the local network?
  6. What output do you get on the command below? sysctl -a | grep -e "ipv4.ip_" -e "wg0" Don't be suprised, the output is quite a lot
  7. can you connect from the local network to the server? This would further narrow down if it's related to the port forwarding, or something else. EDIT: Can you also put a screenshot of your routing table here? (viewable at /Settings/NetworkSettings)
  8. It's shown as up, but not what service is running (checked using nmap) https://suip.biz/?act=nmap
  9. I've learned over time never to trust output of applications themselves, but just to get it from the source. It can't hurt to check netstat just in case
  10. Interesting, though you can kinda confirm it by checking the output of netstat -atunl | grep 51820
  11. That has been tested already, it's closed. We're just trying to figure out why at this point. Could be completely unrelated to the port forwarding if there's no service listening to the port.
  12. I've had no issues with my intel xeon upon rebooting. Wasn't aware of any issues with intel either. Did you notice my edit? If you checked the port I don't think that's the issue, but it can't hurt to make sure. Let us know what the logging tells you (do another port check to trigger it, as well as try to connect with a wireguard client)
  13. Do you have a static IP configured for your unraid server? Are other ports on your unraid server reachable? What if you enable the logging in your router for that port, does that give you any indications? I use unraid 6.8.2 too, but it works fine for me. EDIT: the blurred local endpoint, just to make sure, isn't set to Unraids local IP, but your external IP. Correct? In which case, did your external IP perhaps change?
  14. Did you confirm the Wireguard service to be running? I've had a few instances where it stopped itself after editing the config. Also, If you check the port using an online tool, is it open? if not, either the port is closed, not forwarded correctly, or nothing is listening on the port (ie: wireguard service disabled).
  15. I've had this on the android app of wireguard happen too, it looks as if it's connected even when it isn't. Maybe your external IP changed? or your server got a different IP address invalidating the port-forwarding? Either way, if your unraid server doesn't show the device as connected, it isn't.
  16. If you just put your USB-stick with the unraid installation in your computer, and access the config file at /boot/config/wg0.cfg you can remove the network from peer allowed IPs again, to see if that fixes it. Not sure why it'd cause your admin panel to become unreachable however, but either way, this way you can still access all config files from unraid. As well as some log files.
  17. Ah, I wasn't aware that it sent the "start" request via the GUI as well. I assumed this was handled by the plugin on the backend. Not sure how the plugin handles these requests, but perhaps it'd be able to send the current state along with any request made, and restore the state to it's original state if needed.
  18. I understand that the networks and containers get new ID's, that's why they're configured using the name of the network (ie: alias) rather then ID. If this however would be the reason of the problem, not just this single container should fail to start every time, but 7 others too. Since I have quite a few containers utilizing these networks, including 2 other containers using the "vpn" network, and starting at boot just fine.
  19. the name "vpn" is just an alias that it resolves within the run command to the ID of the network. If the network were to change after the earlier 2 containers initialized I would run into the problem of those 2 not having a network connection, but they run completely fine. Took me a while to learn these things about docker too, no worries it's why I enjoy working with Unraid so much
  20. I'm running into the issue where; after I edit a peer config (or add a peer) and hit the save/apply button, the wireguard service just stops. This happened both times when I was doing this remotely while connecting via Wireguard to my server. Obviously I'd understand if the service would need to restart to apply the changes, but it never comes back up. I have to manually start it again when I'm back home. When I make changes however, while I'm not connected to Wireguard, the service seems to stay up and running. Is this a known issue?
  21. Unfortunately not I checked the entire syslog file, but this is the only line that stands out (anything from before the reboot has wiped itself since it's loaded in RAM). Apparently the error in the log file is different then the error the WebGUI gives. The WebGUI always says "no such container", but the log file seems to say the network doesn't exist. Jan 27 16:58:13 STORAGE rc.docker: medusa: Error response from daemon: network a2603ce63d6661af7f33861e9092ad3ac52d3ed21bf5774e1632c0f00caa3275 not found Jan 27 16:58:13 STORAGE rc.docker: Error: failed to start containers: medu
  22. There is no container defined as 'vpn', it's a separate docker network that I created, in which I configured a docker container as the gateway. This way, I don't require any order in which to start the containers. Either way, the "gateway container" is ordered to start first, with 2 other containers starting after it, after which the medusa container is launched. So I don't think this is the cause of the problem. I have multiple docker networks configured, none of my other containers show this issue.