Funny PING problem - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: October 09, 2024, 07:41:08 am
content: I have a LAN, say 192.168.1.*On that LAN I have a fixed IP device, a little win7-64 industrial PC, say 192.168.1.123From any PC on that LAN I can ping the 123 one, I can run RDP to it, and I can browse it with File Explorer (by going to \\192.168.1.123).I also have a VPN (from a remote site) terminating on the above LAN.From the remote site I can ping or file-browse all devices on the above LAN. Except the .123 one!But from the remote site Icanrun RDP (remote desktop) to the .123 device. So RDP works to .123 but I cannot ping it. I also cannot browse it by going to \\192.168.1.123 (the usual error code 0x80004005).Yet pings (ICMP) cannot be disabled in the .123 firewall because one can ping it from another PC on the same LAN. Same for file browsing - cannot be disabled.The VPN is IPSEC, site to site. Been working for years. All PCs are win7-64.This is quite a narrow scenario and I wonder what it could be. Two things not working to .123. It is as if access was allowed from a local subnet only, but where might this be configured? But the VPN is terminating on the LAN i.e. something like 192.168.1.200 - that is how a VPN is supposed to work. The remote user is de facto on the LAN; he's not "remote".

author: gmb42
author_rank: Frequent Contributor
timestamp: October 09, 2024, 09:57:44 am
content: Have a look at Windows network profiles. There are three, for domain, private and public and they set firewall restrictions accordingly.Not entirely sure what such a decrepit OS supports, but in PowerShell I useCode:Get-NetConnectionProfileto see the profile of all interfaces andCode:Set-NetConnectionProfile InterfaceIndex xxx -NetworkCategory yyyto modify it.

author: peter-h
author_rank: Super Contributor
timestamp: October 09, 2024, 11:23:21 am
content: QuoteMy point is that how can the .123 device tell?A PC on the same subnet should appear the same as a PC on the far end of a VPN which terminates on the same subnet.Looking at the firewall settings,privateprofile, I find, as expected, that enabling/disabling incoming firewall controls whether the remote ping works or not.So I went to look through the firewall inbound rules to see which are forprivateprofile andblockbut I see no obvious candidates. There is a lot of ICMPv6 but I have IPV6 disabled at the adapter properties.

author: 2N3055
author_rank: Super Contributor
timestamp: October 09, 2024, 11:42:45 am
content: Quote from: peter-h on October 09, 2024, 11:23:21 amMight be stupid question, but did you try disabling FW altogether on .123 device for starters?Do you have any AV software on it? ESET, for instance, has it's own FW too.

author: peter-h
author_rank: Super Contributor
timestamp: October 09, 2024, 11:48:05 am
content: QuoteYes - as I say above. It makes it work. Problem is, the number of potential rules to try turning on and off is vast.No AV software.

author: 2N3055
author_rank: Super Contributor
timestamp: October 09, 2024, 11:55:25 am
content: Quote from: peter-h on October 09, 2024, 11:48:05 amSorry, I didn't pick it up.Well that is good. That means it is FW that is a problem. Now you know for sure where you should fix.Now to figure out how.While VPN (IPSec tunnels) tunnel you into network, they do it by encapsulation, layer into another layer.What device is VPN server and how do you connect to it on your side (Win built in VPN or something else?)?

author: peter-h
author_rank: Super Contributor
timestamp: October 09, 2024, 11:58:46 am
content: I've set up firewall logging but it shows no packets. OTOH there are possible complications with the fw have write access to the log file... Weird!The VPN terminator is a Draytek 2955 router - actually a 2955 at both ends.The VPN is brought up automatically when you generate traffic to the "other" subnet. In general it runs 24/7, probably due to windoze discovery packets etc etc.I need to get fw logging working...Ha! Got something. Windoze caches the logfile data and writes it to the file after some time... Now I see, under the Private log2024-10-09 12:51:55 DROP ICMP [remote PC ETH IP] 192.168.1.123 - - 60 - - - - 8 0 - RECEIVENow, which fw rule could this be?Now moving onto the nonworking file browsing, I see2024-10-09 13:03:49 DROP TCP [remote PC ETH IP] 192.168.1.123 63677 445 52 S 889718469 0 8192 - - - RECEIVESo, that .123 machineisseeing the remote machine's IP! Well, not its public (ISP issued) IP but its ETH adapter IP, of the form 192.168.x.y (where x is not 1 - it is another fixed IP machine).It will be buried among this huge list (a piece shown)Turns out that the "local subnet" limitation on item 1 in above list controls the ping! And the VPN remote machine is not on the local subnet...It would be nice to be able to edit the "local subnet" globally.And sure enough the "local subnet" was the issue for file browsing too. I changed the Private lines connected with file and printer sharing to Any and browsing and file transfer etc now works.Funny... not seen this behaviour before on many win7-64 installs I've done. Maybe the DVD was some odd flavour like "enterprise"Thank you. Every day is a school day. I was thinking that a remote (over-VPN) machine ends up on a local IP (because in the routers you can configure such an IP) but clearly this is not happening. Maybe that setting is on the PPTP VPNs and not the site to site IPSEC ones.

author: 2N3055
author_rank: Super Contributor
timestamp: October 09, 2024, 12:56:48 pm
content: Quote from: peter-h on October 09, 2024, 11:58:46 amGREAT!!Happy to help.IPSEC is lots of witchcraft, really. Packets are wrapped in other packets, really like onion....And then unwrapped on the other side.Your packets will have local IP address, but it will be remote...There are many details that you only see if you fire up Wireshark and open IP headers....On standard, old fashioned, no security LANs it is all transparent. But as soon as you start going deeper.....

author: peter-h
author_rank: Super Contributor
timestamp: October 09, 2024, 01:48:48 pm
content: Yes; the only way to get an IPSEC VPN working is to buy both ends from the same vendor and follow their app notes precisely.Like thishttps://www.draytek.co.uk/support/guides/kb-lantolan-ipsecor thishttps://www.draytek.co.uk/archive/vpn_setup.html.

author: Halcyon
author_rank: Unknown
timestamp: October 10, 2024, 08:49:27 am
content: Are you sure it's not a firewall rule? Even if the VPN connection lands in the same IP space, there may be seperate rules that govern the VPN interfaces. I'd start there.

author: madires
author_rank: Super Contributor
timestamp: October 10, 2024, 09:26:26 am
content: Quote from: peter-h on October 09, 2024, 07:41:08 amI'm a bit confused. A site-to-site IPSec VPN means that both networks have their own IP address space, are connected via the IPSec tunnel and routed via the VPN gateways. When both sites use the same private address space they need to set up NAT and additional address space to address each other. The other typical setup is end-to-site (road warrior). In this case a single PC/notebook uses an IPSec client to connect to a remote site and gets an IP address of the remote site. Additionally there can be special configurations. Which setup do you have? Every detail is important!

author: madires
author_rank: Super Contributor
timestamp: October 10, 2024, 09:37:03 am
content: Quote from: peter-h on October 09, 2024, 01:48:48 pmUsually most IPSec devices/clients work with each other after tweaking some settings. Some don't because they have stupid default settings which can't be changed. And I've even seen IPSec products from the same vendor beeing incompatible. IPSec is quite complex and it's easy to make mistakes.

author: gmb42
author_rank: Frequent Contributor
timestamp: October 10, 2024, 10:26:02 am
content: Quote from: peter-h on October 09, 2024, 01:48:48 pmOnly in your limited experience. A single counterpoint disproves your assertion; I use a Windows desktop (native IPSEC) to connect to the company firewall (not Windows based) over an IPSEC VPN for hours every working day. Not a problem.

author: peter-h
author_rank: Super Contributor
timestamp: October 10, 2024, 11:43:15 am
content: QuoteThe issue was a firewall rule, limiting access to thelocalsubnet.What stumped me is my belief that a VPN terminates on some IP of the LAN so e.g. if you connect to 192.168.1.* with a VPN, the remote device will appear on some configured IP e.g. 192.168.1.100. And I have seen such setups. But this VPN presents the remote device differently.QuoteYes; in the Draytek terminology that is the "teleworker" setup. I am using their site-to-site VPN setup. Actually this reminds me... I ought to test the teleworker setup also.QuoteYou had someone clever set it up

author: ejeffrey
author_rank: Super Contributor
timestamp: October 10, 2024, 03:12:38 pm
content: Quote from: peter-h on October 10, 2024, 11:43:15 amThat's not generally true and definitely not for a site to site VPN.In a site to site VPN, the VPN acts as a router connecting two separate subnets so that they can access each other. Devices on each site continue to use their existing IPs which need to be assigned from separate subnets. This is used if a business has two buildings, each of which has several clients, maybe a printer or file server and everyone wants to be able to access the other site in both directions. On each side, local traffic does not go through the VPN.Even remote worker VPNs often have a separate subnet for clients. So I your example, the host network might be 192.168.1.*, but there is a separate VPN subnet 192.168.2.*, and each client gets a unique IP on that network.It's possible to set up remote worker VPNs so that the clients appear directly on the host primary subnet but it's definitely not the only way.

author: gmb42
author_rank: Frequent Contributor
timestamp: October 11, 2024, 10:02:23 am
content: Quote from: peter-h on October 10, 2024, 11:43:15 amI confess, it was me that configured both ends and provided a simple PowerShell script for the rest of the users allows them to connect via an IPSec VPN as well. Not sure if that makes me clever or just able to read documentation. Not the worst thing I've ever had to deal with.