hdebeuf

Members
  • Posts

    3
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

hdebeuf's Achievements

Noob

Noob (1/14)

0

Reputation

  1. Thank you for the quick reply. The network type in Unraid is defined as br0, but in macvlan mode the container is only aware of eth0 where this bridge is attached. Some differences I see when digging into the different container setups are the iptables INPUT chain values: Macvlan: Chain INPUT (policy ACCEPT) target prot opt source destination AS0_ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED AS0_ACCEPT all -- anywhere anywhere AS0_IN_PRE all -- anywhere anywhere mark match 0x2000000/0x2000000 AS0_ACCEPT udp -- anywhere d05504430e62 state NEW udp dpt:1194 AS0_WEBACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED AS0_WEBACCEPT tcp -- anywhere d05504430e62 state NEW tcp dpt:943 Host: Chain INPUT (policy ACCEPT) target prot opt source destination AS0_ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED AS0_ACCEPT all -- anywhere anywhere AS0_IN_PRE all -- anywhere anywhere mark match 0x2000000/0x2000000 AS0_ACCEPT udp -- anywhere 192.168.0.100 state NEW udp dpt:1194 AS0_WEBACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED AS0_WEBACCEPT tcp -- anywhere 192.168.0.100 state NEW tcp dpt:943 LIBVIRT_INP all -- anywhere anywhere Bridge: Chain INPUT (policy ACCEPT) target prot opt source destination AS0_ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED AS0_ACCEPT all -- anywhere anywhere AS0_IN_PRE all -- anywhere anywhere mark match 0x2000000/0x2000000 AS0_ACCEPT udp -- anywhere ecc3ad434c70 state NEW udp dpt:1194 AS0_WEBACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED AS0_WEBACCEPT tcp -- anywhere ecc3ad434c70 state NEW tcp dpt:943 I haven't got advanced knowledge in Unraid, but the behavior of the container in macvlan mode seems weird to me as it should relay on actual environment networking and not Docker container ids. By trying to force add IP based rules, unfortunately the destination is still translated to an id (container id I may presume): iptables -A INPUT -d 192.168.0.97 -i eth0 -m state --state NEW -p udp --dport 1194 -j AS0_ACCEPT Hope this helps with the debugging and enabling the build of an updated image. Thank you. Best regards, hdebeuf
  2. Hi there, After looking to my similar issue through this long thread, no other user has encountered the same issue as me. Environment: Unraid 6.7.0 2 distinct ISPs The main network with multiple VLAN interfaces The secondary network on one interface Unraid GUI is accessible through the 2 separate networks and VLANS with different IPs Image version: linuxserver/openvpn-as:2.6.1-ls11 (latest gives the same issues, but regarding previous comments, this one seems a better option) Goal: Add an OpenVPN container enabling me to access the secondary network through br1 being not the default interface Unraid choses. Setup trials: Using docker MCVLAN option in order to choose br1 interface and define a static IP to the container. GUI is accessible as expected on the defined IP interface eth0 is the listening interface with the defined IP The container has access to the correct default gateway and machines in this network OpenVPN Server seems not being able to start Error: service failed to start due to unresolved dependencies: set(['user']) service failed to start due to unresolved dependencies: set(['iptables_openvpn']) Service deferred error: IPTablesServiceBase: failed to run iptables-restore [status=2]: ["iptables-restore v1.6.0: Port `0' not valid", '', 'Error occurred at line: 88', "Try `iptables-restore -h' or 'iptables-restore --help' for more information."]: internet/defer:323,sagent/ipts:122,sagent/ipts:49,util/mycprof:11,<string>:1,sagent/sagent_entry:14,sagent/sagent_entry:11,util/daemon:28,util/daemon:69,application/app:423,scripts/_twistd_unix:202,application/app:445,application/app:348,internet/base:1166,internet/base:1178,internet/epollreactor:194,python/log:85,python/log:70,python/context:59,python/context:37,internet/epollreactor:223,internet/posixbase:191,internet/process:260,internet/process:762,internet/process:775,internet/_baseprocess:60,svc/pp:117,svc/svcnotify:32,internet/defer:238,internet/defer:307,internet/defer:323,sagent/ipts:122,sagent/ipts:49,util/error:61,util/error:44 service failed to start due to unresolved dependencies: set(['user', 'iptables_live', 'iptables_openvpn']) service failed to start due to unresolved dependencies: set(['iptables_live', 'iptables_openvpn']) Using Host mode in order to have access to all interfaces from inside OpenVPN GUI is accessible as expected on the Unraid IP interface br1 is the listening interface with the Unraid IP from the secondary network The container has access to all linked default gateways, but not with other machines in the network OpenVPN starts without errors Initiating a VPN tunnel from inside the network works correctly Initiating a VPN tunnel from outside the network throws a timeout error (port-forwarding is correctly setup) Using Bridge mode in order to relay on Docker networking GUI is accessible as expected on the Unraid IP interface eth0 is the listening interface with the docker IP The container doesn't seem to have any internet access OpenVPN starts without errors Initiating a VPN tunnel from inside the network works correctly Initiating a VPN tunnel from outside the network throws a timeout error (port-forwarding is correctly setup) Using Host mode and configure OpenVPN to work with the main network GUI is accessible as expected on the Unraid IP interface br0 is the listening interface with the Unraid IP from the main network The container has access to all linked default gateways, but not with other machines in the network OpenVPN starts without errors Initiating a VPN tunnel from inside the network works correctly Initiating a VPN tunnel from outside the network works correctly I've used previously OpenVPN-AS in a regular docker environment without any issues, but the way Unraid manages networking seems to make a constraint in this setup. So the only way I may have to make this use case working seems to be 1 with the Error resolved. Is anyone familiar with this issue? Thank you. Best regards, hdebeuf
  3. Switch in Advanced view and try to add --user=root in the Extra Parameters field. This is required according to Elastic documentation here.