Badger not properly forwarding real IP's via Cloudflare

[slimshizn]

Placing this here as further discussion via Discord reveals badger is possibly the issue.

More discussion here https://discord.com/channels/1325658630518865980/1325658631567573029/1378616813298126919

Original Pangolin issues:

fosrl/pangolin#341

fosrl/pangolin#619

[AstralDestiny]

It's because Badger is getting just the request IP and that won't be anything in the preferred X-Forwarded-For and not limited to just cloudflare, If there's any downstream or upstream reverse proxy or webserver it will get the requestIP which might be the proxy itself,

It's due to the code doesn't look for X-Forwarded-For, The code assumes the initial request is the actual visitor ip but X-Forwarded-For includes each server that handles the request.. Been trying locally for it to get the X-Forwarded-For but not very versed in Traefik plugins exactly so stumbling around in the dark right now.

[oschwartz10612]

^^ This is correct its just grabbing the client IP and putting it into the X header.

Badger would need to pull the IP from the Cloudflare provided header and send it along in the X header or something like that. Not sure if there are any security concerns with something like that?

[slimshizn]

^^ This is correct its just grabbing the client IP and putting it into the X header.

Badger would need to pull the IP from the Cloudflare provided header and send it along in the X header or something like that. Not sure if there are any security concerns with something like that?

In order to use both Cloudflare and IP based rules in Pangolin with the otherwise (mostly) default Pangolin setup (Cloudflare IPs added to trustedIPs in traefik) then it has to be adjusted or documentation should be adjusted to say that Cloudflare proxy will work, but IP based rules in Pangolin won't. As long as traefik has it trusted it shouldn't be a security issue.

[slimshizn]

Anyone who's run into this I've went ahead and moved to a traefik plugin instead to block IP's instead of built in rules. https://plugins.traefik.io/plugins/677ac8b5f5aa5a721d14c9df/deny-ip-plugin Works great. Might use a Ipwhitelist plugin as well to get the actual behavior needed.

[jghaanstra]

Could someone tell me where this is on the roadmap. There have been several major Pangolin releases but no love for Badger. To me this is a pretty serious bug rendering the Pangolin rules useless when used in combination with Cloudflare proxy. The fix isn't too complicated. For now I'm using this patched version but I'd like to see the bug fixed in the official plugin.

https://plugins.traefik.io/plugins/68b2afa13971511800dd078c/fossorial-badger-patch-with-i-pv6

[miloschwartz]

Yes we need to work this in. Thanks for the PR. Will look

[overclockit]

Looking at PR #9 I noticed it incorporates a variation of a snippet I originally provided during earlier Pangolin development. At the time, I flagged that it wasn’t production-ready — and in its current form, it still has some critical limitations:

1. CF-Connecting-IP: The logic assumes that if the header is present, it’s trustworthy. However, this should only be accepted if remoteAddr matches a known Cloudflare IP range. My original snippet skipped this validation under the assumption that forwarded headers only included Cloudflare IPs.
2. X-Forwarded-For: The current implementation takes the leftmost IP, which is easily forged. It should instead be parsed right-to-left to identify the first untrusted IP. This was intentionally omitted in my snippet for testing purposes.

I’ve addressed these issues in my personal fork and would be happy to submit a PR however my implementation reverts Pangolin’s clientIp changes for IPv6 support, since requestIp is sufficient when sanitised by Badger (source port is already stripped).

Additionally, I’ve introduced a badger config block in config.yml with cloudflare_ips and trusted_ips. This allows us to verify CF-Connecting-IP against a trusted list and update it as needed.

For X-Forwarded-For, my fork checks CF-Connecting-IP first. If remoteAddr isn’t in the CF range or the header is missing, it parses X-Forwarded-For right-to-left, selecting the first untrusted IP (or final trusted IP if all are trusted). If neither check passes, it falls back to the sanitized remoteAddr.

I've also updated it to implement the refactor from PR #11 and so far it works well in testing.

[praveenroot03]

I see that there is so many PRs and forks of the fix implementation, please look into it and fix this.

[slimshizn]

@praveenroot03 kind of odd that they've ignored this one. Your best bet is using one of the patches since they seemingly don't plan on getting to this. I'm going to close this, but it's not fixed. Someone else can open a new issue.

[yann117]

Does it make sense to close it and request that a new one be raised?

What is the point of having duplicates, except that it causes confusion when trying to get a picture of the product's state?

Milo already mentioned they will look into it (see above history), so we are not in a hurry, there are no SLA, just wait for it patiently (and keep one single report open) ?

[slimshizn]

No, but it also doesn't make sense for it to sit open for as long as it has when PRs exist. Feel free to open a new issue, I've moved on.

[yann117]

but it also doesn't make sense for it to sit open for as long as it has when PRs exist

I guess you are not a dev. On the contrary, it is just one of the basic principles of development and tracking issues.
As long as the PR is not reviewed and merged, the report remains open, indicating that it has not yet been included in the product.

The fact that you are the reporter and "moved on" doesn't make a difference here and is irrelevant.

This one is flagged as an enhancement, and enhancements typically have a longer lifecycle (lower priority) than bugs.