Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am a bit stuck with an experiment of mine.

I have a network looking somewhat like this.

        | Internet |
    ----  |Switch| ---- 
    |                  |
Server w/pub IP       | DD-WRT router |
                         RFC1918 clients

What I want is for the RFC1918 clients to speak directly with each others.

On the server with the public IP I have this route: dev eth0 scope link and can see that packets are infact reaching the dd-wrt router for, even though if I get no answer.

Trying to reach one of the RFC1918 clients from the public IP server will get no result, as the dd-wrt router is not announcing that network on to its external interface (arp who-has tell, but no answer).

The router being an WLAN dd-wrt router has of course a load of routes, VLANs and interfaces: dev vlan2  scope link dev br0  proto kernel  scope link  src dev eth1  proto kernel  scope link  src dev vlan2  proto kernel  scope link  src dev br0  proto kernel  scope link  src dev lo  scope link via dev vlan2 being the public IP, and being the default route for the public IP.

I am not sure where to continue with this. I would recon that I both need routing on the dd-wrt router, as well as some iptables magic?

Why do something this complex? Why not ;)

Also, do not mind that "Internet" can get RFC1918 traffic, it wont go outside of the walls.

EDIT 1: Following the tip from stew I do indeed get the correct ARP flowing. And adding an iptables rule for allowing traffic from that specific public IPd machine I get traffic between the systems!

Oddly enough though, the speed I get from Server w/pub IP -> RFC1918 clients are the same as if the traffic were routed out onto the Internet and back.

Edit 2: Ok, disconnecting the external Internet connection will still give the same, crappy transfer speed. So it has to be something else.

Edit 3: Ok, I guess there are other reasons for this crappy speed. Case closed. :)

share|improve this question
up vote 1 down vote accepted

You need the dd-wrt to proxy arp requests from one interface to the other. try:

echo 1 > /proc/sys/net/ipv4/conf/eth1/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/br0/proxy_arp
share|improve this answer
That ensures that ARP at least is working, altough no traffic other than that is being sent through the router. I am not sure if it is iptables. The traffic does not reach the client, so I do not think it is the return traffic that is broken. – espenfjo Jul 3 '12 at 19:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.