NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
R6400 Port Forward issues V1.0.1.12_1.0.11
I just purchased a new NETGEAR R6400 router. I am trying to set up some port forwarding rules that have worked perfectly on other NETGEAR routers. For example, inbound traffic on port 13389 should ...
The Release Notes for V1.0.1.12_1.0.11 indicate that they enhanced port forwarding:
- Improves port forwarding by allowing fixed and range ports to be added to one rule.
If you upgraded from a previous version, then you may want to perform a factory reset to wipe out any incompatible configuration settings left over from the previous version. Then re-enter the port forwarding settings by hand. Do not restore from a backup configuration file because it, too, can be incompatible with the new version.
If this doesn't work, then try downgrading to an older version. You can find firmware here (link). Be sure to perform another factory reset after installation.
I had the same problem with an R6400 I just purchased. It caused me a great deal of lost time and frustration since I use port forwarding extensively. To find the problem I used an Ethernet sniffer (wireshark) and discovered that the R6400 did not implement port forwarding correctly, as specified by RFC 1631 and its successors. The R6400 does not bind the gateway IP address as the source of the forwarded message and instead forwards the message with the originating host's public IP address! Of course that address is invalid inside the private network and so is discarded by the intended host target. I ended up putting the new Netgear router on the shelf and bought a Linksys router until this is fixed. I'll try reverting to a previous firmware load and see if it works.
I hope someone from Netgear reads this and verifies the problem so it can be fixed.
gkcambr wrote:I had the same problem with an R6400 I just purchased. It caused me a great deal of lost time and frustration since I use port forwarding extensively. To find the problem I used an Ethernet sniffer (wireshark) and discovered that the R6400 did not implement port forwarding correctly, as specified by RFC 1631 and its successors. The R6400 does not bind the gateway IP address as the source of the forwarded message and instead forwards the message with the originating host's public IP address! Of course that address is invalid inside the private network and so is discarded by the intended host target. I ended up putting the new Netgear router on the shelf and bought a Linksys router until this is fixed. I'll try reverting to a previous firmware load and see if it works.
I hope someone from Netgear reads this and verifies the problem so it can be fixed.
Can you clarify the incorrect behavior? Public source IP addresses are perfectly valid inside a private network. Was the R6400, perhaps, not translating the public destination IP address into a private address?
In my application external (public) hosts use websockets within their browser to set up TCP connections to a private host within my LAN. Using an Ethernet sniffer (wireshark) I saw the external hosts TCP request properly translated at the NAPT to the internal private destination address and port. However the incoming PDU's source IP address and port were public (not translated). My host did not accept that packet. To resolve the problem I took the advice given to others and loaded the previous firmware load V1.0.1.6_1.0.4. Once loaded I reset the router and re-configured it exactly as I had done the V1.0.1.12_1.0.11 load. The older load worked.
I read RFC 2663 and believe the safest implementation for a NAPT is Twice NAT (section 4.3). That implementation binds the WAN public address in the public domain the LAN gateway address in the private domain. Both source and destination addresses are translated as PDUs cross the LAN/WAN boundary in both directions. I don't know if this is the problem, but you can verify if the bindings are different in the .4 and .11 loads.
It's still a little unclear about what you observed. You said you saw the external host's TCP request properly translated to the internal private destination address and port. Are you talking about the initial TCP 3-way handshake? Was the source address from the external host translated?
Then you said an incoming PDU's source IP address and port were not translated. Are you talking about PDU's that arrived subsequent to the initial TCP handshake?
IOW, did you see the source IP address translated for some packets but not for others? That would be a bug.
AFAIK, Netgear implements Section 4.1 NAT (i.e. Traditional or Outbound NAT). It's more expensive to implement Twice NAT with limited, additional benefit.
I set port forwarding to one of my Linux systems with an ethernet sniffer and captured the TCP connection request generated when my application tries to connect from an external host to my public port 780x. This was done with the older NetGear release, V1.0.1.6_1.0.4. I don't have my app running on that host so all we see is the connection request, however this release works with my app server. Unfortunately it cannot support the sniffer on the app server. I have the wireshark file if you'd like to look at the working TCP connection request, but I don't think I can attach it to the forum reply. My email is gkcambr@yahoo.com if you'd like a direct copy.
If you hit a complete dead end, I'll reconfigure my network with the newer NetGear release and perform a similar capture. That's a pain, but if there's no other way I can do that.