reverse proxy --to with a ipv6 address is broken

[ChristianDresel]

in the follow command:

reverse-proxy --from example.com --to [fd1f:4614:ef30::204]:80

The webserver at the end of fd1f:4614:ef30::204 answer with "400 Bad Request" and say:

Apache/2.4.38 (Debian) Server at example.com Port 204

the port is the last 2 bytes of the ip address. If i use a fqdn it works fine.

[mholt]

Thanks for opening an issue! We'll look into this.

I've just tried it and things are working for me. It's not immediately clear to me what is going on, so I'll need your help to understand it better. (My ISP doesn't support IPv6 so keep that in mind for reproduction instructions.)

Ideally, we need to be able to reproduce the bug in the most minimal way possible. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.

I've attached a template below that will help make this easier and faster! It will ask for some information you've already provided; that's OK, just fill it out the best you can. 👍

I've also included some helpful tips below the template. Feel free to let me know if you have any questions!

Thank you again for your report, we look forward to resolving it!

Template

## 1. Environment

### 1a. Operating system and version

```
paste here
```


### 1b. Caddy version (run `caddy version` or paste commit SHA)

```
paste here
```


### 1c. Go version (if building Caddy from source; run `go version`)

```
paste here
```


## 2. Description

### 2a. What happens (briefly explain what is wrong)




### 2b. Why it's a bug (if it's not obvious)




### 2c. Log output

```
paste terminal output or logs here
```



### 2d. Workaround(s)




### 2e. Relevant links




## 3. Tutorial (minimal steps to reproduce the bug)

Helpful tips

1. Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.

2. Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.

   • 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials.
   • 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
   • 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.

3. Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:

   • Start with an empty config. Add only the lines/parameters that are absolutely required to reproduce the bug.
   • Do not run Caddy inside containers.
   • Run Caddy manually in your terminal; do not use systemd or other init systems.
   • If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
   • Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
   • Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file:

{ ... }

Open terminal and run Caddy:

$ caddy ...

Make an HTTP request:

$ curl ...

Notice that the result is ___ but it should be ___.

[ChristianDresel]

1. Environment

1a. Operating system and version

two Debian 10 LXC Container on Proxmox.
uname -a
Linux caddy 5.3.10-1-pve #1 SMP PVE 5.3.10-1 (Thu, 14 Nov 2019 10:43:13 +0100) x86_64 GNU/Linux
cat /etc/debian_version
10.0

One with caddy2 and one with Apache2.
The Caddy2 Server has fd1f:4614:ef30::203/64 as IP and a public IP where we can connect from the internet
The Apache2 Server has fd1f:4614:ef30::204/64 as IP
domain example.com to a AAAA record to the public IP of the first Server.

1b. Caddy version (run caddy version or paste commit SHA)

v2.0.0-beta.13 h1:QL0JAepFvLVtOatABqniuDRQ4HmtvWuuSWZW24qVVtk=

1c. Go version (if building Caddy from source; run go version)

Download from here:
https://github.com/caddyserver/caddy/releases/download/v2.0.0-beta.13/caddy2_beta13_linux_amd64

2. Description

2a. What happens (briefly explain what is wrong)

i not use any config file and use only this line on caddy
If i use this cmd:
./caddy2_beta13_linux_amd64 reverse-proxy --from example.com:443 --to [fd1f:4614:ef30::204]:80

the Webserver answer with:
Bad Request

Your browser sent a request that this server could not understand.

Additionally, a 400 Bad Request error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2.4.38 (Debian) Server at example.com Port 204
-------------------------------------------------------------------^^^

it seems that der Port in the last line is the number from the last 2 bytes of the ip address:
[fd1f:4614:ef30::204]:80
---------------------^^^

if i change the ip address from fd1f:4614:ef30::204 to fd1f:4614:ef30::999 the webserver say:
----------------------------------------------------------------------------------------^^^
Apache/2.4.38 (Debian) Server at example.com Port 999
--------------------------------------------------------------------^^^

2b. Why it's a bug (if it's not obvious)

i can not use v6 address in the to parameter at reverse proxy

2c. Log output

root@caddy:/home/christiand# ./caddy2_beta13_linux_amd64 reverse-proxy --from example.com:443 --to [fd1f:4614:ef30::204]:80
2020/02/08 23:15:54.761 WARN admin admin endpoint disabled
2020/02/08 23:15:54.762 INFO http server is listening only on the HTTPS port but has no TLS connection policies; adding one to enable TLS {"server_name": "proxy", "https_port": 443}
2020/02/08 23:15:54.762 INFO http enabling automatic HTTP->HTTPS redirects {"server_name": "proxy"}
2020/02/08 23:15:54.762 INFO http enabling automatic TLS certificate management {"domains": ["example.com"]}
2020/02/08 23:15:54 [INFO][cache:0xc0002e3270] Started certificate maintenance routine
2020/02/08 23:15:54.764 INFO tls cleaned up storage units
2020/02/08 23:15:54.764 INFO autosaved config {"file": "/root/.config/caddy/autosave.json"}
Caddy 2 proxying from http://example.com:443 to http://[fd1f:4614:ef30::204]:80

sorry no more logs from caddy

2d. Workaround(s)

i can use a fqdn and it works finde:
root@caddy:/home/christiand# cat /etc/hosts
[...]
fd1f:4614:ef30::204 test.dns
[...]
and use:
./caddy2_beta13_linux_amd64 reverse-proxy --from example.com:443 --to test.dns:80

this works fine

2e. Relevant links

3. Tutorial (minimal steps to reproduce the bug)

take 2 Server with an ethernet link. Give both server a ULA ipv6 address that they connected directly and give the caddy2 Server a public v6. Add a domain like example.com to the public IP of the caddy Server.
Lets run on one Server a Webserver like apache2 and on the other caddy as reverse proxy:
./caddy2_beta13_linux_amd64 reverse-proxy --from example.com:443 --to [fd1f:4614:ef30::204]:80
if u open example.com you will see a 400 error and the port failure.

[mholt]

I won't have time to set up an Apache server in the near future, but I have a hunch that Apache is misinterpreting the Host header as a host:port and isn't supporting an IPv6 address in its place.

Everything I can see from testing IPv6 on my end, and adding debug prints/logs shows the correct values in the correct places. If you could invest more effort into where the bug lies, that'd be helpful for sure. A good place to start would be to enable debug logging and check what Apache is getting for the Host header.

[ChristianDresel]

thx i think you're right it's a apache problem and not from caddy.