github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-03-12 09:54:16 -05:00
Code Issues 94 Packages Projects Releases 48 Wiki Activity

X-Forwarded-For: not working with IPv6 #39

New Issue
Closed
opened 2025-11-13 11:48:18 -06:00 by GiteaMirror · 9 comments
GiteaMirror commented 2025-11-13 11:48:18 -06:00
Owner
Copy Link

Originally created by @danhusan on GitHub (Jan 30, 2025).

Originally assigned to: @miloschwartz on GitHub.

It seems X-Forwarded-For and X-Real-Ip shows the IP of badger when resources are accessed by IPv6.
Beta8

wget -4 whoami.mydomain.com
...
...
X-Forwarded-For: 193.193.221.3
X-Real-Ip: 193.193.221.3
...
...

wget -6 whoami.mydomain.com
...
...
X-Forwarded-For: 172.18.0.1
X-Real-Ip: 172.18.0.1
...
...

Originally created by @danhusan on GitHub (Jan 30, 2025). Originally assigned to: @miloschwartz on GitHub. It seems X-Forwarded-For and X-Real-Ip shows the IP of badger when resources are accessed by IPv6. Beta8 wget -4 whoami.mydomain.com ... ... X-Forwarded-For: 193.193.221.3 X-Real-Ip: 193.193.221.3 ... ... wget -6 whoami.mydomain.com ... ... X-Forwarded-For: 172.18.0.1 X-Real-Ip: 172.18.0.1 ... ...
GiteaMirror added the enhancementreverse proxy labels 2025-11-13 11:48:18 -06:00
GiteaMirror commented 2025-11-13 11:48:19 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jan 30, 2025):

Thanks for this. I have not focused on IPv6 support but it is something I want to do more of at some point.

I can look into this - I assume it has to do with some v4-v6 translation stuff. Is this impacting any functionality for you right now?

@oschwartz10612 commented on GitHub (Jan 30, 2025): Thanks for this. I have not focused on IPv6 support but it is something I want to do more of at some point. I can look into this - I assume it has to do with some v4-v6 translation stuff. Is this impacting any functionality for you right now?
GiteaMirror commented 2025-11-13 11:48:19 -06:00
Author
Owner
Copy Link

@danhusan commented on GitHub (Jan 30, 2025):

Does not have any impact for me atm, just trying to document things that can be improved in the future.

@danhusan commented on GitHub (Jan 30, 2025): Does not have any impact for me atm, just trying to document things that can be improved in the future.
GiteaMirror commented 2025-11-13 11:48:19 -06:00
Author
Owner
Copy Link

@zandercodes commented on GitHub (Feb 11, 2025):

To obtain an IPv6 forwarding address, you must be activated in Docker and on your server.

Add this to the Traefik Container in the Docker Compose or you can also configure in the sysctl on the Linux System

sysctls:
  net.ipv6.conf.all.disable_ipv6: 0
  net.ipv6.conf.all.forwarding: 1

Add this to the Docker Daemon config (Example):

{
    "ipv6": true,
    "experimental": true,
    "ip6tables": true,
    "fixed-cidr-v6": "fd07:a:b:c::/64",
    ...
}

IPv6 is an experimental feature in Docker

@zandercodes commented on GitHub (Feb 11, 2025): To obtain an IPv6 forwarding address, you must be activated in Docker and on your server. Add this to the Traefik Container in the Docker Compose or you can also configure in the sysctl on the Linux System ```yaml sysctls: net.ipv6.conf.all.disable_ipv6: 0 net.ipv6.conf.all.forwarding: 1 ``` Add this to the Docker Daemon config (Example): ```json { "ipv6": true, "experimental": true, "ip6tables": true, "fixed-cidr-v6": "fd07:a:b:c::/64", ... } ``` IPv6 is an experimental feature in Docker
GiteaMirror commented 2025-11-13 11:48:20 -06:00
Author
Owner
Copy Link

@4ndreasH commented on GitHub (Jun 18, 2025):

