Hello! I have 3 company devices: one is the domain computer, another is the "technical" computer (a laptop where I've installed Windows with no limitations, no company control to do my actual job) and an iPhone. I've setup the mini router like this: It is connected to my personal phone hotspot just for testing reasons, I've connected it to the Wireguard V.P.N. built-in in my Fritz!Box 7590 with success. The kill switch feature is active, DNS over TLS in the mini router (GL-MT300N-v2) is active.
I can use the "technical" laptop without any issues, ipleak.net shows no leak. Same thing in my corporate phone. With my domain laptop instead I am having some troubles. I am using temporary for the purpose of testing at my home the WiFI connection of the GL.iNet forgetting all the previous networks (I don't have a USB-ethernet adapter at the moment, forgive me), and: even if I exit with the correct home IP address, I can resolve DNS using the "ping" binary in cmd or powershell, but when it comes to solve them in browser, the browser doesn't want to connect. It says that there is a problem in the DNS resolution. Fine, I'll put the IP address I solved using the "ping" function into the address bar. It doesn't work! I can't use Outlook, BUT I can use Teams and even have calls with colleagues, I can connect to my company's V.P.N., but sometimes the DNS resolution in the browsers (chrome, edge, firefox) doesn't work.
PAY ATTENTION! It is not always like this. It is upon the startup/reboot of the laptop to have this problem, then, after some tricky stuff in the DNS configuration of the GL.iNet it starts to work and goes smoothly until reboot. The actual configuration is now: DNS Rebinding Attack Protection and DNS over TLS (Cloudflare) enabled. On my Fritz!Box I've left my ISP default DNS at the moment for the seek of testing.
Since I am in my working location, I've tried to disable V.P.N. and kill switch and so exiting with my hotspot IP address, but my company laptop refused to solve DNS, so I exclude the V.P.N. connection is the problem and the problem is somehow inside the GL.iNet. (edit: or some local DNS resolution in my company laptop)
What do you suggest me to do? I didn't find a similar post before, so I would like to discuss this situation with you.
thank you so much for your answer! Now everything was working smoothly after almost one hour. nslookup says that the name server is the built-in router 192.168.8.1. I gave a reboot now to the laptop and it replies in the same manner at nslookup BUT now it can't resolve hostnames in the browser
If this can help: I have the Netskope client installed in my company laptop. When I test in ipleak.net I can sometimes see a Netskope DNS server IP address
2024/05/16 19:59:59.046 stAgentSvc p1d94 t201c info bypassAppMgrUDP.cpp:225 BypassAppMgr Blocking UDP connection from process: chrome.exe, dest IP:142.251.209.36:443
2024/05/16 19:59:59.047 stAgentSvc p1d94 t201c info bypassAppMgrUDP.cpp:225 BypassAppMgr Blocking UDP connection from process: chrome.exe, dest IP:142.251.209.36:443
seems like blocking UDP connections to the google.com IP (UDP connection blocked? DNS?)
This instead is a summary of more extensive logs from ChatGPT:
The provided log entries seem to be from a network security application, likely part of a proxy or VPN service used to monitor and manage network traffic. Here’s an analysis of the key events and their implications:
Steering and Bypassing Flows:
The system checks for different steering methods (amCheck Checking other steering methods).
Several entries indicate bypassing certain flows to specified exception hosts (e.g., bypassing flow to exception host: us-teams.events.data.microsoft.com, process: ms-teamsupdate.exe). This means the traffic to these hosts is allowed to pass through without the usual checks or restrictions.
Proxy Management:
Old connections are frequently removed from the proxied map (Removed old connection 192.168.8.206:56718 from proxied map). This indicates the cleanup process for stale or closed connections.
New flows are being tunneled through DTLS to various destinations (Tunneling flow from addr: 192.168.8.206:56718, process: searchapp.exe to host: www.bing.com).
Blocking and Throttling:
Several UDP connections initiated by chrome.exe are blocked (Blocking UDP connection from process: chrome.exe, dest IP:142.251.209.36:443).
The log shows warnings related to SSL write failures due to message sizes exceeding the interface MTU (nsssl DTLS SSL_write failed due to msg size 1359 is bigger than interface MTU). This might indicate issues with large packet handling, which can lead to connection problems or performance issues.
Duplicate Packets and Retransmissions:
There are entries about duplicate packets being detected and SYN packets being retransmitted (Got dup pkt: len 517, flags 18 from 192.168.8.206:56730 in state 3, retransmit SYN to NSP). This can happen in high latency or unreliable network conditions, where the system tries to ensure the packets reach their destination by retransmitting them.
Certificate Store Check:
The log also includes an entry for checking a specific certificate (javaCertStore java: findCert "ca.deloitte-eu-wps.goskope.com-Netskope Inc.-0163B7" result: 1). This indicates the system verifies certificates to maintain a secure connection.
Errors and Warnings:
A curl operation times out (curl_easy_perform failed, code 28, error Timeout was reached). Timeouts can be indicative of network issues or unresponsive remote servers.
There are warnings about the absence of Server Name Indication (SNI) in SSL connections (No SNI found in SSL connection 192.168.8.206:56735, tunneling). SNI is important for identifying the hostname in SSL/TLS connections, and its absence might cause some connections to fail or be handled improperly.
Overall, the logs reflect a system actively managing and troubleshooting network connections, enforcing security policies, and dealing with common network issues like connection timeouts, packet retransmissions, and SSL/TLS handling.
Implications and Potential Actions
MTU Size Adjustment: The repeated MTU size issues suggest a need to adjust the MTU settings on the network interfaces or ensure that applications are segmenting packets appropriately to fit within the MTU limits.
Network Exception Management: The frequent bypassing for certain IPs and hosts indicates that the exception list is actively in use. Review and ensure that all exceptions are necessary and correctly configured.
Connection Cleanup: Regular removal of old connections is good practice for maintaining network efficiency. Ensure this process continues to run smoothly to avoid stale connections impacting performance.
Handling Timeouts: Address the cause of timeouts in network operations. This might involve network stability checks or improving timeout settings in the network client's configuration.
SSL/TLS Configuration: The absence of SNI in some SSL connections could be problematic for some secure communications. Ensure that all necessary SSL/TLS settings and extensions are properly configured.
Understanding and addressing these issues will improve network performance and reliability.
this is actually a DTLS gateway, it encrypts and tunnels datagrams with this protocol and seems that when I am connected to the GL.iNet, despite the fact the VPN is active or not, despite the fact I connect it through the smartphone hotspot or directly into my Fritz!Box I have this problem. Yeah, the MTU error is inside this company software (NetSkope) to monitor the web traffic and it appears it blocks website due to a too big MTU, but unfortunately I can't change MTU because it requires elevated privileges. it doesn't block local IPs because it says they are in a sort of white list, so it is like I need to change this GL.iNet with another GL.iNet more expensive where I can change the MTU at the router level. Can I change it into the GL-MT300N-v2? I didn't find the option.
Thanks!
You need to adjust the MTU on all end devices, just the router will still cause fragmentation, which leads to issues. If you can't adjust the MTU on your company device, I don't see a good way how to fix this, tbh.
only the IT department can elevate privileges and so adjust the MTU accordingly. I can open a ticket and saying that I have connection issues with my new router working from home.
But in the GL.iNet I don't have the option to adjust MTU
Because it is pretty hard to understand the main issue, I asked ChatGPT so summarize your wall of text - could you please check if this summary is correct, so we can work just from a view points instead of walking through the whole text?
Summary:
Devices and Setup:
Devices: Domain laptop, technical laptop, iPhone.
Router: GL-MT300N-v2 connected to a personal phone hotspot for testing.
VPN: Wireguard VPN configured via Fritz!Box 7590.
Router Features: Kill switch and DNS over TLS enabled.
On company laptop: DTLS gateway encrypts and tunnels data.
Current Observations:
Technical Laptop & iPhone: No issues, no DNS leaks.
Domain Laptop:
Intermittent DNS resolution issues in browsers (Chrome, Edge, Firefox).
DNS can be resolved via command line (ping) but not in browsers.
Outlook doesn't work; Teams and company VPN do work.
Issues arise mainly on startup/reboot and sometimes require DNS configuration tweaks on the GL.iNet router.
MTU error caused by company software (NetSkope) which monitors web traffic and blocks websites due to too large MTU.
Testing Observations:
Disabling VPN and kill switch, exiting with hotspot IP still results in DNS resolution failure on the domain laptop.
Indicates the problem likely lies within the GL.iNet router or local DNS configuration on the domain laptop.
The problem persists whether connected through smartphone hotspot or directly to Fritz!Box.
Local IPs are not blocked due to being whitelisted.
MTU Issue:
The company software, NetSkope, blocks websites due to a too large MTU.
Changing the MTU on the domain laptop is not possible due to lack of elevated privileges.
Suspected solution involves changing MTU settings at the router level.
Need to determine if MTU can be adjusted on the GL-MT300N-v2 router.
At the moment, everything is correct. I'm trying to reboot the Laptop now. I've reboot also the router directly connect to the Fritz!Box and without the VPN and I'm gonna see what's going on here, to be sure isn't Wireguard the problem
UPDATE: I've rebooted the laptop and connected to the mini router without VPN. Worked at the first shot like a charm. Then I activeted the VPN, and still working! At the moment I am directly connected to the Fritz!Box so idk if the phone hotspot was the problem. I'll keep you updated.
Thank you so much again for your help, I love GL.inet
the journey is still going on. Now I've connected the GL.iNet to the Fritz!Box via Wi-Fi 2.4GHz and also VPN with kill switch is enabled and seems that there are no issues. But of course the point is to be connected to another router, ideally everywhere in the world, and being able to access my LAN in Italy with wireguard. So, the next step is going on some places with free wifi and try to connected the GL.iNet to it and try to use my company laptop to open random websites like google or LinkedIn. I'll keep you updated, thanks!
EDIT: I hope this will be my last update. Since I supposed the problem to be caused by the wireguard protocol, I decided to switch to OpenVPN. I used 4 years ago to setup an OpenVPN server on my Raspberry Pi4. Figured out it was still there, I opened again the UDP1194 on my router, setup a new configuration for my GL.iNet router and fired it. It was working like a charm. So, I've decided to try connecting to my phone hotpost, reboot the Laptop and the MTU problem seems to be no more! I hope you'll not see other messages in this thread, because this means the problem is finally solved.
So, my suggestion in case you have some problems with wireguard, regarding or not the MTU size: switch to OpenVPN, give it a try!
Thanks to the community, especially to @admon
- could you please check if this summary is correct, so we can work just from a view points instead of walking through the whole text?
