1

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?

Community
  • 1
Marco
  • 1,709
  • 3
  • 17
  • 31
  • 3
    ISP's can absolutely use RFC1918 in their internal network space (very common for internal management systems) but it looks like they may have missed an ACL dropping these nets from the CPE. They should've used RFC 6598 or IPv6. – Jacob Evans Jun 23 '17 at 17:35
  • I've edited the question in order to make more clear the kind of answer I was initially looking for. – Marco Jun 26 '17 at 15:14
  • You should contact the ISP (I would use whois to find a better contact for the IP your customer has publicly and contact them that way vs customer service"). There is no legal action or policy that says they must/cannot allow CPE access to their infrastructure. Maybe push them to use IPv6 Global ;). You could always find their twitter and publicly shame them. Some security advocates would email their legal team and warn them of pending disclosure. – Jacob Evans Jun 26 '17 at 15:24

1 Answers1

3

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).

Jacob Evans
  • 7,886
  • 3
  • 29
  • 57
  • 1
    They already have a full featured multilink utm firewall that can do that. Your suggestion to drop routing requests "in -> out" to the RFC1918 address space is a good hint! Thank you very much. – Marco Jun 27 '17 at 13:05
  • 1
    Great! It was part of my template in the early days of ipsec VPN on Cisco routers that required specific ACLs and route maps. Glad you figured it out. Now switch to global unicast and be done with this mess! :) – Jacob Evans Jun 27 '17 at 13:10