| Linode Forum https://forum.linode.com/ |
|
| Reaching services from internal subnet via external address https://forum.linode.com/viewtopic.php?f=11&t=2831 |
Page 1 of 1 |
| Author: | zipflash [ Fri Aug 24, 2007 12:08 am ] |
| Post subject: | Reaching services from internal subnet via external address |
I have a Netgear firewall configured to forward 5 ports to a Debian server on the local subnet. From outside the firewall, all 5 services are accessible, and all else is blocked. All good. From inside the firewall, I can access all services via the server's subnet address, because this doesn't go through the firewall. Again, all good. Here is the puzzle. When accessing services from INSIDE the firewall, but using the EXTERNAL address of the firewall, some services are reachable (SMTP, HTTP, SSH), but some aren't (DRb, alternate SMTP). The two services that don't work were configured by me, implying the problem is with my configuration at the server, not the firewall. Problem occurs regardless of whether I bind those services to the local or external address, or to 0.0.0.0. Where did I go wrong? |
|
| Author: | SteveG [ Mon Aug 27, 2007 4:32 pm ] |
| Post subject: | |
Is the firewall blocking the "outgoing" packets for your extra services? Is the firewall configured to reject requests for (some, I suppose) external address/ports from internal address/ports? On a more general level, why do you want internal requests for internal services to go through the firewall's external addresses? If it's a naming issue, you might look at dnsmasq, which makes it easy to have internal addresses that are different than what the rest of the world sees. |
|
| Author: | zipflash [ Mon Aug 27, 2007 5:46 pm ] |
| Post subject: | /forums/viewtopic.php?p=12645#12645 |
Answering the general question first: goal is to use a laptop from anywhere with minimal reconfiguration. Home ISP blocks port 25. Cannot use the ISP's SMTP server because of our company's SPF/SenderID configuration (don't get me started). The issue with DRb is similar: would like to run debug and production code with the same configuration, i.e. using an external address. To solve the SMTP issue, I followed this linode post to set up an alternate SMTP port on our mailserver, which is not blocked by the ISP. Thus both port 25 and the alternate port are effectivly connected to the same listener. This works, except that, weirdly, port 25 SMTP works from either address, while the alternate port works only on the internal address. The firewall is configured identically for all services. General debugging question: what tools can I use to watch new connections into the server as they are made/refused, and thus get a sense of what's going on? Thanks! |
|
| Author: | SteveG [ Tue Aug 28, 2007 6:15 pm ] |
| Post subject: | |
Assuming the firewall is a Linux box running iptables, you should be able to turn on iptable logging; how you do this may depend on what particular FW sofwtare you're using (e.g. firehol, direct iptable commands, etc.) Also, run wireshark or tcpdump on the firewall, listening for packets from your laptop, to see if they're even reaching the FW. Oh, nevermind, you said "Netgear fw" in the first post, didn't you. Bugger. Does it have any logging options that look useful? Another idea to make your life harder: is it possible your packets are going through some internal router that is dropping packets with external addresses and port !25 and !80? Hm, tcptraceroute might be useful. That should let you see what path both successful and unsuccessful packets are taking. |
|
| Author: | zipflash [ Tue Aug 28, 2007 7:04 pm ] |
| Post subject: | |
Traceroute yielded a useful result. From behind the firewall, requests always route to the LOCAL destination address. E.g. traceroute -p [any_port] external_ip_address will follow a path through internal subnet(s) only, never through external_ip_address explicitly. So the FW apparently knows always to translate requests from within the subnet into a subnet destination, if possible. This, in turn, suggests the connection is rejected at the server itself. Could this be related to the vagaries of whether the service is bound to (or forwarded to) 127.0.0.1, vs localhost, vs the local IP address? I must confess these distinctions are not clear to me. |
|
| Author: | Internat [ Tue Aug 28, 2007 11:24 pm ] |
| Post subject: | |
Yes. If the service is bound to either localhost/127.0.0.1 then only things on that computer will get to it. It would need to be bound to the lan ip. or if your happy with it, dont bind to a specific ip, let evyerhting use it. |
|
| Author: | zipflash [ Wed Aug 29, 2007 12:34 am ] |
| Post subject: | |
I'm not knowingly binding to localhost or 127.0.0.1, but there seems to be something to this. I'll hunt around and then post results. |
|
| Author: | SteveG [ Wed Aug 29, 2007 5:47 pm ] |
| Post subject: | |
If a service is bound only to 127.0.0.1, then it wouldn't be available to any external client, so that's probably not it. zipflash wrote: Traceroute yielded a useful result. From behind the firewall, requests always route to the LOCAL destination address. E.g. traceroute -p [any_port] external_ip_address will follow a path through internal subnet(s) only, never through external_ip_address explicitly. So the FW apparently knows always to translate requests from within the subnet into a subnet destination, if possible. Huh? Is it possible to post an actual example of traceroute to both a working port and a non-working port? Feel free to obfuscate your public IPs, but do it consistently. zipflash wrote: This, in turn, suggests the connection is rejected at the server itself. Could this be related to the vagaries of whether the service is bound to (or forwarded to) 127.0.0.1, vs localhost, vs the local IP address? I must confess these distinctions are not clear to me.
127.0.0.1 == localhost, and is only accessible from the same machine. "local IP" usually means the machine specific IP, and behind a firewall is usually in the private IP space (e.g. 192.168.x.x, or 10.x.x.x, or whatever the other group is that I always forget). |
|
| Author: | zipflash [ Wed Aug 29, 2007 8:06 pm ] |
| Post subject: | |
What I wrote was wrong. The traceroute always shows all requests routing correctly. Sorry. The good news is, your pointing that out led directly to a solution. The problem was the Netgear firewall. After its last firmware upgrade, any newly created entries in the port forwarding services table will forward correctly from external addresses, but not from subnet addresses. Existing older entries continue to work normally. I was able to demonstrate this by editing pre-existing entries in the table. Any entry that existed prior to the firmware upgrade can be edited to forward any port or port range correctly from either internal or external addresses. But any entry newly created after the firmware upgrade can only forward from external addresses. These entries are configured identically in all other ways. The workaround was just to "move" the services needed both internally and externally to the existing older port forwarding table entries. This works. This, in turn, led to the Netgear firmware upgrade page. Sure enough, shortly after our last firmware upgrade, there was a bug fix release that we missed. This is all sufficiently creepy to make me want to build a Debian router at first opportunity. But the immediate problem is solved. Thanks for your help. |
|
| Author: | SteveG [ Fri Aug 31, 2007 2:16 pm ] |
| Post subject: | |
You're welcome -- glad you got it working. What a weird bug. If/when you do build a Debian firewall, take a look at "firehol". It's very straightforward, and unless you have a *very* unusual configuration, has all the power you need. Shorewall works well to, but I found the config overly complex for my needs. |
|
| Page 1 of 1 | All times are UTC-04:00 |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|