Closed ChristianDresel closed 4 years ago
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. :+1:
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!
## 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)
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.
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.
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:
curl
.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 ___.
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.
caddy version
or paste commit SHA)v2.0.0-beta.13 h1:QL0JAepFvLVtOatABqniuDRQ4HmtvWuuSWZW24qVVtk=
go version
)Download from here: https://github.com/caddyserver/caddy/releases/download/v2.0.0-beta.13/caddy2_beta13_linux_amd64
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:
---------------------^^^
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 --------------------------------------------------------------------^^^
i can not use v6 address in the to parameter at reverse proxy
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
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
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.
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.
thx i think you're right it's a apache problem and not from caddy.
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.