stevesgt's profile

Tutor

 • 

4 Messages

Sat, Mar 4, 2017 5:26 PM

NVG589 private/public IP routing (broken NAT?)

I just was just given an Arris MVG589 router after a service call. I've paid for a public fixed IP block x.x.x.184/29, which gives me usable addresses from x.x.x.185 to x.x.x.189 with x.x.x.190 reserved for the router. I am also using the default private network at 192.168.1.0/24 with the U-verse router at the default 192.168.1.254.

The problem is that while hosts on the public Internet can reach my public address hosts reliably, and hosts on my private network can reach most hosts on the public Internet reliably, hosts on my private network mostly get timeouts trying to reach my public IP addresses on any TCP protocol (http, ssh, sftp, etc.). I can ping my public hosts from my private hosts reliably.

 

The other odd thing is that logs in my public hosts are showing that they're getting connections from 192.168.1.x addresses. When using my previous router, the logs in my public hosts would show connections from x.x.x.190 for any of my private hosts.

So does anybody know of some setting that could cause this that I might have overlooked?

ATTHelp

Community Support

 • 

180K Messages

5 y ago

Hi @stevesgt,

 

We are sorry about the issues. You may want to try to do a trace route to see where the connection is having issues. You may need another router behind ours to separate the traffic, as it appears our router is having issues trying to separate the LAN. We apologize about this issue.

 

-ATTU-verseCare

Tutor

 • 

4 Messages

5 y ago

RFC3022 makes it clear that the source address to any host on the WAN side of network address translation should be the router's address, not one of the RFC1918 private addresses. So what I'm seeing is clearly misconfiguration of the masquerade portion of network address translation. Since any configuration of this operation is hidden from the consumer user, it appears to be a design error in the router itself.

 

In my case, a traceroute from a private address host should, and does, yield a two hop result: 

traceroute to x.x.x.185 (x.x.x.185), 64 hops max, 52 byte packets
 1 192.168.1.254 (192.168.1.254) 0.734 ms 0.723 ms 0.556 ms
 2 public.host.net (x.x.x.185) 1.126 ms 1.110 ms 0.673 ms

 

A traceroute, and even a ping, from a public host to a private host should fail, because the RFC1918 private addresses should never appear in the globally unique public Internet address space. This is indeed what happens in my case:

traceroute to 192.168.1.67 (192.168.1.67), 30 hops max, 60 byte packets
 1 * * *
 2 * * *
 3 * * *
 4 * * *
 5 * * *
 6 *^C

 

If I was able to ping or traceroute from a public host to an RFC1918 private address, that would be an even more serious failure.

 

ATTHelp

Community Support

 • 

180K Messages

5 y ago

Hi,

 

We are sure that the packet headers for source and destination should be good. You can use a packet tracer program like wire shark to look into it. What appears to be happening is that the router is routing internally, since the routing table for the public IP is built into our gateway. Due to the lack of NAT loopback on our gateway, it sounds like that may be the issue you are encountering.

 

-ATTU-verseCare

Tutor

 • 

4 Messages

5 y ago

Problem solved. Today a technician brought me a new router/gateway: A 5268AC model.

 

It works perfectly in a way that the NVG589 most certainly does not.

ATTHelp

Community Support

 • 

180K Messages

5 y ago

Great to read and thanks for sharing the resolution. 

 

-ATTU-verseCare

 

 

Need help?
New to the AT&T Community? Start by visiting the Community How-To.
New to the AT&T Community?
Visit the Community How-To.