Quic doens't start

kvv213

New Member
#1
Hello Every One!

I'm a fresh migrate from Apache2 to OpenLiteSpeed. I've managed to migrate more or less well but I can't start using http/3 with quic. OLS doesn't start Quic.

I use:
  • Ubuntu 18.04.6 LTS (GNU/Linux 4.15.0-196-generic x86_64) VPS with XEN virtualization.
  • OpenLiteSpeed 1.7.16.
OLS contains:
Two listeners (not counting Admin one)
1668523975170.png
and a number of Virtual Hosts.

I've double checked the enabling of Quick at Server level:
1668524324781.png
Listener:
1668524421709.png
and Virtual Host:
1668524447332.png

Also I've checked UPD 443 port that it is available from VPS and to VPS:
1. I can reach google form VPS via UDP 443. That works.
2. I'm not able to reach VPS via UDP 443 from another server (but this server can reach also google via UDP). But.

But. If I use TCPDUMP at VPS side that is listen to UDP 443 and try to reach VPS via UDP 443 from another server then suddenly TCPDUMP receives packets from another server:
Code:
tcpdump -i eth0 -A -s0 port 443 and udp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:18:32.477132 IP 91.193.176.253.22794 > 85.143.202.103.443: UDP, length 1
E.....@.1.a.[...U..gY
...      aX.................
23:18:32.477178 IP 91.193.176.253.22794 > 85.143.202.103.443: UDP, length 1
E.....@.1.a.[...U..gY
...      aX.................
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel
Then I checked the open ports:
1668524779605.png

It seems that OLS doesn't use UDP 443. It uses only UDP for the admin listener (7081 port). Also it uses only IPv6 80 and 443 ports. But works well also with IPv4.

I've checked the error.log of the server:
1668524911191.png

it contains some infor that UDP 443 failed to be open. Without any other explanations. I've tried to check the problem with DEBUG mode but nothing more were found.

So, the server is able to receive UDP 443 but no one listen to it at the server side. OLS gives an error when trying to obtain UDP 443. All the settings are On. No quick as a result. What can be wrong?
 

Cold-Egg

Administrator
#2
OpenLiteSpeed default has HTTP/3 enabled and supported, so you don't need to change any HTTP/3 or security config for it.

From the netstat it seems you have UDP port 443 issue, please check the firewall.
 

kvv213

New Member
#3
OpenLiteSpeed default has HTTP/3 enabled and supported, so you don't need to change any HTTP/3 or security config for it.

From the netstat it seems you have UDP port 443 issue, please check the firewall.
I also thought about the firewall (iptables) but as I wrote above if I use a listener at my server, in my example it is tcpdump, the I can receive UDP 443 packets to my server.

Executing iptables -I INPUT -p udp --dport 443 -j ACCEPT doesn't bring anything. The message is the error log is the same.
 

kvv213

New Member
#4
I've moved a little bit further:
1668632397386.png

Separated the listener into two: for IPv6 and IPv4. It seems that IPv6 UPD causes the problem.

So, to date Quic works at IPv4:
1668633826580.png

Need to understand what is the problem with ipv6
 
Last edited:

kvv213

New Member
#6
I've do some other checks concern IPv6 and in/out UDP:

tcpdump -i eth0 -Q in udp port 443 and ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:51:42.807541 IP6 2a06:a004:f072::2.58318 > 2a04:ac00:2:65::.443: UDP, length 1
19:51:42.807623 IP6 2a06:a004:f072::2.58318 > 2a04:ac00:2:65::.443: UDP, length 1

In UDP 443 works (check at my VPS and a via remote server).

nc -z -v -u -6 google.com 443
Connection to google.com 443 port [udp/*] succeeded!

Out also works...
 
#10
So in the end what worked? Setting up a listener for IPv4 or just separating it from IPv6 or downgrading to OLS 1.7.15 and then re-upgrading to OLS 1.7.16?
I have the same issue with HTTP/3 & QUIC not working, in OLS 1.8.2. Some HTTP/3 checkers like ralfvanveen.com and domsignal.com pass the test saying I have it perfectly working, others like http3check.net (and all browsers) however fail the test and revert back to HTTP/2
 
Top