What FireWall setting will allow SMTP Server connection?

Windows Server 2008.

Pair of Mac-heads (me and my own cllient) trying to figure out what bloody setting to use in the freaking firewall to permit a service running on the server to communicate with an external SMTP Server. The external SMTP server uses port 2525.

Tried to no avail: Two new inbound rules.

Protocol type TCP, Local port 2525, remote port All Ports, scope Any to Any IP address, apply to all programs and services, profile = “these profiles: Public”, all interface types, Enabled, Allow the connection.

Protocol UDP, otherwise totally identical to the TCP one above.
Tried and works fine but not a viable solution to the problem: Disabling windows firewall altogether.

The exact same process/service running on a different hostbox elsewhere sends the email with no problem. Disabling firewall results in the email going through from this box, no problem. Any clue as to what we should futz with on this blasted firewall to get it to stop blocking those emails from going through?

Outbound (i.e. your server sending out emails from your internal system) you shouldn’t have to do anything (with the firewall) to connect to the SMTP server (you may need to authenticate with the server, but it won’t matter to the firewall) unless you have specific rules blocking those ports for outbound traffic. Inbound (i.e. the external server sending your server email coming in from the internet) you will have to set up a port forward. The standard SMTP port is 25, but if they are using 2525 then set up a port forward for inbound traffic that comes in on that port to be forwarded to your SMTP server.

(if you completely disabled the firewall both inbound and outbound, your problem might have been with NAT…or there is an authentication step your server needs to go through to connect. I’m not sure how Mac’s work, but in exchange you can set up a connector with authentication creds if that’s what’s needed).

ETA: This all assumes you have your MX record(s) and PTR record(s) set up correctly btw.

-XT

It’s outbound traffic; the SMTP Server will be used by a service on the WinServer2008 box to send mail from that box to some totally external location.

Authentication is required, account and plain password to make use of the SMTP Server. I would assume that means some back and forth chatting. I know when my own local computer negotiates with an SMTP server, Eudora reports on a back and forth conversation in which local computer says “I want to send mail”, SMTP Server says “AUTH?” and local computer says “Account” and “Password” and SMTP Server says “proceed” and local computer says “here you go” followed by the emails going outbound.

If I’m understanding you correctly then unless you have totally locked down your firewall to disallow outbound traffic, you shouldn’t need to do anything to the firewall at all. As long as it’s part of a transaction initiated by your internal server the traffic should be allowed by any firewall that doesn’t specifically block outbound ports or addresses. It’s only when transactions are initiated by external sources that you need to get into modifying your firewall.

There are of course other variables. Sometimes with SMTP you have the external service ‘call back’ outside of the initial transaction. IOW, you initiate an authentication session and then the external server will ‘call’ your server to verify the transaction. That would mean it would need you to pass that transaction through your firewall to your server. In which case you would need a port forward (or use a DMZ) that allows specific ports coming in from outside your firewall to be forwarded to your email server.

If it’s not working I’d try forwarding the standard SMTP port as well as the port they say they are using to your server and see if that works. There are better ways to figure all this out if you know how to use a packet sniffer and if your firewall has some monitoring features, but if not that would be the place to start. If it still doesn’t work then my guess is that it’s something in the authentication and isn’t related to the firewall. Your best bet in that case is to call the vendors tech support and work through getting connected with them if you don’t have access to more advanced tools. I’d probably go that route, as I’ve found it generally saves time, even if working with vendors tech support can be extremely frustrating at times.

-XT

English translation please.

The firewall is doing something wicked and undesirable, since turning the firewall off results in the emails going through.

I know about port forwarding in the same sense that I know about triple bypass surgery. I can tell you what either one of them is done for but that doesn’t mean I know how to do either one myself. It’s something that is, or is not, done in/via/through the Windows firewall settings?

Ah…sorry about that. I didn’t mean to do the whole techno-babble thingy.

Um…ok. Let’s see if I can explain this well in English. Basically, when you have a workstation or server inside your firewall (i.e. on your side of the firewall), most firewalls simply let the traffic out unless specifically told not too. My guess is that your firewall is pretty much out of the box, so it will allow traffic coming from your network and out to the internet out without any problem. So, if you go to YouTube you can click on a link and watch a video…or go the the StraightDope and view a thread. Whatever you like. If you set up a workstation to go out and collect SMTP mail from an external email system it will go out and get it…the firewall won’t care, since the traffic is initiated from inside your network.

