-
Notifications
You must be signed in to change notification settings - Fork 104
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot connect to gost because Warp is grabbing incoming traffic #23
Comments
The command you are using in the container is going through gost (you specified |
Like I said when I kill warp-svc process inside container, connection from outside container starts working, so it must be caused by warp catching (and dropping or something like that) this income traffic from whatever else that's not coming through |
I can't think of any reason that caused it. I also run a similar setup myself, where another container accesses the warp inside the container, and it works well:
Here is my configuration for your reference, hoping it will be helpful to you. version: '3.9'
services:
rsshub:
image: diygod/rsshub:chromium-bundled
restart: always
container_name: rsshub
environment:
PROXY_URI: 'http://warp-socks:1080'
depends_on:
- warp-socks
networks:
- exposed
- rsshub
warp-socks:
image: caomingjun/warp:latest
container_name: warp-socks
restart: always
volumes:
- /home/cmj/warp/var:/var/lib/cloudflare-warp
cap_add:
- NET_ADMIN
sysctls:
net.ipv6.conf.all.disable_ipv6: 0
net.ipv4.conf.all.src_valid_mark: 1
networks:
- rsshub
environment:
- WARP_SLEEP=2
- WARP_LICENSE_KEY=***
networks:
rsshub:
name: rsshub
exposed:
name: exposed
external: true where:
|
I too have same issue. The docker port 1080 is reachable only after disconnecting warp-cli. Any other specific settings we need to enable to make this work when
|
What's your docker engine version? Are you using arm device to run this? (For both @vinothsubramanian and @ostrolucky ) I try to reproduce the problem when it opened 3 weeks ago but failed, so I need more information. |
I am running the docker on RaspberryPI 5 - arm64 architecture. Here are the version numbers.
|
I'm also running it on arm64, it's macbook m1 with MacOS and I'm using OrbStack as docker engine
|
So there might be a problem in ARM image. I will look into it ASAP after my vacation. |
@cmj2002 I am thinking that it could be related to configuration in cloudflare tunnel or policies. The forwarding doesn't work only when we are connected to a team. If we don't connect to a team, and connect to warp with default settings everything works fine. |
I found this on stackoverflow: https://stackoverflow.com/questions/77053747/not-able-to-ssh-into-server-after-setting-up-cloudflare-warp So maybe warp is grabbing the response packet of gost, and obviously it cannot reach the host by cloudflare exit node. Try add the host or the container ip which using warp to the exclude list may help? I am not sure of this, grabbing a packet of an existing TCP connection which belongs to another network interface is uncommon. |
@cmj2002 I am yet to try this solution. However I was able to overcome the problem by tweaking the entrypoint.sh to use mdm.xml as explained in the document https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/private-net/warp-connector/#4-install-a-warp-connector. Now I have a working warp-to-warp connector by running warp-docker image. I will raise a pull request shortly. |
@ostrolucky Can you try the latest image with mdm.xml setup and see if you are able to make it to work |
I can't really configure it according the guide, because I'm just an employee that is forced to use cloudfare zero trust. I don't have any admin rights in Cloudfare admin panel, which is what the linked guide for setting up warp connector seem to expect, so not sure how I can get values to put to mdm.xml file. Anyways, since I've created this thread I've discovered https://github.com/rany2/warp.sh with which I can remove official cloudfare-warp application and instead use wireguard tunnel, where it's trivial to configure split tunnels even when official application doesn't allow me so. |
@ostrolucky do you still want this defect to be opened or it can be closed |
I think I would prefer to leave this opened until your fix is merged |
@ostrolucky I successfully reproduced the issue. As a cross-check, please provide the results of running |
warp-cli tunnel dump
ip address
|
From the information you provided, warp-docker use Since you do not have permission to modify the excluded address list, I suggest selecting one from the existing excluded CIDRs to use as the IP range for the docker network, and placing warp-docker under this docker network. Edit: carefully choose the CIDR, it should be a private IP address and not used by your other devices. |
Yep, that seemed to have fixed the issue! But I was thinking that container could adjust the routing table automatically after cloudfare-cli starts so that this cannot happen? Otherwise this can be quite brittle and manual. |
Of course, I will try to automate this process in the next few days. However, the host IP may conflict with the IP addresses of services within the user's organization, making it unavailable; therefore, I will set it as an optional feature that is disabled by default. |
Fixed in 5499865, you can follow the new guidelines in the document to resolve this issue. |
I just discovered that the previously released version still attempts to add rule even when the rules already exist. It doesn't seem to cause any issues, but I still recommend updating to the newly built version. |
I still could not connect the gost exposed service from the host even with
I think and I try to expose a shadowsocks service by gost: any idea? thanks |
Edit: I just noticed that you opened a new issue. I suggest we continue the discussion there. You must have made a mistake. |
Inside container
Outside container
Once I kill warp-svc process inside container, then previous command works (but then it doesn't go through cloudfare network of course).
Do you have any advice what to do in this case?
The text was updated successfully, but these errors were encountered: