How can I achieve a remote connection to a client from a container, without using network_mode: host? #27275

Onotot · 2025-10-11T21:34:17Z

Onotot
Oct 11, 2025

Hello. I'm encountering an issue with FRP(Fast Reverse Proxy) for remote router connections. I can only establish a connection when the container's network mode is set to host. This is not a suitable configuration for me, as I need to utilize a custom network.

[Container]
ContainerName=frp
Image=ghcr.io/fatedier/frps:v0.65.0
PublishPort=7000:7000
PublishPort=127.0.0.1:10022:10022
Network=host
Volume=/home/user/frps/frps.toml:/etc/frp/frps.toml
Exec=-c /etc/frp/frps.toml
AutoUpdate=registry
[Unit]
Description=FRPS Container
# After=frps.socket
# Wants=frps.socket

[Service]
Restart=always

[Install]
WantedBy=default.target

FRP Server Config:

bindPort=7000
proxyBindAddr="127.0.0.1"

FRP Client Config:

config init
	option stdout '1'
	option stderr '1'
	option user 'root'
	option group 'root'
	option respawn '1'

config conf 'common'
	option server_addr 'remote_addr'
	option server_port '7000'
	option log_level 'trace'
	option token 'token'
	option tls_enable 'true'

config conf 'ssh'
	option type 'tcp'
	option local_ip '192.168.1.1'
	option local_port '22'
	option remote_port '10022'
	option name 'ssh'

The logs indicate a successful connection between the client and server:

client login info: ip [router_ip]
16:03.156 [I] [proxy/tcp.go:82] [dbd0b998412b8f79] [ssh] tcp proxy listen port [10022]
16:03.157 [I] [server/control.go:399] [dbd0b998412b8f79] new proxy [ssh] type [tcp] success

Upon successful connection, I enter the command ssh -p 10022 root@127.0.0.1 and gain access to the router.

But this is only functional when using network_mode: host. When I switch to a custom network or different modes, like network: pasta, SSH fails to connect.

Connection closed by 127.0.0.1 port 10022
# or
Connection reset by 127.0.0.1 port 10022

My initial thought was that the problem lay with the client's IP, that it was being swapped out for Podman's internal IP. But upon checking, this wasn't the case.

Is it possible to solve this task while preserving the client's IP and using a custom network, or not? Activation via socket for frp is not working.

Answered by eriksjolund

Oct 13, 2025

bindPort=7000
proxyBindAddr="127.0.0.1"

Just a wild guess, does it work if you use

proxyBindAddr="0.0.0.0"

?

The reasoning is that 127.0.0.1 inside the container is not the same as 127.0.0.1 on the host when using rootless podman with pasta.

Here is an example:

Test 1: using `--bind 127.0.0.1` fails

$ podman run --rm -p 127.0.0.1:8000:8000 -d --name test --replace docker.io/library/python python3 -m http.server --bind 127.0.0.1 8000
f453eeccf0aa0d4e39c77ed3b8851ee85968844efef461c662e05bc133cbeda9
$ curl 127.0.0.1:8000
curl: (56) Recv failure: Connection reset by peer

Test 2: using `--bind 0.0.0.0` succeeds

$ podman run --rm -p 127.0.0.1:8000:8000 -d --name test --replace docker.io/library…

View full answer

baude · 2025-10-13T15:47:41Z

baude
Oct 13, 2025
Maintainer

i assume you are doing this unprivileged in which has subtle differences in networking. so first question, do this work for a privileged user?

1 reply

Onotot Oct 13, 2025
Author

@baude I'd considered that, but no, root access didn't help.

eriksjolund · 2025-10-13T17:58:37Z

eriksjolund
Oct 13, 2025

bindPort=7000
proxyBindAddr="127.0.0.1"

Just a wild guess, does it work if you use

proxyBindAddr="0.0.0.0"

?

The reasoning is that 127.0.0.1 inside the container is not the same as 127.0.0.1 on the host when using rootless podman with pasta.

Here is an example:

Test 1: using `--bind 127.0.0.1` fails

$ podman run --rm -p 127.0.0.1:8000:8000 -d --name test --replace docker.io/library/python python3 -m http.server --bind 127.0.0.1 8000
f453eeccf0aa0d4e39c77ed3b8851ee85968844efef461c662e05bc133cbeda9
$ curl 127.0.0.1:8000
curl: (56) Recv failure: Connection reset by peer

Test 2: using `--bind 0.0.0.0` succeeds

$ podman run --rm -p 127.0.0.1:8000:8000 -d --name test --replace docker.io/library/python python3 -m http.server --bind 0.0.0.0  8000
WARN[0010] StopSignal SIGTERM failed to stop container test in 10 seconds, resorting to SIGKILL
76c9542e2b9a7c977f8c08d35bc169c75656c70836471ef182605911618516d2
$ curl -s 127.0.0.1:8000 | head -1
<!DOCTYPE HTML>

3 replies

Onotot Oct 13, 2025
Author

@eriksjolund

Just a wild guess, does it work if you use

You guessed right! It also worked with the custom network, even without Network=pasta and without keeping the client's IP address.

But I don't quite understand why. When I enter the command ssh -p 10022 root@127.0.0.1 on the host, do I not get into the container, or do I get in, but not to 127.0.0.1?

eriksjolund Oct 14, 2025

You guessed right!

Glad to hear!

It also worked with the custom network, even without Network=pasta and without keeping the client's IP address.

Pasta is also handling the network traffic when you are using custom network.

But I don't quite understand why. When I enter the command ssh -p 10022 root@127.0.0.1 on the host, do I not get into the container, or do I get in, but not to 127.0.0.1?

The process on the host and the process in the container are running in different network namespaces.

127.0.0.1 on the host and 127.0.0.1 in the container will thus be different. There is a diagram showing how custom networks are set up with podman:

#22943 (comment)

Onotot Oct 15, 2025
Author

@eriksjolund Thanks for your help, I didn't know what else to try :)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

How can I achieve a remote connection to a client from a container, without using network_mode: host? #27275

Uh oh!

{{title}}

Uh oh!

Replies: 2 comments 4 replies

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

How can I achieve a remote connection to a client from a container, without using network_mode: host? #27275

Uh oh!

Onotot Oct 11, 2025

Test 1: using --bind 127.0.0.1 fails

Test 2: using --bind 0.0.0.0 succeeds

Replies: 2 comments · 4 replies

Uh oh!

baude Oct 13, 2025 Maintainer

Uh oh!

Onotot Oct 13, 2025 Author

Uh oh!

Uh oh!

eriksjolund Oct 13, 2025

Test 1: using --bind 127.0.0.1 fails

Test 2: using --bind 0.0.0.0 succeeds

Uh oh!

Onotot Oct 13, 2025 Author

Uh oh!

eriksjolund Oct 14, 2025

Uh oh!

Onotot Oct 15, 2025 Author

Onotot
Oct 11, 2025

Test 1: using `--bind 127.0.0.1` fails

Test 2: using `--bind 0.0.0.0` succeeds

Replies: 2 comments 4 replies

baude
Oct 13, 2025
Maintainer

Onotot Oct 13, 2025
Author

eriksjolund
Oct 13, 2025

Test 1: using `--bind 127.0.0.1` fails

Test 2: using `--bind 0.0.0.0` succeeds

Onotot Oct 13, 2025
Author

Onotot Oct 15, 2025
Author