Hey,
I still try to implement VPN-Server to my network, I get connection to it, but I can not go out as it seems (despite the rule for VPN-Server to access the whole red network). I tried it in DMZ and tried it in GREEN with the same result.
The only thing I see, if I try to connect to the internet with my VPN client (wireguard) are drops as mentioned: DROP_CTVALID ICMP with destination port 53, from the VPN server to the VPN client.
It seems to be a DNS problem.
Maybe it’s the point I need to solve.
are these drops such special that nobody knows them?
I read a little bit about DROP_CTINVALID, but I could not understand, what does it mean in my case.
thanks, but I don’t really understand what does it mean in my case. Why are they dropped specially while the VPN client try to access the internet within VPN tunnel? Why on port 53? Why from the VPN server to the VPN client?
When a packet arrives at the Linux kernel, it goes through various checks, including the connection tracking process. If the packet’s connection tracking state is deemed invalid or inconsistent, the kernel may choose to drop the packet and log the “DROP_CTINVALID” message. This could happen, for example, if the packet does not match any existing connection or if it violates the expected sequence of packets for a particular connection.
You need to figure out what’s happening to those packets. Packets not following the correct sequence? Loss of connection? Latency? The conntrack table can be visualized with conntrack -L. Look for ip and port for source and destination, timestamp and try to mach with the conntrack table.
EDIT, you should also look at the possibility you might have a problem of MTU size being not optimal. That could introduce a latency problem leading to DROP_CTINVALID. This is the sequence of events that can lead to dropped traffic due to fragmentation and latency as explained by GPT4:
VPN Server Configuration: Let’s assume the VPN server is configured with an MTU setting that is larger than the allowed MTU size of the underlying network infrastructure. For example, the VPN server’s MTU is set to 1500 bytes, but the network only supports an MTU of 1400 bytes.
Packet Transmission: When a client sends a packet to the VPN server, the packet’s size exceeds the allowed MTU of the network infrastructure. In this case, the packet needs to be fragmented into smaller fragments to fit within the network’s MTU size.
Fragmentation and Reassembly: The VPN server fragments the packet into smaller fragments according to the MTU size of the network infrastructure. Each fragment is then transmitted over the network to the intended recipient.
Invalid Fragments: At the receiving end, if the network devices (such as firewalls, routers, or other VPN servers) responsible for reassembling the fragments encounter issues, the fragments may not be properly reassembled. This can happen if there are network misconfigurations, firewall rules, or any other factors that interfere with the reassembly process.
DROP_CTINVALID Log Messages: When the reassembled packet is considered invalid by the CT mechanism due to incorrect or missing fragments, the network device drops the packet and generates DROP_CTINVALID log messages to indicate the discarded packet
This is also a sensitive issue due to the layer of encryption/decryption above the normal traffic. If the MTU settings introduce a fragmentation need after the content has been already encrypted, all sorts of bad things can happen leading to dropped traffic. You will find many thread discussing this issue in the forum.
thanks a lot, guys… and (maybe) gurls!! I will try to understand it with these infos.
As it seems, I already have an idea of this issue, but must investigate a little bit more.