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

trusted_proxies does not accept IPv6 #3870

Closed
fadenb opened this issue May 29, 2017 · 2 comments
Closed

trusted_proxies does not accept IPv6 #3870

fadenb opened this issue May 29, 2017 · 2 comments
Assignees
Milestone

Comments

@fadenb
Copy link

@fadenb fadenb commented May 29, 2017

When setting the trusted_proxies setting Graylog does not accept an IPv4 in CIDR notation as indicated in the comment in the example graylog config: https://github.com/Graylog2/graylog2-server/blob/master/misc/graylog.conf#L124-L126

Expected Behavior

  • Define trusted_proxies with IPv4 and IPv6 both in CIDR notation
  • Use Graylog API without encountering java.lang.IllegalArgumentException: This IPv6 address cannot be used in IPv4 context error

Current Behavior

The following trusted_proxies settings can be used to reproduce the error:

  • trusted_proxies = 10.93.0.1/16, 2a00:cb0:8002:0:0:0:0:0/48
  • trusted_proxies = 10.93.0.0/16
  • trusted_proxies = 10.93.0.0/32
  • trusted_proxies = 127.0.0.1/32, 0:0:0:0:0:0:0:1/128 (copied from comment)
May 29 13:00:00 graylog graylogctl[22102]: 2017-05-29 13:00:00,734 ERROR: org.graylog2.shared.rest.exceptionmappers.AnyExceptionClassMapper - Unhandled exception in REST resource
May 29 13:00:00 graylog graylogctl[22102]: java.lang.IllegalArgumentException: This IPv6 address cannot be used in IPv4 context
May 29 13:00:00 graylog graylogctl[22102]:         at org.jboss.netty.handler.ipfilter.CIDR.getIpV4FromIpV6(CIDR.java:213) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.jboss.netty.handler.ipfilter.CIDR4.ipv4AddressToInt(CIDR4.java:144) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.jboss.netty.handler.ipfilter.CIDR4.contains(CIDR4.java:100) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.jboss.netty.handler.ipfilter.IpSubnet.contains(IpSubnet.java:119) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.jboss.netty.handler.ipfilter.IpSubnet.contains(IpSubnet.java:104) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.graylog2.rest.RestTools.getRemoteAddrFromRequest(RestTools.java:70) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.graylog2.shared.security.ShiroSecurityContextFilter.filter(ShiroSecurityContextFilter.java:68) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:132) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.server.ContainerFilteringStage.apply(ContainerFilteringStage.java:68) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.process.internal.Stages.process(Stages.java:197) ~[graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:318) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.jersey.grizzly2.httpserver.GrizzlyHttpContainer.service(GrizzlyHttpContainer.java:384) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at org.glassfish.grizzly.http.server.HttpHandler$1.run(HttpHandler.java:224) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:176) [graylog.jar:?]
May 29 13:00:00 graylog graylogctl[22102]:         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_131]
May 29 13:00:00 graylog graylogctl[22102]:         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_131]
May 29 13:00:00 graylog graylogctl[22102]:         at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]

Steps to Reproduce (for bugs)

  1. Configure trusted_proxies = 10.93.0.0/16, 2a00:cb0:8002:0:0:0:0:0/48
  2. Access Graylog API by opening the graylog webinterface
  3. Get a log full of errors

Context

Users are shown with the IPv6 address of the reverse proxy in front of the Graylog cluster instead of the address provided by the X-Forwarded-For header

Your Environment

  • Graylog Version: 2.3.0-alpha.2
  • Elasticsearch Version: 5.4.0
  • MongoDB Version: 3.2.9
  • Operating System: NixOS 17.09.git.5495d07 (Hummingbird)
@jalogisch
Copy link
Contributor

@jalogisch jalogisch commented May 30, 2017

Hej @fadenb

thank you for that finding - did your Graylog know that it should listen to IPv4 and IPv6. Our Documentation is missing important information on that topic. You might find the time to contribute to the documentation about dual stack setups.