I have a Pangolin system with the plugins Crowdsec, Geoblock, and Umami-feeder (see #914 for details). These three plugins require the real IP address to function correctly. Everything works fine with IPv4, but for IPv6 they seem to be bypassed (probably due to the missing X-Forwarded-For header).

Geoblock:
I have analyzed the log entries from Geoblock over the past five days, and not a single IPv6 address appeared.
(For comparison, I have a server using a Traefik proxy (without Pangolin), fed by HAProxy using proxy-protocoll. On that system, I do see blocked IPv6 addresses every day.)

Crowdsec:
To test crowdsec I added my external IP address to the decision list and tried to access my homepage. With IPv4 I get 403 (forbidden) as expected, but for IPv6 I could access my homepage without any restrictions.

Umami:
Accessing my web pages via IPv6 works, but those accesses are not being recorded by the Umami-feeder.

All these plugins behave the same when VPS-Docker system (with Pangolin/Traefik) uses IPv6 within the Docker network.

I therefore suspect that when accessing over IPv6, the protection mechanisms of Geoblock and Crowdsec are not effective against unwanted traffic. Likewise, my traffic statistics are unable to count those accesses.

If I can do more/better testing, please let me know.

@4ndreasH commented on GitHub (Jun 18, 2025): I have a Pangolin system with the plugins Crowdsec, Geoblock, and Umami-feeder (see #914 for details). These three plugins require the real IP address to function correctly. Everything works fine with IPv4, but for IPv6 they seem to be bypassed (probably due to the missing X-Forwarded-For header). Geoblock: I have analyzed the log entries from Geoblock over the past five days, and not a single IPv6 address appeared. (For comparison, I have a server using a Traefik proxy (without Pangolin), fed by HAProxy using proxy-protocoll. On that system, I do see blocked IPv6 addresses every day.) Crowdsec: To test crowdsec I added my external IP address to the decision list and tried to access my homepage. With IPv4 I get 403 (forbidden) as expected, but for IPv6 I could access my homepage without any restrictions. Umami: Accessing my web pages via IPv6 works, but those accesses are not being recorded by the Umami-feeder. All these plugins behave the same when VPS-Docker system (with Pangolin/Traefik) uses IPv6 within the Docker network. I therefore suspect that when accessing over IPv6, the protection mechanisms of Geoblock and Crowdsec are not effective against unwanted traffic. Likewise, my traffic statistics are unable to count those accesses. If I can do more/better testing, please let me know.
GiteaMirror commented 2025-11-13 11:48:20 -06:00
Author
Owner
Copy Link

@4ndreasH commented on GitHub (Jun 22, 2025):

I made a big mistake while testing with IPv6: I enabled IPv6 for host and docker but my pangolin network was still IPv4 only.
Now with an IPv6 capable "pangolin" network Pangolin is setting x-forwarded-for when I access my sites with IPv6.

To get IPv6 to work I deleted the old pangolin network and created a new one with same config but with IPv6 enabled and declared it external in my pangolin container:

docker network create \
  --driver=bridge \
  --subnet=172.22.0.0/16 \
  --gateway=172.22.0.1 \
  --ipv6 \
  --subnet=fd00:cafe:babe::/64 \
  --gateway=fd00:cafe:babe::1 \
  pangolin

Can someone confirm that I'm doing it right this time?

@4ndreasH commented on GitHub (Jun 22, 2025): I made a big mistake while testing with IPv6: I enabled IPv6 for host and docker but my pangolin network was still IPv4 only. Now with an IPv6 capable "pangolin" network Pangolin is setting x-forwarded-for when I access my sites with IPv6. To get IPv6 to work I deleted the old pangolin network and created a new one with same config but with IPv6 enabled and declared it external in my pangolin container: ``` docker network create \ --driver=bridge \ --subnet=172.22.0.0/16 \ --gateway=172.22.0.1 \ --ipv6 \ --subnet=fd00:cafe:babe::/64 \ --gateway=fd00:cafe:babe::1 \ pangolin ``` Can someone confirm that I'm doing it right this time?
GiteaMirror commented 2025-11-13 11:48:20 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jun 22, 2025):

@4ndreasH seems to make sense to me! Good to know there is an avenue to make this work. Maybe we need IPv6 support on by default in the docker compose?

Anyone aware of any downside to that?

@oschwartz10612 commented on GitHub (Jun 22, 2025): @4ndreasH seems to make sense to me! Good to know there is an avenue to make this work. Maybe we need IPv6 support on by default in the docker compose? Anyone aware of any downside to that?
GiteaMirror commented 2025-11-13 11:48:20 -06:00
Author
Owner
Copy Link

@Xentrice commented on GitHub (Jul 18, 2025):

@oschwartz10612 @miloschwartz
Pushing this due to security concerns - a default installation of pangolin + crowdsec is not secured by crowdsec since the logs which crowdsec depends upon are not usable (if a client connects via IPv6). This also leads to confusion as seen in #1084 as well as skewed statistics.
If you follow the community guide for geoblocking, this will also be circumvented by all IPv6 clients.
If your own client is only IPv4 capable, all tests will succeed, creating a false sense of security.

In my opinion, 2 steps are necessary:

  1. For now, as a temporary solution due to security, ensure IPv4 functionality only to ensure expected behavior of middleware's. IMHO this should be done asap as a minor/hotfix release. At the very least, warn users during crowdsec installation that IPv6 Clients can circumvent the crowdsec protection.
  2. Ask about IPv6 during installation, enabling/disabling IPv6 for the docker network as per the users choice, with full support for IPv6. I am currently unsure if changes in the docker compose are sufficient, or if maybe the docker daemon itself has to be reconfigured for ip forwarding to work. I personally would advise against IPv6 enabled by default.

If you want, I can take responsibility for this issue. I could compose a PR for step 1. in the next two days, and a PR for step 2. in the upcoming week. This might just be a small configuration change.

I'd be happy to hear about your stance on this.

@Xentrice commented on GitHub (Jul 18, 2025): @oschwartz10612 @miloschwartz Pushing this due to security concerns - a default installation of pangolin + crowdsec is not secured by crowdsec since the logs which crowdsec depends upon are not usable (if a client connects via IPv6). This also leads to confusion as seen in #1084 as well as skewed statistics. If you follow the community guide for geoblocking, this will also be circumvented by all IPv6 clients. If your own client is only IPv4 capable, all tests will succeed, creating a false sense of security. In my opinion, 2 steps are necessary: 1. For now, as a temporary solution due to security, ensure IPv4 functionality only to ensure expected behavior of middleware's. IMHO this should be done asap as a minor/hotfix release. At the very least, warn users during crowdsec installation that IPv6 Clients can circumvent the crowdsec protection. 2. Ask about IPv6 during installation, enabling/disabling IPv6 for the docker network as per the users choice, with full support for IPv6. I am currently unsure if changes in the docker compose are sufficient, or if maybe the docker daemon itself has to be reconfigured for ip forwarding to work. I personally would advise against IPv6 enabled by default. If you want, I can take responsibility for this issue. I could compose a PR for step 1. in the next two days, and a PR for step 2. in the upcoming week. This might just be a small configuration change. I'd be happy to hear about your stance on this.
GiteaMirror commented 2025-11-13 11:48:20 -06:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jul 18, 2025):

