Good morning everyone
in the firewall log I often find many DROP_INPUT entries with Source IP (Facebook, Microsoft, and many others), Source Port UDP 443 and destination ports greater than 40000 on the public interface (red0).
It would seem to be QUIC traffic, but I can’t explain why it is blocked by the firewall (actually on the user side I don’t find any problems) as there is a special firewall rule that enables clients within my network to exit on UDP 443.
Can anyone give me a suggestion?
Unless I am mistaken, drop input should be traffic initiated from the WAN side of your network. IPFire drops that traffic by default, unless you have a rule that will forward it (destination nat, DNAT) somewhere in you LAN.
correct, that’s what I assumed too: a client of my network connects to facebook and receives a quic flow on udp port 443…
you say create a rule that forwards it (nat/DNAT) but how do I create a rule to that effect if I don’t know the source? i can’t open to the world and at the same time i don’t know who will respond with a quic flow
yes, I agree. You could write a rule to allow the incoming traffic on UDP port 443 as a source, but then you need to redirect that traffic to the machine that tried the connection. I am sure it can be scripted a way to solve this problem, but this is beyond my very limited knowledge of Iptables.
the problem is that the client that initiates the connection can be a laptop or a smartphone, which acquire a dynamic address from DHCP (external to ipfire). Regardless of identifying who established the connection though, once the connection is established, why does ipfire block return traffic?
it’s strange how this behaves, because once the connection is started Client side ipfire should somehow manage the connection
maybe it is not return traffic in the sense of an handshake syn, syn ack, ack, but an incoming syn?
it’s udp traffic…
thanks all the same, I’ll be forced to create a rule to prevent quic traffic.
I was asking this question why other firewalls handle these situations, and I was wondering why ipfire doesn’t handle them
of course. I did not connect the brain.
I hope someone more competent than I am can answer that question. My guess would be, you block as much as you can by default, being IPFire really paranoid (in a good way) with security. However, I support your question, how to open up the firewall (if you decide so) in such a situation?
also the DNS is UDP traffic, right? Could you use a similar approach to this rule? You force the outbound traffic from the clients on UDP port 443 to go trough the kernel of IPFire, which will then connect to facebook or whatever. Then, the return traffic should be forwarded back to the client?
sorry for the delay in responding, here is a small update after the removal (from firewall rules) of UDP 443 and addition, in outgoing rules, of the rule reported in my previous post.
Now on the firewall logs I have no entries regarding traffic (probably quic) with source port udp 443 towards the public interface of the firewall (strange, because I checked the box to log them), however I see many DROP_FORWARD type entries that from my clients go to google, facebook, etc. on source port udp 443 
