We have a few RFID readers with web interfaces that can not be reached when logged into the company through VPN. We have several systems with web interfaces that we can access while connected to VPN. I am not sure what the issue is.
Gather your basic troubleshooting info to compare working and non-working systems. Obfuscate output as necessary to keep your configuation anonymous
–Ping and traceroute from VPN client to working and non-working systems and compare.
–If you are accessing RFID reader via hostname or fully-qualified domain name in browser, verify what the host resolves to. Compare this with DNS resolution for working systems. Does this resolve the same whether you are inside or outside of your network?
–Assuming your RFID reader has a single network interface, does routing exist to reach back from the RFID reader to your VPN IP addresses (check subnet mask and default gateway). In one relevant example, a customer set up their internal network as a single flat network with IP addressing 192.168.0.0/24, then later added a VPN where clients obtained IP addresses in the 192.168.1.0/24 range. While the DHCP server and servers with static IP addresses were modified to use the newer 192.168.0.0/23 network and mask, some existing video appliances still had the older /24 subnet mask and could not communicate with VPN clients.
Thank you! I’m working on it.
Additionally, check your VPN configuration.
For example, if your working servers are in the 192.168.0.0/25 range network and your non-working RFID readers are in the 192.168.0.128/25 range, does your VPN configuration allow your clients to reach the entire 192.168.0.0/24 network?
Check for VPN overlap with local networks. For example, let’s say your RFID readers are in the 192.168.0.128/25 network, but your VPN users also have a home network in the same 192.168.0.128/25 network. If your VPN configuration allow clients to access their local LAN at the same time as the company LAN, there is a conflict when the local LAN has the same network used in your company LAN.
Your suggestion lead me to see that the subnet was not listed in the split-tunnels.