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?

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.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.
-- seen on the net

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!

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.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net

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.

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.

_________________
ServerAdmin - www.our-lan.com
"Diplomacy is the art of saying nice doggy whilst looking for a really big stick"
"In my experiece, any attempt to make any system idiot proof will only challenge God to make a better idiot"

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.

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.


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.


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 irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net

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.

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.

_________________
The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world.

-- seen on the net