Reaching services from internal subnet via external address
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?
9 Replies
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.
To solve the SMTP issue, I followed this linode post
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!
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.
traceroute -p [anyport] externalip_address
will follow a path through internal subnet(s) only, never through externalipaddress 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.
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.
@zipflash:
Traceroute yielded a useful result. From behind the firewall, requests always route to the LOCAL destination address. E.g.
traceroute -p [anyport] externalip_address
will follow a path through internal subnet(s) only, never through externalipaddress 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: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).
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.
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.