@Xentrice thanks for bringing this up. I agree its a security issue and we should address ASAP!

If you are available to make these changes that would be incredible! I think your 2 step process makes a lot of sense. As long as disabling v6 does not break user's installs that would be fine.

Feel free to open a draft PR and ping me as much as needed haha.

@oschwartz10612 commented on GitHub (Jul 18, 2025): @Xentrice thanks for bringing this up. I agree its a security issue and we should address ASAP! If you are available to make these changes that would be incredible! I think your 2 step process makes a lot of sense. As long as disabling v6 does not break user's installs that would be fine. Feel free to open a draft PR and ping me as much as needed haha.
GiteaMirror commented 2025-11-13 11:48:21 -06:00
Author
Owner
Copy Link

@Kornelius777 commented on GitHub (Jul 19, 2025):

I'm glad you brought this up!
Just disabled IPv6 at my docker installation, removed the IPv6 resolution from my DNS server.
Looking forward to having a solution soon!

Thank you for your gorgeous product!

@Kornelius777 commented on GitHub (Jul 19, 2025): I'm glad you brought this up! Just disabled IPv6 at my docker installation, removed the IPv6 resolution from my DNS server. Looking forward to having a solution soon! Thank you for your gorgeous product!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
No Label enhancement reverse proxy
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#39
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?