Skip to content
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

I seem to result connected to the vpn, but no response from the server. #99

Open
alexanderi96 opened this issue Feb 4, 2023 · 2 comments

Comments

@alexanderi96
Copy link

Basically I setup the container as described in the guide, edited the docker compose adding the pihole ports and added a password for it. So this is the situation on portainer:

image

I connected my phone via the wireguard app and edited the configuration in order to do the split tunnel, but connecting to the admin panel of pihole or just navigating is just not possible.

The container runs on a pi4, with ufw (i allowed the vpn port) and opened the port from my router. Do you have any other suggestions on how to fix this problem?

@pawl
Copy link

pawl commented Dec 23, 2023

Are you also seeing errors like this in journalctl -f of your host?:

Dec 23 20:59:01 instance-1 kernel: IPv4: martian source 172.20.0.2 from <my real IP>, on dev eth0
Dec 23 20:59:01 instance-1 kernel: ll header: 00000000: <redacted>
Dec 23 20:59:06 instance-1 kernel: IPv4: martian source 172.20.0.2 from <my real IP>, on dev eth0
Dec 23 20:59:06 instance-1 kernel: ll header: 00000000: <redacted>

I solved a similar issue by adding INTERNAL_SUBNET= to the .env file as suggested here: #112 (comment)

Edit: Using INTERNAL_SUBNET= just defaults it to 10.13.13.0, and the rest of your configuration needs to account for that. You use ALLOWED_IPS=10.2.0.0 to access the wireguard UI, which is on a separate private network.

@pawl
Copy link

pawl commented Dec 23, 2023

Also need to make sure you check and make sure your client is on the same network as the server. In my case I had a static IP on my client that was connecting, but it wasn't in the same subnet as what INTERNAL_SUBNET was defaulting to. It seems reasonable to set INTERNAL_SUBNET to something like INTERNAL_SUBNET=10.2.0.0 if you're going to be setting any static IPs.

Edit: It's probably not a good idea to use INTERNAL_SUBNET=10.2.0.0 because it could cause IP conflicts with stuff on that private network. INTERNAL_SUBNET defaults to 10.13.13.0, a separate network, which is probably best.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants