403 despite inclusion of name and IP range in allowFrom

[SempleSituation]

I am in a swarm and trying to specify the subnet of an overlay network scoped to my swarm dedicatd to socket proxy requests. I hope to encrypt it... but for now am not.

I have read the other discussions involving naming in Swarm, but I think my config should not be impacted by naming due to opening the entire network's range... including the one being reported as prohibited.

I see
`time=2025-05-17T15:04:00.273Z level=WARN msg="error looking up allowed client hostname" hostname=10.0.1.0/24 error="lookup 10.0.1.0/24: no such host"'

and then

time=2025-05-17T15:04:00.274Z level=WARN msg="blocked request" reason="forbidden IP" method=GET URL=/v1.24/version client=10.0.1.4:56240 response=403

despite my config info showing these listed in the allowfrom:

time=2025-05-17T15:03:59.342Z level=INFO msg="configuration info" socketpath=/var/run/docker.sock listenaddress=0.0.0.0:2375 loglevel=DEBUG logjson=false allowfrom=10.0.1

[wollomatic]

Hi @Know1GitzMe,

It looks like socket-proxy doesn't recognize the IP address as an IP address and tries to look it up over DNS. Could you please check if allowfrom is set correctly? The last line you posted shows allowfrom=10.0.1

[SempleSituation]

Sorry the full line is :
time=2025-05-17T15:03:59.342Z level=INFO msg="configuration info" socketpath=/var/run/docker.sock listenaddress=0.0.0.0:2375 loglevel=DEBUG logjson=false allowfrom=10.0.1.0/24,traefik,traefik.socket shutdowngracetime=5

I am just trying to set it up. I can see the error hop to the IP range I specify and one being used .

I think they are configured as described but I feel like it is trying to treat the CIDR as a machine name.

FWIW I also have several other services picking up by name in my swarm and configuring them the same way and specifying the name here does not change the behavior.

[wollomatic]

Thanks for the reply. I think your assumption is correct. The CIDR is treated as an hostname. I'm going to improve this as soon I find the time.

[SempleSituation]

Thanks. There is something else amiss too IMHO. the other two names there are a) the service name, which should resolve per my understanding, and b)the traefik.socket is an alias that I can specify and am using in other situations (monitoring mostly, but not exclusively) . I have not seen any errors when I just use the alias implying iit is picking up the alias specific to the network, which should translate to the IP.

I am still seeing the error. ...

I will poke more.

I think supporting CIDR will make it so docker swarms are easily supported.

[SempleSituation]

Despite the attempts to work around the attempts to resolve CIDR thing, I have made progress but still have the same net results. It is different than I have read on this forum it should behave. Do you have suggestions on how to test DNS resolution within the container itself?

I now have identified what I believe to be a resolvable Service Name and a resolvable Alias on that network. I believe this because I no longer see any errors like this for any of the names I provide

`time=2025-05-17T15:04:00.273Z level=WARN msg="error looking up allowed client hostname" hostname=10.0.1.0/24 error="lookup 10.0.1.0/24: no such host"'

I do however still get the forbidden IP and a 403.

The lack of error implies I am getting a resolution for the names, and the 403 implies that that resolution is not enabling it.

Any suggestions on further troubleshooting?

[SempleSituation]

I saw and tested the test image... which now seems to be resolving the IPs but I woudl expect the error to go away as a result and do not:

 time=2025-05-19T11:17:43.544Z level=INFO msg="starting socket-proxy" version=testing-b13f47149d2c53a62f309df77807717d1b53624c os=linux arch=amd64 runtime=go1.24.3 URL=github.com/wollomatic/socket-proxy
 time=2025-05-19T11:17:43.544Z level=INFO msg="configuration info" socketpath=/var/run/docker.sock listenaddress=0.0.0.0:2375 loglevel=DEBUG logjson=false allowfrom=[10.0.2.0/24] shutdowngracetime=5
 time=2025-05-19T11:17:43.544Z level=INFO msg="watchdog enabled" interval=3600 stoponwatchdog=true
 Request allowlist:
    Method   Regex
    GET      ^/v1\..{1,2}/(version|containers/.*|events.*)$
 time=2025-05-19T11:17:43.544Z level=DEBUG msg="checking socket availability" origin=checkSocketAvailability
 time=2025-05-19T11:17:43.544Z level=INFO msg="socket-proxy running and listening..."
 time=2025-05-19T11:17:43.544Z level=DEBUG msg="watchdog running"
 time=2025-05-19T11:17:43.658Z level=WARN msg="blocked request" reason="forbidden IP" method=GET URL=/v1.24/version client=10.0.1.63:42028 response=403
 time=2025-05-19T11:17:44.072Z level=WARN msg="blocked request" reason="forbidden IP" method=GET URL=/v1.24/version client=10.0.1.63:42040 response=403
 time=2025-05-19T11:17:45.386Z level=WARN msg="blocked request" reason="forbidden IP" method=GET URL=/v1.24/version client=10.0.1.63:50692 response=403
 time=2025-05-19T11:17:47.753Z level=WARN msg="blocked request" reason="forbidden IP" method=GET URL=/v1.24/version client=10.0.1.63:50694 response=403

