Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
10.5.20
-
None
Description
I tried to create a test setup for maxscale and proxy protocol, with proxy-protocol-networks only allowing the IPv4 subnet my maxscale instances were in.
The maxscale instances had IP 10.64.86.100 and 10.64.86.101, so I tried
```
proxy-protocol-networks=10.64.86.0/24
```
This did not work, connections via maxscale were rejected, but the cause was unclear at first, until looking at maxscale logs showed
```
Sending proxy-protocol header 'PROXY TCP6 ::ffff:10.64.86.100 ::ffff:10.64.86.11 36672 3306' to server 'galera-node-2'.
...
Master 'galera-node-2' failed: #HY000: Lost connection to backend server: network error (galera-node-2: 104, Connection reset by peer)
```
The ::ffff: prefix finally gave it away.
Disabling IPv6 as a first workaround made connections work, but that didn't feel like a correct solution
I then added the legacy prefix to my IPv4 netmask as:
```
proxy-protocol-networks=10.64.86.0/24,ffff:0a40:5600::/48
```
and with that things finally worked with IPv6 enabled, too.
The 6to4 prefix 2002:0a40:5600::/48 also worked.
As this is rather un-intuitive I'd say that proxy-protocol-networks handling should be made aware of incoming legacy IPv4 / 6to4 address and match them against given netmasks and host addresses given in classic IPv4 format, too.