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?

Improve this question
3
  • 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, 2017 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, 2017 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, 2017 at 15:24

1 Answer 1

Reset to default
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).

Improve this answer
2
  • 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, 2017 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, 2017 at 13:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .