Scenario: I have a customer running a Win7 Pro and an OpenVPN client; this workstation is used from one of their employees to send remote cmds to the (Windows) OpenVPN server, both using psexec and smb.
What happend: Everything went fine for years, until their sysadmin upgraded the workstation to Windows 10 Pro. He relied on the Windows upgrade advisor, and just uninstalled the old antivirus that was marked as incompatible. After the upgrade, he - in good faith - did the following tests:
-check the openvpn service on the client -> runnning
-ping 10.8.0.1 (server's ip) -> OK
So he obviously thought everything was fine.
As this workstation is used by the employee at nighttime, the morning after I was involved by their internal sysadmin as the employee wasn't able to send updates. He said none of the services did send reply through the vpn, only icmp was working. Firstly I did some telnet to the ports that I expected to be reachable and found I got instant connection refused. I did a ping and found a TTL value in the reply of 250!?!? I did the following tracert:
C:\>tracert -w 100 10.8.0.1
Traccia instradamento verso 10.8.0.1 su un massimo di 30 punti di passaggio
1 3 ms 2 ms 2 ms 192.168.0.4
2 1 ms 2 ms 2 ms 192.168.22.41
3 1 ms 3 ms 1 ms 10.139.59.130
4 5 ms 3 ms 3 ms 10.3.132.113
5 15 ms 13 ms 15 ms 10.254.12.202
6 15 ms 15 ms 15 ms 10.254.1.245
7 27 ms 25 ms 23 ms 10.8.0.1
The first time I looked at this it was unbelivable, but 0.4 is their internal Default GW, 22.41 is one of their routers, and this router is only connected to the ISP.
Fix for Openvpn issue: I quickly figured out that regarding the Win10 upgrade and the openvpn client it was just a matter of routes mess, and openvpn logs confirmed that, and solution (upgrade to latest openvpn) fixed it. I still can ping 10.8.0.1 from any other computer in their network not running OpenVPN, if policy routing bring the connection on this 22.41 uplink. If I route the connection to any other of their 4 (tot. 5) uplinks the issue doesn't happen. As this "say pirate" 10.8.0.1 replies on every port with instant rejects and everything is closed I think it might be a router. I'm just wondering if the ISP is violating the RFC 1918 or else how is it possible that I can ping an ip from the Private Addresss Space in the public network!?
--- Edit 2
Question: As the Customer feels this unexpected behaviour has damaged their business, can they mention any documents such as RFC stating that the ISP has violated any service rules for providing internet services?
RFC1918 Private address space CAN be used by the ISP, typically it would be transparent to the customer, it appears they have a firewall/ACL misconfigured as those addresses should not be visible to the customer.
Contact the carrier, either NOC Contact from the Net-Whois or via Customer Support. I am not aware of any legal action that can be taken.
RFC 6598 (100.64.0.0/10) was carved out for as a CGN/NAT444 space to be used by the ISP's in transition to IPv6 space. Each ISP does it's own thing, standards are not Laws.
If nothing else, you could configure your customer firewall to drop unused private ISP space to the WAN, which may require a better router/firewall or 3rd party software (DDRWRT).