If a remote host connected to a server via VPN is not able to ping the server, how'd you determine if the issue is with VPN at "server side" or VPN at "client side"?
(https://linux.org/attachments/1699203043386-png.17191/)
1. check if traffic is interesting source traffic is permitted trough the tunnel and will transverse. #2 check if response back is permitted.
Quote from: icecream-guy on November 05, 2023, 05:59:01 PM1. check if traffic is interesting source traffic is permitted trough the tunnel and will transverse. #2 check if response back is permitted.
It mat get there but return response is denied, packet capture on device or FW may be required.
1. Immediate error message - likely blocked on my end.
2. Really long time before error message - likely traffic permitted on my end, but possible that the traffic goes through the VPN OK and the service is down on the far side and I'm getting a TCP timeout.
If the VPN is not working, we'll get error messages from our end about the error, since the traffic simply can't go across. If the VPN is working, then good news is that we have it configured correctly, but that's no guarantee that the VPN terminator on the far side will permit traffic to or from our expected destination.
Traceroute is your friend, here. Where it fails determines where the (first) problem is. It will resolve fairly quickly, and if we see no far side IP addresses in the traceroute, we can be sure that the VPN on our side is not set up correctly, in terms of defining "interesting source traffic" or in terms of correctly matching cryptography with the far side. If there are far side IP addresses in the traceroute, then it's not the firewall. We have an image for that. :smug:
:notthefirewall: