We are setting up an internal program, on an internal server that uses the private 172.30.x.x subnet... when we ping the address 172.30.138.2, it routes across the internet:
C:\>tracert 172.30.138.2
Tracing route to 172.30.138.2 over a maximum of 30 hops
1 6 ms 1 ms 1 ms xxxx.xxxxxxxxxxxxxxx.org [192.168.28.1]
2 * * * Request timed out.
3 12 ms 13 ms 9 ms xxxxxxxxxxx.xxxxxx.xx.xxx.xxxxxxx.net [68.85.xx.xx]
4 15 ms 11 ms 55 ms te-7-3-ar01.salisbury.md.bad.comcast.net [68.87.xx.xx]
5 13 ms 14 ms 18 ms xe-11-0-3-0-ar04.capitolhghts.md.bad.comcast.net [68.85.xx.xx]
6 19 ms 18 ms 14 ms te-1-0-0-4-cr01.denver.co.ibone.comcast.net [68.86.xx.xx]
7 28 ms 30 ms 30 ms pos-4-12-0-0-cr01.atlanta.ga.ibone.comcast.net [68.86.xx.xx]
8 30 ms 43 ms 30 ms 68.86.xx.xx
9 30 ms 29 ms 31 ms 172.30.138.2
Trace complete.
This has a number of us confused. If we had a VPN setup, it wouldn't show up as being routed across the internet. If it hit an internet server, Private IP's (such as 192.168) shouldn't get routed.
What would let a private IP address get routed across servers? would the fact that it's all comcast mean that they have their routers setup wrong?
If the routers between you and the destination do not have ingress/egress filters that block the Private address space, then it would probably get routed following the default routes. You should strongly consider setting up rules on your external router that prohibits anything destined for a private address from leaving your network.
Lots of routers just forward all traffic, and don't do any kind of filtering at all. An private address looks just like any other address. If the router doesn't have an explicitly defined route it send it to its default gateway.
You have apparently managed to reach someone else with a poorly configured router.
There are also cases where can leak private IP, and still not be have those private IPs be publicly accessible. Lets say you had a simple network like this. Lets also assume the IP addresses are all publicly routable except for the subnet between router 2 and router 3. When you run a traceroute from client 1 to client 2, you may or may not see a response from the router 3. If you have good filters in place you will not see a reply, if you don't, and no other system has filters, you would see a reply. The packet returned from a trace route will usually include the IP of the interface the trace was received on, but it will be destined for the IP of the machine that is running the traceroute. Since the destination address is valid, the packet will be delivered, even though it has a private IP as a source address.
In many ways this comes back to the points in this question about IP forgery. When there are no filters in place, and you don't care about the replies, the source address can be anything you want. Because traceroute implementations use ICMP, and ICMP is stateless, you may see IP addresses that you cannot directly reach, or may possibly even be invalid.
It looks like your originating network is 192.168.28.0. Does your machine or your router know about the 172.30.138.x network? If not, it will just sent it out its default route like any other network it doesn't know.
You'll either need to add an interface in the 172.30.138.x network on your originating machine or add an interface in that network on your router so that it can properly direct the traffic.
Set up wrong? Yes, private addressing should absolutely be filtered within the interior of their network. But if they've been a bit sloppy then it's possible if the path is all Comcast- in carrier networks, especially sloppy ones like Comcast, private addressing is filtered at the edge networking diligently, but not nearly as much at the core or access portions. In your case it appears that the entire route is Comcast-only, so it is 'reasonable' that this might actually be forwarded to a destination also within Comcast that actually answers for it. It isn't a clean networking implementation, to be sure, and you did go from the Baltimore area to Denver and finally to Georgia, but it is possible within a complete "autonomous system" that allows for it.
Let's define what a private IP address is first: It's an address that, by convention, is agreed to not be routed on the Internet. That means that we agree as a community to never advertise those routes over BGP. It also means that that an ISP will probably kill those routes at the borders to their network to prevent them from possibly propagating.
That doesn't mean, however, that a private IP can't cross routers. It is very possible and even highly likely that Comcast uses private IP address ranges for networking equipment that isn't ever supposed to communicate with the Internet as a whole. Those routes may be forwarded by interior routing protocols throughout the entire Comcast network.
All in all, I'm going to guess that it's the case that your router performs NAT translation and then default-routes all traffic that isn't local to the next hop router, including private IP space. It's not very likely, though, that there are many Comcast routers sporting default routes that accidentally go all the way to a responding host with a private IP. It's my strong assumption that this is something purposeful. It might be a temperature sensor with remote monitoring or some other equally innocuous device that never needs to be talked to by anybody outside of Comcast.
Since your traceroute shows that all the packets remain within the Comcast network, it's actually not a very surprising circumstance that you've run into. It's staying within a single autonomous system and not violating any standards.
A private address is just like any other ip address. If it is announced to the Internet, it will be routable. Supposingly ISPs have inbound/outbound filters to prevent leaking these addresses to "what the end-user perceive as the Internet".
But in your case, the traffic never left Comcast AS7922. Comcast was using the RFC1918 private address, just like everyone else (ISPs usually use them for STB, modem, DHCP, DNS etc.). If they don't filter it, then you can reach it...