NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
NAT loopback debugging help wanted
As you all know the RBR 75x and RBR 85x series do not properly support NAT loopback. The question is how did they manage to screw this up? Here's what I've found so far. - they have set up the ...
So I found out the NAT loopback works if the connection from the router to the server being accessed is via one of the ethernet ports on the device (rather than through an intermediate switch). I also found out that this is likely due to the
bridge-nf-call-iptables
setting, based on information in a forum of a different consumer device.
That is, if you issue:
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
it will work (just as if you turn on promisc mode on br-lan).
So this is interesting. The RBR 750 uses Linux's virtual bridging (a software implementation of Layer 2 switching) to connect the 3 physical ethernet ports (eth1, eth2, eth3) and the wireless interfaces into a single bridge interface. The problem is not the type or kind of switch, it's the fact that those packets cannot be sent directly to their layer-2 receiver. I don't fully understand it yet.
Normally linux bridge does not forward the packets to same ports, to avoid loop. If you have server and client on same port, you can try setting harpin ON for the port.
brctl hairpin br0 ethX on
minesweeper wrote:Normally linux bridge does not forward the packets to same ports, to avoid loop. If you have server and client on same port, you can try setting harpin ON for the port.
brctl hairpin br0 ethX on
I've already tried that and it didn't work. But I tell you what: Netgear has actually sent my a trial firmware they claim fixes the problem. As soon as I can take the router down, I'll try it out.
- Well running
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
Makes it work. And reading about bridge-nf-call-iptables, looks like there is discussion in the community for changing the default to 0 (may be in a different context) here https://wiki.libvirt.org/page/Net.bridge.bridge-nf-call_and_sysctl.conf
So for now I have changed the value to 0, until the hot-fix or new firmware fixes that. I just need to ensure that nat/routing functionality is not impacted (i.e. the router continues to send packets from outside to ip tables and does not act like a router) will check it from external host. I don’t believe it should because bridge is at layer 2 and routing being later 3 should not get impacted.