iptables, port forwarding, and access from LAN-side
Nothing like firewall rules to make me feel like a moron. I recently wiped and reinstalled OpenWRT on my WRT54G router. Before the wipe, I had firewall rules which forwarded port 80 to a web server on my home LAN behind the router.
The nice part was that I could access that server both from outside and inside the LAN, using the external WAN IP. I've got scraped RSS feeds and other HTTP accessible bits that I access from my laptop. This laptop travels between work and coffee shop and home. I like being able to subscribe to and point at these things by URLs that don't change.
But now, after the wipe, I've got firewall rules which open the WAN port to the home LAN for access from outside - but not from inside. I've lost the old rules, and the knowledge I had that let me build the rules has since paged out of my brain and been lost to the ether.
I suppose I could try building a VPN to home again - or use some SSH port tunneling - but I'd really like to get this port forwarding working again. Anyone know how this crud works?
What does OpenWRT get you that the stock factory firmware doesn't? Personally I've been very happy with the official firmware and it's nice easy web-based configuration which also happens to support everything I need out of a router (port forwarding, access control, QoS, etc.)
Just in case I'm a bit dim, why would you not refer to the machine by name? I appreciate the cleverness with IPs was a nice thing to do, but wouldn't it be easier to just call it home.decafbad.com wherever you are (and have that resolve to the internal IP address of the box inside the network and the external address outside)?
fluffy: Eh, OpenWRT lets me meddle, first of all (see this post).. But, second, it's got some traffic shaping stuff I've been learning about, can run a VPN connection, and let's me SSH in to a screen session to check on some other machines at home. Between this and my NSLU2, I don't have a PC home linux server anymore. (Of course, I haven't checked out the factory firmware in awhile, so they may have made some updates I haven't seen.)
Stuart: I did just that at one point, by running a DNS proxy on the home LAN that gave an internal IP answer for the equivalent of home.decafbad.com - while the rest of the world saw the WAN address. I think I did it with tinydns, but I seem to remember it was a pain in the butt for some reason. I should check it out again.
This is the reason I've got a wiki on my home network I store all the little notes and config stuff in. It's on the Linux box I never tinker with, so I'm sure not to wipe it out. (I also do some minimal backups as well in case of trouble.)
OpenWRT may offer this, but this is what I do with m0n0wall, which I have running on one of those little dedicated WRAP boxes - it can run a DNS forwarder for the internal boxes that are accessing the world. In other words, it runs as a DNS cache from whatever your external DNS is, and then can inject any custom entries you want. Then configure DHCP or any internal static IP boxes to point at the router as a DNS server. Then you can setup overriding rules for any DNS entries that refer to your home external IP.
You also stated you access it via your "external IP" - are you not using a dynamic DNS service like DynDNS to give your home an external domain? You could even then use a real DNS provider to make a nicer domain (say a subdomain of your website) be a CNAME pointing at the DynDNS entry. m0n0wall and many other routers also have DynDNS clients built in. Who needs static IPs? You certainly don't if all you need is web and ssh access.
So for example, I may have an internal web server running at 192.168.1.10, with my external IP being 188.8.131.52. So I have home.cafgood.com as a CNAME pointing at cafgood.dyndns.com which gets automatically set to resolve to my external home IP (184.108.40.206). On my router, I then say home.cafgood.com equals the internal IP (192.168.1.10). From the outside, I would hit real DNS servers, get CNAME-pointed to DynDNS servers, which would point me at my external IP, and NAT points at the web server. From the inside, the overridden DNS forwarder would just point any internal request right at the web server.
Okay, addendum summary: I'm already using DynDNS to point at my home address, my external IP. I've used a DNS cache that substituted a LAN IP for that domain name for LAN clients in the past and didn't like it. Up until this week, my firewall rules allowed port 80 on my external IP to respond to traffic from the WAN and the LAN interfaces. But now, those rules are gone and I don't remember what the magic invocation was in iptables.
Bah, I'll probably just end up going back to a DNS cache.
Oh, holy hell. I can't figure out the proper iptables arrangement - which still bugs me - but I did discover that my router's running dnsmasq and that the following line in
/etc/dnsmasq.confdid the trick:
Still feeling like a moron.
Feel like a moron no more :o)
I believe what you are looking for is something like the following two rules:
1.) $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
2.) $IPTABLES -A FORWARD -i $EXTIF -o $INTIF -p tcp --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
I hope that helps!
iptables -t nat -A PREROUTING -p tcp -d 220.127.116.11 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10
iptables -t nat -A POSTROUTING -p tcp --dst $HTTPIP --dport 80 -j SNAT --to-source $LANIP
iptables -t nat -A OUTPUT --dst $INETIP -p tcp --dport 80 -j DNAT --to-destination $HTTPIP
Check http://iptables-tutorial.frozentux.net/chunkyhtml/x4013.html for explanations of the lines above. Another good reference is http://tldp.org/HOWTO/IP-Masquerade-HOWTO/index.html (and http://www.openbsd.org/faq/pf/rdr.html if you are on BSD). The DNS solution seems better since it won't harm your logging.
i had the same issue after upgrading from rc4, the easy solution is to add a rule for your local subnet and have it forward to your destination.
This web page has a working example. I've included the link to give credit where it is due, and for context.