How to forward (inside a container) requests from 0.0.0.0 to 127.0.0.1

Looking for a solution on how to forward the requests from 0.0.0.0:9222 --> 127.0.0.1:9222 inside a container

I am using a docker container with google-chrome-stable installed for running visual testing.

root@6bb8678b29f5:/# google-chrome-stable --version
Google Chrome 114.0.5735.90 

Maybe that's totally justified that google-chrome listens on different addresses when lunching from command line without --headless, but this is preventing me from tracing the tests when writing them. So i need sometimes to turn-of the --headless for debugging purposes.

However, when not using --headless switch, then google-chrome is ignoring the other: --remote-debugging-address=0.0.0.0 switch completely and is starting the DevTools and listens on 127.0.0.1 for connection, by default. Then the test runner fails to connect to the DevTools.

Connecting to 172.22.0.13:9222... failed: Connection refused.

So my thought was to set-up port forwarding for DEV environment, but i can't really get it working

I tried this:

iptables -t nat -A PREROUTING -p tcp --dport 9222 -j DNAT --to-destination 127.0.0.1:9222
iptables -t nat -A POSTROUTING -p tcp -d 0.0.0.0 --dport 9222 -j SNAT --to-source 127.0.0.1

... the request is not immediately refused but still not connecting.

--2023-06-05 13:14:16--  http://172.22.0.13:9222/json/version
Connecting to 172.22.0.13:9222... failed: Connection timed out.
Retrying.

--2023-06-05 13:16:28--  (try: 2)  http://172.22.0.13:9222/json/version
Connecting to 172.22.0.13:9222... failed: Connection timed out.
Retrying.

I was hoping somebody with more experience in this would give me a hint here :)

Thanks !! .

EDIT

I find myself in the situation "2" when chrome-stable is launched inside container without --headless, binding (by default) on 127.0.0.1 address instead of 0.0.0.0

root@c877116fd92a:/# netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:9222          0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.11:35045        0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:5900            0.0.0.0:*               LISTEN     
tcp6       0      0 :::5900                 :::*                    LISTEN     
udp        0      0 127.0.0.11:52971        0.0.0.0:*                          
udp        0      0 224.0.0.251:5353        0.0.0.0:*      

root@0442b7974e78:/# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
root@0442b7974e78:/# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            127.0.0.1            tcp dpt:9222

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
DOCKER_OUTPUT  all  --  0.0.0.0/0            127.0.0.11          

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
DOCKER_POSTROUTING  all  --  0.0.0.0/0            127.0.0.11          

Chain DOCKER_OUTPUT (1 references)
target     prot opt source               destination         
DNAT       tcp  --  0.0.0.0/0            127.0.0.11           tcp dpt:53 to:127.0.0.11:44889
DNAT       udp  --  0.0.0.0/0            127.0.0.11           udp dpt:53 to:127.0.0.11:41070

Chain DOCKER_POSTROUTING (1 references)
target     prot opt source               destination         
SNAT       tcp  --  127.0.0.11           0.0.0.0/0            tcp spt:44889 to::53
SNAT       udp  --  127.0.0.11           0.0.0.0/0            udp spt:41070 to::53

.

.

.

More details on the output, when launching google-chrome

root@6bb8678b29f5:/# /usr/bin/google-chrome-stable --disable-gpu --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222 --no-sandbox --window-size="1920,1080" --disable-dev-shm-usage --no-startup-window --no-first-run --start-maximized --disable-extensions --disable-infobars --user-data-dir=/var/tmp/chrome --log-level=3
[737:737:0605/110543.181892:ERROR:browser_dm_token_storage_linux.cc(100)] Error: /etc/machine-id contains 0 characters (32 were expected).

DevTools listening on ws://127.0.0.1:9222/devtools/browser/3db57e4b-403f-42cc-a385-b4d6b031a753

root@6bb8678b29f5:/# /usr/bin/google-chrome-stable --headless --disable-gpu --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222 --no-sandbox --window-size="1920,1080" --disable-dev-shm-usage --no-startup-window --no-first-run --start-maximized --disable-extensions --disable-infobars --user-data-dir=/var/tmp/chrome --log-level=3 

DevTools listening on ws://0.0.0.0:9222/devtools/browser/7448953b-8da1-4d13-8621-91ebbec8d3f4

Docker containers has some port forarding/NATing that can help automate this.

But if you want to do this the hard way...

The address 0.0.0.0 is not used in general as source address (e.g. DHCP discovery is using it). When a service listens on 0.0.0.0 means it is listaning on all available interfaces, but is actually listening only on the IP addressess configured on the local interfaces.

In Netfilter firewall you can foward/NAT all TCP+UDP traffic with the destination a specific port to another IP:port pair. The incoming traffic that has the destination a local interface, will not go trough (PRE|POST)ROUTING chains/tables, but via INPUT.

For debugging, with sudo iptables -L -nv you can see how many times a Netfilter rule was matched.

Don't be affraid to use 2 tcpdump commands, one for the incoming packet and one for the NAT-ed packet and filter for specifics that you expect (in this case the destination IP:port should chnage).