[SempleSituation]

Thanks for the help. I know you mentioned that you were going to further update the info with stuff to help resolution troubleshooting. ALthough I think I will be able to get this working, a more secure config would be to limit it by service name. I do not think that is working and think I have two names being identified and translated, yet not allowing it to pass. Is this still something you intend to pick at?

thanks again.

[SempleSituation]

@wollomatic, thanks again for your assistance. I think I understand my next limitation and wondering if it would be something you could a) validate as true and b) if I should file a bug under... or feature request... or whatever..

Slight background: I now have 2 of my three services running under the version you enabled CIDR to be specified in the allowed list (thanks again). I would prefer and find it more secure if I could specify the service names here ... and I think this MAY relate to my issue I am having with my third service.

The issue: I do not believe the translating of name to service name to IP is working right for swarm configurations when using Socket Proxy. Other services use the service name as specified in the initiation of the service in the config or task.servicename:port or even specify the protocol via prefix. I also have some that are able to detect services by ports.

When using the socket proxy, the portainer agent seems to be requesting address translation for the hostname, which appears to be the container Id (or first part of a longer ID for the container ID) by default. It is unable to translate this when using.

IRP-Mgmt-Dev_agent-dev.0.xe82sj3d127g@DevProxPi124    | 2025/05/24 01:03:26.491PM INF github.com/portainer/agent/cmd/agent/main.go:94 > agent running on a Swarm cluster node. Running in cluster mode |
IRP-Mgmt-Dev_agent-dev.0.xe82sj3d127g@DevProxPi124    | 2025/05/24 01:03:26.494PM WRN github.com/portainer/agent/cmd/agent/main.go:105 > unable to retrieve agent container IP address, using host flag instead | error="Error response from daemon: No such container: 0f8152d327e9" host_flag=0.0.0.0
IRP-Mgmt-Dev_agent-dev.0.xe82sj3d127g@DevProxPi124    | 2025/05/24 01:03:29.496PM DBG github.com/portainer/agent/net/lookup.go:22 > host=agent-dev ip=10.0.1.201 result=1
IRP-Mgmt-Dev_agent-dev.0.xe82sj3d127g@DevProxPi124    | 2025/05/24 01:03:29.496PM DBG github.com/portainer/agent/serf/cluster.go:79 > advertise_address=0.0.0.0 join_address=["10.0.1.201"]

I am by no stretch a docker expert, but I am wondering if this is because my agents run globally (on all nodes of my swarm) and therefore have access to the socket on each node and the socketproxy running on a single node. Trying it globally did not help, but I assume because there is no awareness of one another to ensure the right proxy is translating for the containers proper socket.

I do not have this issue when connecting directly to the socket. Disabling the config specifying the agent to use the proxied socket and putting it back to native results in expected behavior and fully functional magic. This leads me to believe it is this socket proxy causing me these challenges.

Any thoughts?

[wollomatic]

Hi @Know1GitzMe, I don't have any experience running Swarm, so I'm afraid I can't offer any useful advice on that part.

To dig deeper into the issue, I recommend enabling debug logging in socket-proxy by setting loglevel to debug. This way, you'll be able to see which requests reach the proxy, and you'll get detailed information on why certain requests are blocked or allowed.

[SempleSituation]

Hey @wollomatic, THanks for the advice. It had been enabled and still is but nothing is being blocked. and everything is passing through.

You can see debug logging as recently as 5 days ago.

I think the issue is in the resolution of the IP by container ID where the container is on a different node than the proxy socket.

Is there any opportunity for this service to be run globally (one on each node) and enable a cluster wide container ID resolution rather than just resolution of the containers running local to the socket proxy?