I have read several complaints in this forum lately about port forwarding not working properly, and just to clarify, port forwarding is from WAN to LAN which still works fine, most users are having problems with loopback (LAN to WAN to LAN or LAN to LAN). The way dd-wrt implements it currently will not work for most setups, to fix it, you can go to the webgui in dd-wrt under Administration > Commands and enter in this code, once the code is entered, click "Save Firewall" and restart the router.
iptables -t nat -I POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE
Of course if you use a different subnet than 192.168.1.1 you'll have to adjust the code to work for what subnet you use. Also, another great code, which i hope will soon be implemented into dd-wrt is..
insmod ipt_markinsmod xt_markiptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get wan_ipaddr` -j MARK --set-mark 0xd001iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE
Which can also be saved in Administration > Commands enter the code then click "save firewall"
This code adds loopback for ALL interfaces regardless of how many different subnets you use.
Hey buddee... thanks for your post. I had posted a couple of days ago in dd-wrt, but no answer so i thought I would come here.
My original post is here:
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=612722#612722
The post basically explains a port forwarding issue to additional internal subnets. As I saw this post of yours right when I visited the forums here I thought I would try it first.
I tried your first suggestion, modifying the subnet to 10.10.10.0 as that is my internal LAN that the router is on. I fed the command via SSH, so I didn't think rebooting was necessary as IPTABLES should go into effect right away. It didn't seem to work... I was still unable to access a port forward on the 10.10.20.0 network.
I then tried the commands from your second post. For the two insmod commands I got:
The two IPTABLES commands took and then immediately I was able to access a port forward on my .20 network!
So, first off..thank you very much. However, I am not content with a solution, I would like to better understand. I am familiar with firewalls, but not IPTABLES (I am currently beginning my studies into it).
Can you explain to me the limitation in DD-WRT that makes this necessary, and what the two iptables commands you provide actually do.
Also, can you explain why the insmod errors?
And finally, do these command reduce security at all (other then the fact that a port forward is allowed, is there any other risk)?
Thanks so much!
This could perhaps explain better than me..
Thanks buddee...actually found that on my own. Unfortunately it doesn't really explain the details...which I would like to understand the syntax a little better.
What's interesting (and I posted this on dd-wrt as well) is that although this is a posted fix for loopback problems it solved my issue as well.
The normal loopback issue is if you say forward port 25 on your mail server to your internal IP of 10.10.10.150. If you try to access this from outside your LAN - no issues. However if you try to access port 25 using your WAN address (instead of directly connecting to 10.10.10.150) from WITHIN your LAN you will have problems without this fix.
My issue isn't the same - my issue was not being able to access a port forward off of a secondary network (say 10.10.20.120) from either inside or outside the LAN via the WAN address. I had configured two additional subnets in advanced routing and could route between them (via an intermediary router) without issue. My port forwarding to these subnets worked fine on my old Tomato router, but not via dd-wrt.
Those two IPTABLES commands seem to have done the trick.
Anyway, maybe I will mail the guy who proposed the fix initially... thanks for pointing me in the right direction!
Well main thing with this is since you do not know iptables very well, i could explain all day, and you probably wouldn't understand what i am talking about, so my apologies there.
I will say this, loopback in general breaks certain functions of wireless, like WDS becomes broken with the old loopback code in place (before the 15778 change) and port forwarding is not loopback, port forwards work with WAN to LAN, which still works fine, loopback works with Lan to Lan or Lan to Wan to LAN, which without the input code i posted, will not work because its not letting the loopback pass by not masqurading the packets to the inner lan. Hope that makes sense.
Also don't worry about the modules not found, the modules are mainly for broadcom units, Atheros does't need it but since phuzi0n came up with the code, i felt i needed to keep it fully intact, even if the mods aren't found, the code still works.
hmm...yeah.. Well I am going to research iptables in more detail...I'm pretty comfortable with routing and firewall concepts, just not coming from an iptables background. I was interested in the syntax of the statement, as it's quite exotic compared to a standard iptables command.
Loopback/port forwarding should, in theory, have nothing to do with wireless functions... I have 0% insight into the code under dd-wrt, but allowing loopback functions and port forwards to internal networks are a common function on many routers. I also had a Tomato router in previously which functioned with loopback, the port forwards I need, and WDS at the same time. If it breaks these things in dd-wrt it's because it isnt designed well to begin with (of course...that's easy for me to say...i would have no idea how to code it better! but then again, I'm the consumer...I provide the money, not the product).
My experience with dd-wrt so far hasn't been good, and I wish Tomato was supported on more devices. It may only have 50% of the features that dd-wrt does, but those are the 50% of features that 95% of the community needs/wants, and they all work fantastically. At least I should thank the dd-wrt developers for offering an alternate firmware supported on newer devices - even if it is buggy.
I think Buffalo is way out of line shipping units with dd-wrt though...as they don't offer any real support or documentation on their build of it. I would go back to the stock firmware if only the QoS were better. They shouldn't claim it as a feature - especially as it is cancels out the majority of the rest of the feature sets that they advertise (that only runs on their stock firmware).
Anyway, thanks again for pointing me in the right direction - my current situation only requires QoS and these port forwards. I don't think I will play around with much more of the functionality of dd-wrt anyway as every one thing is bound to break something else. I just hope at the least the router remains stable and can provide these basic functions without drop-offs.
cheers
Thanks so much for the loopback trick! It took me a while to realize port forwarding was working, it was just because I was trying to access the ports from the local LAN that made it seem like it wasn't working. It was driving me crazy!
I've recently purchased a buffalo HighPower N300 Gigabit Wireless Router.. and I am having problems with the loopback port forwarding. I tried the suggested lines in the firewall section. The port forwarding seems to work for a few seconds, and then doesnt work any more. The build that is on this router is 19438. Do you have any suggestions for me to try? Please let me know if you need any router information from me.
Which code are you using?
sorry for the late response.. I am using the code thats showing at the top of this thread. It doesnt seem to be working for me. I can access everything using the local IP address, but not from my WAN IP.
insmod ipt_markinsmod xt_markiptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get wan_ipaddr` -j MARK --set-mark 0xd001iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE
So remove that one, and try the first one i posted, make sure the 192.168.x.x matches whatever subnet you are using:
iptables -t nat -I POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE
This code still wont work for me. I'm guessing I have something configured incorrectly. But everything else works fine.. and if you are outside the network, all the port forwarding works great. Here are some of the settings for my router off of the basic setup screen. Let me know if you would like to see any other information. Everything is pretty much default.
Local IP Address 192.168.1.1
Subnet Mask 255.255.255.0
Gateway 192.168.1.1
Local DNS 192.168.1.1
DHCP Type: DHCP Server
DHCP Server : enabled
Start IP Address 192.168.1.2
Max DHCP Users: 200
Client Lease Time: 1440 minutes
Static DNS 1: 0.0.0.0
Static DNS 2: 0.0.0.0
Static DNS 3: 0.0.0.0
WINS: 0.0.0.0
Use DNSMasq for DHCP: Checked
Use DNSMasq for DNS: Checked
DHCP-Authoritative: Checked
Its interesting, no matter which code I use, When I reboot my router (from the admin page) for a few seconds the loopback works, then its off again. Like something that loads late in the bootup, blocks it.
Before we go further with this, i want to know that you understand what loopback is, so my question to you: how are you checking to see if loopback is working? Because i can go on and on with this trying to troubleshoot something, but i want to know that you understand what you are talking about with this issue, because this all began with you just posting that you are having trouble with loopback, never did you state any details of whatever it is you are trying to do and how you are going about checking to see if loopback is working or not.
Networking is not my area of expertise by any means, so my use of terminology in this area may be misconstrued. My appologies for not being clear to begin with. I appreciate you taking your personal time to answer mine and every one else's questions. You seem to be pretty knowledgable in this area.
In my research for my issue I came across this and several other threads for problems that seemed to match my own, so I figured this was the right place. My loose understanding of Loopback is to send the signal back to the source for testing purposes.
Let me explain what I am doing. For simplicity, I'll just explain that I have a web server on one of the computers on my home network (other things such as ftp and telnet have the same issue). I CAN access my web page by using my Web Server's internal IP address directly (192.168.x.x). I CANNOT access my web page using my external IP address, when I try from any computer/device that is inside my network. I CAN access my web page by using a computer/device from outside of my local network by using my External IP address. So, I can deduce that my port forwarding is working correctly, and the data is being passed to web server with no issues.
When I say that it works for a few seconds after the reboot, what I'm doing is, I have an internet browser open, with my external IP address punched in the address line.. and after I click reboot on my Router, I start hitting refresh in the browser to see if I'm able to access my webpage from inside my network, using the external IP address. After I see that my network start to come back online, I am able to access my webpage for a few seconds. After those few seconds, I am unable to access my webpage from inside my network again. This makes me think that something loads late in the router boot up sequence, that blocks my communication to the website from inside the network.
My old router (linksys with dd-wrt loaded on it) worked fine in this area.
If you need any other information than I've given you already, let me know and I will be glad to give it to you.
How are you assigning the IP to the web machine? Manually on the device itself, or are you using static DHCP lease thru the router?
Each computer I have a port being forwarded to, I set the IP manually, and other devices/computers obtain theirs from the router.
Each computer uses the 192.168.1.x block of ip's subnet mask 255.255.255.0 .. default gateway 192.168.1.1 .. pretty standard addresses.
Right, you should try setting static leases thru DHCP on the router, not the devices, this way the device will have a static ARP binding and be able to be found in the router's routing table, when you set a hardware IP within the hardware itself, it communicates to the router somewhat transparently, because there is no table for the router to follow nor does it have to because you choosen another method externally and not using the router. Not saying this is going to yield promise, but its worth a try and it something i noticed some while back, so now i use the router to assign static DHCP ip's and have no problem with loopback.
I set up the router to assign static IP's to my computers and set the computers to obtain an address automatically. Still unable to get anything from inside the network.
Show me from command line 'iptables -vL' no quotes, this will show me all your chains, then we can determine if the router is the culprit. And yes i know, it'll output alot, so you may have to use the code insertion function of this forum.
Chain INPUT (policy ACCEPT 180K packets, 36M bytes) pkts bytes target prot opt in out source destination 0 0 DROP tcp -- vlan2 any anywhere anywhere tcp dpt:webcache 0 0 DROP tcp -- vlan2 any anywhere anywhere tcp dpt:www 0 0 DROP tcp -- vlan2 any anywhere anywhere tcp dpt:https 0 0 DROP tcp -- vlan2 any anywhere anywhere tcp dpt:69 9 456 DROP tcp -- vlan2 any anywhere anywhere tcp dpt:ssh 0 0 DROP tcp -- vlan2 any anywhere anywhere tcp dpt:telnet Chain FORWARD (policy ACCEPT 5183 packets, 209K bytes) pkts bytes target prot opt in out source destination 1 137 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:61876 656 207K ACCEPT udp -- any any anywhere 192.168.1.26 udp dpt:10479 40785 16M ACCEPT 0 -- br0 br0 anywhere anywhere 20266 1034K TCPMSS tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU 1143K 363M lan2wan 0 -- any any anywhere anywhere 1124K 362M ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:52231 278 15513 ACCEPT tcp -- any any anywhere Coruscant tcp dpt:www 0 0 ACCEPT udp -- any any anywhere Coruscant udp dpt:www 3 180 ACCEPT tcp -- any any anywhere Endor tcp dpt:ftp 0 0 ACCEPT udp -- any any anywhere Endor udp dpt:fsp 9 396 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpts:1433:1434 1 404 ACCEPT udp -- any any anywhere Kashyyyk udp dpts:1433:1434 0 0 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpts:2382:2383 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpts:2382:2383 4 184 ACCEPT tcp -- any any anywhere Coruscant tcp dpt:https 0 0 ACCEPT udp -- any any anywhere Coruscant udp dpt:https 0 0 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpt:62917 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:62917 29 1524 ACCEPT tcp -- any any anywhere Endor tcp dpt:telnet 0 0 ACCEPT udp -- any any anywhere Endor udp dpt:23 0 0 ACCEPT tcp -- any any anywhere Coruscant tcp dpt:3784 0 0 ACCEPT udp -- any any anywhere Coruscant udp dpt:3784 49 2472 ACCEPT tcp -- any any anywhere Coruscant tcp dpts:5800:5900 0 0 ACCEPT udp -- any any anywhere Coruscant udp dpts:5800:5900 0 0 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpt:7777 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:7777 0 0 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpt:8777 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:8777 0 0 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpt:9777 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:9777 0 0 ACCEPT tcp -- any any anywhere Kashyyyk tcp dpt:27900 0 0 ACCEPT udp -- any any anywhere Kashyyyk udp dpt:27900 0 0 ACCEPT tcp -- any any anywhere 192.168.1.4 tcp dpts:9997:9999 0 0 ACCEPT udp -- any any anywhere 192.168.1.4 udp dpts:9997:9999 0 0 ACCEPT tcp -- any any anywhere 192.168.1.4 tcp dpt:1234 0 0 ACCEPT udp -- any any anywhere 192.168.1.4 udp dpt:1234 0 0 ACCEPT tcp -- any any anywhere 192.168.1.4 tcp dpts:5000:5001 0 0 ACCEPT udp -- any any anywhere 192.168.1.4 udp dpts:5000:5001 11 741 TRIGGER 0 -- vlan2 br0 anywhere anywhere TRIGGER type:in match:0 relate:0 18687 1008K trigger_out 0 -- br0 any anywhere anywhere 13515 799K ACCEPT 0 -- br0 any anywhere anywhere state NEW Chain OUTPUT (policy ACCEPT 147K packets, 29M bytes) pkts bytes target prot opt in out source destination Chain advgrp_1 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_10 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_2 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_3 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_4 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_5 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_6 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_7 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_8 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_9 (0 references) pkts bytes target prot opt in out source destination Chain grp_1 (0 references) pkts bytes target prot opt in out source destination Chain grp_10 (0 references) pkts bytes target prot opt in out source destination Chain grp_2 (0 references) pkts bytes target prot opt in out source destination Chain grp_3 (0 references) pkts bytes target prot opt in out source destination Chain grp_4 (0 references) pkts bytes target prot opt in out source destination Chain grp_5 (0 references) pkts bytes target prot opt in out source destination Chain grp_6 (0 references) pkts bytes target prot opt in out source destination Chain grp_7 (0 references) pkts bytes target prot opt in out source destination Chain grp_8 (0 references) pkts bytes target prot opt in out source destination Chain grp_9 (0 references) pkts bytes target prot opt in out source destination Chain lan2wan (1 references) pkts bytes target prot opt in out source destination Chain logaccept (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT 0 -- any any anywhere anywhere Chain logdrop (0 references) pkts bytes target prot opt in out source destination 0 0 DROP 0 -- any any anywhere anywhere Chain logreject (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- any any anywhere anywhere reject-with tcp-reset Chain trigger_out (1 references) pkts bytes target prot opt in out source destination
According to your route table, there isn't even an entry for loopback, so no wonder it is not working. If there was a loopback entry, a line like this should be in there: 217 14342 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 but there isn't an entry with 'lo' (loopback) interface.
Put this in and make sure you 'save firewall' and not save it as a start up script after you add it, reboot the router:
iptables -t nat -I POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE
I have the code in the firewall section.. and I still dont see any entries different than what I showed you before. Am I saving this incorrectly? I put the command in the Command Shell box, hit save firewall .. then I go to the management tab and reboot router. Here is a screenshot of the commands tab.
http://manchild.homeip.net/joseph/routerfirewall.jpg
It appears to be entered correctly, just still no loop reference, i'm gonna think on this and will post back when time permits. This is kinda stumbling me as to why it isn't working for you. One last curious question, in Security > Firewall, how is your WAN blocking setup?
Currently, I have the firewall disabled. If you would like to remote into this to get a better look, PM me, and I can get you set up.
Hey guys. Pardon me for jumping in on your party. :) I am having the same symptoms as JosephChild, but there may be something different going on with mine. I have the same firewall command entered, but my iptables -vL output does appear to have a loopback entry. However, it doesn't appear to be correct. Don't know if my input will help with JosephChild's problem or if they are totally separate. I'm on build 19484 and here's the output:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 27890 1745K ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 logdrop udp -- ppp0 any anywhere anywhere udp dpt:route 0 0 logdrop udp -- br0 any anywhere anywhere udp dpt:route 0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:route 0 0 logdrop icmp -- ppp0 any anywhere anywhere 0 0 logdrop igmp -- any any anywhere anywhere 6 422 ACCEPT 0 -- lo any anywhere anywhere state NEW 1494 155K ACCEPT 0 -- br0 any anywhere anywhere state NEW 349 45881 logdrop 0 -- any any anywhere anywhere Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT udp -- any any anywhere Jims-Mac udp dpt:5353 0 0 ACCEPT udp -- any any anywhere Jims-Mac udp dpt:4500 0 0 ACCEPT gre -- any ppp0 192.168.1.0/24 anywhere 0 0 ACCEPT tcp -- any ppp0 192.168.1.0/24 anywhere tcp dpt:1723 0 0 ACCEPT 0 -- br0 br0 anywhere anywhere 775 47332 TCPMSS tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN TCPMSS clamp to PMTU 102K 61M lan2wan 0 -- any any anywhere anywhere 101K 61M ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 TRIGGER 0 -- ppp0 br0 anywhere anywhere TRIGGER type:in match:0 relate:0 643 46023 trigger_out 0 -- br0 any anywhere anywhere 462 36815 ACCEPT 0 -- br0 any anywhere anywhere state NEW 181 9208 logdrop 0 -- any any anywhere anywhere Chain OUTPUT (policy ACCEPT 27326 packets, 5590K bytes) pkts bytes target prot opt in out source destination Chain advgrp_1 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_10 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_2 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_3 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_4 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_5 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_6 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_7 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_8 (0 references) pkts bytes target prot opt in out source destination Chain advgrp_9 (0 references) pkts bytes target prot opt in out source destination Chain grp_1 (0 references) pkts bytes target prot opt in out source destination Chain grp_10 (0 references) pkts bytes target prot opt in out source destination Chain grp_2 (0 references) pkts bytes target prot opt in out source destination Chain grp_3 (0 references) pkts bytes target prot opt in out source destination Chain grp_4 (0 references) pkts bytes target prot opt in out source destination Chain grp_5 (0 references) pkts bytes target prot opt in out source destination Chain grp_6 (0 references) pkts bytes target prot opt in out source destination Chain grp_7 (0 references) pkts bytes target prot opt in out source destination Chain grp_8 (0 references) pkts bytes target prot opt in out source destination Chain grp_9 (0 references) pkts bytes target prot opt in out source destination Chain lan2wan (1 references) pkts bytes target prot opt in out source destination Chain logaccept (0 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT 0 -- any any anywhere anywhere Chain logdrop (6 references) pkts bytes target prot opt in out source destination 530 55089 DROP 0 -- any any anywhere anywhere Chain logreject (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- any any anywhere anywhere reject-with tcp-reset Chain trigger_out (1 references) pkts bytes target prot opt in out source destination
In the immortal words of Rosanne Rosanadana : Nevermind! :) Maybe I had to wait for something to update/propogate. It seems to work now. Sorry for the interruption. We now return you to our regularly scheduled help.
Best of luck with your problem JosephChild.
I have same problem as Joseph.
Hi guys just looking for some help regarding Loopback.
My router setup is a little unique so please bare with me.
One of my router (Router B) has an IP of 192.168.2.1 - (Router C) has an IP of 192.168.2.100
Router B and Router C are connected Wirelessly using WDS, with Router B assigning IP addresses. All of this works great.
Here comes the difficult part.
Connected to Router B is Router A (IP 192.168.1.1). Router A is NOT a DD-WRT router, however Router A is the primary router for the Internet, which Router B is connected to.
The reason why this is, is becuase Router B is used as a VPN Client, this also explains the different subnet, as Router A has nothing to do with the VPN (I don't need it to), and Router B is the VPN Client.
Therefore if I connect to Router A i'm NOT using VPN, and if I connect to Router B / C I am using VPN.
Heres the problem;
One of my Computers is connected to Router A, and if I try to FTP I get timeout errors. Connecting to the devices, browsing the file directory isn't a problem only FTP.
If i add the following command to Router B (DD-WRT Router) FTP works great, from my computer which is connected to Router A (Regular Router)
iptables -t nat -I POSTROUTING -o br0 -s 192.168.1.1/24 -d 192.168.2.1/24 -j MASQUERADE
Adding this command seems that everything is work great and its all fixed. However when adding this command, anything connected to Router C (192.168.2.100) looses connection to any NAS devices connected to Router B (192.168.2.1).
Example:
Before adding the command to the firewall on Router B, my Apple TV (connected to Router C) can connect to all NAS Devices on both Router B / C
After adding the command to the firewall on Router B, my Apple TV (Conected to Router C) CANNOT connect to any NAS devices on Router B.
Of course removing the loopback command from the firewall fixes everything, but then I'm back to the problem of not being able to FTP.
I know for some of you this seems a vert strange setup, and maybe a little complicated, however it does need to be like this. Any help regarding this loopback problem would be great.
Is there anything needed ot be added on Router C?
I'd be happy to explain anything more if needed.
Your problem really doesn't reside in a loopback functionality. Your problem is more needing to create static routes between subnets. And honestly, this thread should be closed now, loopback has been fixed in dd-wrt for some while now.
buddee wrote:Right, you should try setting static leases thru DHCP on the router, not the devices, this way the device will have a static ARP binding and be able to be found in the router's routing table, when you set a hardware IP within the hardware itself, it communicates to the router somewhat transparently, because there is no table for the router to follow nor does it have to because you choosen another method externally and not using the router. Not saying this is going to yield promise, but its worth a try and it something i noticed some while back, so now i use the router to assign static DHCP ip's and have no problem with loopback.
Buddee, your advice to get fixed IPs via the router and NOT by setting the network device properties seems to have sorted a problem I've had for a looooong time. My main desktop has a mail server and other stuff running on it so I need a fixed IP and port forwarding. The old Linksys advice was to set fixed IPs outside the range assigned by DHCP, and set them on the machine (not the router), so I've done this since I started networking. I'm now using WDS with two DD-WRT'd routers and mostly it worked fine. Sometimes though DLNA wouldn't work across the link, though it worked on traffic going through a single router. I adjusted every setting possible, and came up with special sequences for switching on the routers, servers and DLNA player, but the bottom line was sometimes it worked and sometimes it didn't. Then I got a Raspberry Pi OpenElec media player, and used a fixed IP again as this was supposed to give easier WiFi connection (plus it's easier to SSH, or WinSCP into it if the IP is fixed). WiFi was fine, but sometimes I couldn't ping it, even using IP and not the name. This meant I couldn't administer it over SSH. I'd got as far as noticing arp -a didn't show up the openelec name next to its IP, but being unable to ping something on the same subnet drove me nuts. Then I saw your post and thought it worth a try. All devices where I want a fixed IP now have that assigned, within the DHCP range, by the host router, which does seem to force it to recognise the link between MAC, IP, and hostname. Like I say, I've had this issue for a long time, and it appeared somewhat randomly, so I'm reluctant to declare a complet fix just yet, but I think we might be there. This advice for getting a fixed IP should be much more widely disseminated. Thank you!!