The trouble comes when traffic that is initiated from outside your network is trying to get inside. Like, say, if you have an external email host that is trying to forward SMTP to your internal server using your public IP address, or if you have a Mail Exchange (MX) record that points to either one of your public IP addresses (if you have a block of public addresses) or to the public IP of your firewall. If this happens then the firewall, by default, will not let the packets inside your network. That’s what it’s designed to do after all. So, you have to tell the firewall to forward the packets coming into your firewall to a server or workstation inside your network. One of the ways to do this is a port forward…basically, you tell your firewall to take any IP traffic that comes in on a certain port (like, say port 25 or 2525 as you were saying) specifically to one of your public IP addresses (or the external address of your firewall) and send it inside your network to your server.

As an example, let’s say your internal network is 192.168.0.0/24 (don’t worry about what all that means). And let’s say that your server’s IP address is 192.168.0.100. And let’s say that your pubic IP address of your firewall is 12.12.12.12. So, what you do is you set up on your firewall to forward traffic that’s coming into 12.12.12.12 on ports 25 and 2525 to forward to 192.168.0.100. That’s it. The syntax of doing this will depend on your firewall, but these days most of them have a browser interface, and usually their address is the .1 of the private network that they are dishing out addresses for. You can find out by checking out your workstation and looking for the gateway address (it might be called the default gateway or gateway of last resort) and then just putting that address into your internet browser. A lot of times port forwarding is under either routing or in advanced settings…you’ll probably have to play around with it some, or download a tech paper on it, or call their tech support and have them walk you through it.

Just a couple things about all of this. One is that this will obviously open a security hole into your network. It’s not a very big hole, but it is a hole and can be exploited. Another thing is that all this assumes you have your DNS records set up correctly to get the mail to you…or that you’ve given your external email provider or forwarder your correct information for your public IP address.

It also assumes this is the problem. As I said, it might be an authentication issue. If that’s the case, then your best bet it to call tech support from your provider and ask them to walk you through setting all this up.

Hopefully the above isn’t too confusing. Good luck. :slight_smile:

-XT

If I am not mistaken (and there is a good possibility that I am), AHunter3 is talking about a software firewall while xtisme is talking about the router (often built in to the “cable modem”). I have had issues where they were resolved by my turning off the software firewall (I use Zonealarm), but I have never turned off the router firewall (I would not even know how). The software firewall does interfere with outbound stuff. It is my understanding that that is their purpose.

If turning off the software firewall fixes the problem, I don’t see how the router could be involved. I would think that the solution would lie in telling the software firewall what to let in and what to let out. I have only done that by telling it trusted IP adresses.

Well…sort of. I’m talking about a firewall device (appliance or dedicated firewall server) though, yes. You can get a ‘cable modem’ (it could be broadband or DSL or a few other things) that has an integrated firewall these days (in fact, they generally come standard with a firewall built in), or it could be a firewall appliance (like a SonicWall, CISCO ASA or Pix, eSoft, etc)…even firewall software in a server (Gauntlet or Microsoft’s ISA product).

If the OP is talking about firewall software (like ZoneAlarm or Turtle or similar products) then it will depend on the software…but you still have to allow the traffic to come through. You could do this based on the IP address and ‘trust’ it, or you could still do it based on the port (and address…and make it authenticate as well, depending on how complex you want to get). I’ve used ZoneAlarm and it’s certainly capable of doing a port forward.

-XT

I’m talking about a piece of software that appears to be part and parcel of Windows Server 2008.

Oh…Windows Firewall? :smack::smack::smack: Sorry…I misunderheard you and ethelbert had it right. If turning it off makes it work, then you can basically use this link to walk you through modifying it to allow ports or IP addresses in. Or just turn it off if you have an appliance firewall.

Sorry about that.

-XT

I’m still slightly baffled as to why AHunter3 might need to allow any inbound connections, though. AIUI, the service on the Windows server is merely acting as a client to the external SMTP server. I wasn’t aware of this “call back” feature of SMTP, which seems to me like a recipe for failure, with so many clients being behind firewalls or NAT.
[edit] or do you mean address verification? But that’s something that happens between SMTP servers, I thought.

Can I start over? I don’t know much here except what I said in post #1 and the clarification that this is the built-in Windows firewall.

Turning it completely off lets the emails go through. They are being (/will be) sent from a service running on the WinServ08 box, the SMTP Server is external. I can’t find a setting that lets the email go through when the firewall is turned on. Help?

I think your best bet at this point is to go through the link xtisme supplied above. Apparently the Windows Server 2008 Firewall has a crapload of default rules. I suspect that one of these is responsible for your problem. If I were you, I would try to create a rule allowing traffic in and out to/from the IP address of the other server. I have no experience with that firewall.