Yes, we will look into this issue.

Loading

@jalogisch jalogisch changed the title trusted_proxies does not accept IPv4 trusted_proxies does not accept IPv6 May 30, 2017
@fadenb
Copy link
Author

@fadenb fadenb commented May 31, 2017

did your Graylog know that it should listen to IPv4 and IPv6.

Graylog is listening on tcp6 (default behaviour, no special config) which is accessible via IPv4 as well as IPv6.

tcp6       0      0 :::12900                :::*                    LISTEN      243        80897      6501/java           
tcp6       0      0 :::9000                 :::*                    LISTEN      243        80899      6501/java           

Our reverse proxy in front of Graylog is also dualstack. This is the reason I tried to trust its IPv4 as well as IPv6 address (for some requests it is using IPv6 for others it is using IPv4)

You might find the time to contribute to the documentation about dual stack setups.

I actually am using Graylog dualstacked for quite some time and never experienced any issues before. I believe (besides from this issue) there is no special configuration required at all.

Loading

@joschi joschi self-assigned this Jun 21, 2017
@joschi joschi added this to the 2.3.0 milestone Jun 21, 2017
joschi pushed a commit that referenced this issue Jun 21, 2017
The Netty 3.6 `IpSubnet` class (http://netty.io/3.6/api/org/jboss/netty/handler/ipfilter/IpSubnet.html)
doesn't allow checking if an IPv6 address is part of an IPv4 subnet and throws an exception instead.

In order to allow users to run a dualstack environment (IPv4 and IPv6 at the same time), this changeset
introduces a custom `IpSubnet` implementation which can handle these cases properly.

The new `IpSubnet` implementation was initially copied from https://github.com/edazdarevic/CIDRUtils
but modified for performance and compatibility with the Netty 3.6 `IpSubnet` class.

As the original source file is licensed under MIT, the IpSubnet source file contains a GPLv3 *and* an MIT
license header (https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility).

Fixes #3870
joschi pushed a commit that referenced this issue Jun 21, 2017
The Netty 3.6 `IpSubnet` class (http://netty.io/3.6/api/org/jboss/netty/handler/ipfilter/IpSubnet.html)
doesn't allow checking if an IPv6 address is part of an IPv4 subnet and throws an exception instead.

In order to allow users to run a dualstack environment (IPv4 and IPv6 at the same time), this changeset
introduces a custom `IpSubnet` implementation which can handle these cases properly.

The new `IpSubnet` implementation was initially copied from https://github.com/edazdarevic/CIDRUtils
but modified for performance and compatibility with the Netty 3.6 `IpSubnet` class.

As the original source file is licensed under MIT, the IpSubnet source file contains a GPLv3 *and* an MIT
license header (https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility).

Fixes #3870
@bernd bernd closed this in #3926 Jun 28, 2017
@ghost ghost removed the in progress label Jun 28, 2017
bernd added a commit that referenced this issue Jun 28, 2017
The Netty 3.6 `IpSubnet` class (http://netty.io/3.6/api/org/jboss/netty/handler/ipfilter/IpSubnet.html)
doesn't allow checking if an IPv6 address is part of an IPv4 subnet and throws an exception instead.

In order to allow users to run a dualstack environment (IPv4 and IPv6 at the same time), this changeset
introduces a custom `IpSubnet` implementation which can handle these cases properly.

The new `IpSubnet` implementation was initially copied from https://github.com/edazdarevic/CIDRUtils
but modified for performance and compatibility with the Netty 3.6 `IpSubnet` class.

As the original source file is licensed under MIT, the IpSubnet source file contains a GPLv3 *and* an MIT
license header (https://en.wikipedia.org/wiki/License_compatibility#GPL_compatibility).

Fixes #3870
@joschi joschi marked this as a duplicate of #4005 Jul 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

4 participants