Routing RFC1918 addresses through dd-wrt via a switch
- by espenfjo
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 192.168.1.1 |
|
RFC1918 clients 192.168.1.0/24
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: 192.168.1.0/24 dev eth0 scope link and can see that packets are infact reaching the dd-wrt router for 192.168.1.1, 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 192.168.1.107 tell xxx.xxx.xxx.xxx, but no answer).
The router being an WLAN dd-wrt router has of course a load of routes, VLANs and interfaces:
xxx.xxx.xxx.1 dev vlan2 scope link
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.244
84.215.64.0/18 dev vlan2 proto kernel scope link src xxx.xxx.xxx.xxx
169.254.0.0/16 dev br0 proto kernel scope link src 169.254.255.1
127.0.0.0/8 dev lo scope link
0.0.0.0 via xxx.xxx.xxx.1 dev vlan2
xxx.xxx.xxx.xxx being the public IP, and xxx.xxx.xxx.1 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. :)
