Re: SMTP and tcp ports
- From: News Reader <user@xxxxxxxxxxx>
- Date: Wed, 30 Apr 2008 21:36:04 -0400
Bob Simon wrote:
We've got two sub-threads going here which makes this a bit ackward.
I will avoid this in the future. In addition, I believe I reported
incorrectly earlier. Please let me try again.
Two days ago, the only smtp ACE was "access-list 102 permit tcp any
host 192.168.0.20 eq smtp". With this, we were able to receive mail
but could not send mail out.
One of your paragraphs below requests interpretation of the ACLs so I'll do so. As you stated earlier, ACL 102 is applied inbound on the external interface (correct me if I am wrong).
A modest (no embellishments) extended ACL takes the form:
action, protocol, source, qualifier source-port, destination, qualifier destination-port
If you leave out the source or destination ports and their qualifiers, those criteria are not used in evaluating a match.
permit tcp any host 192.168.0.20 eq smtp
The ACE above (lets call it ACE #1) "permits" "any external host" (due to where you applied the ACL), with any source port (because you haven't specified one), to connect to "host 192.168.0.20" on "TCP destination port 25" (i.e.: specified with smtp keyword).
This ACL would permit access to the internal SMTP server (listening on TCP port 25) from external clients and servers. The mail clients would be using a TCP source port >1023, and external mail servers would be using TCP source port 25, or TCP source port >1023 (I'm not sure which, but would have expected TCP source port 25). Both would get through because your ACE is not evaluating the source port.
You were successful in receiving mail from outside sources because ACL 102 permitted the inbound connection, and you addressed return path requirements (perhaps with ACLs, or with Inspection).
Yesterday, I removed that statement and replaced it with "access-list
You removed the statement that facilitated inbound connections to the SMTP server from "any source port".
102 permit tcp any eq smtp host 192.168.0.20". I can't recall whether
.... and replaced it with an ACE (lets call it ACE #2) that required a "source port of 25".
This ACE prevents e-mail clients from accessing the server (they use source port >1023).
This ACE may or may not prevent external SMTP servers from accessing the server depending on the answer to our earlier question (i.e.: does the external server use source port 25, or a port >1023). See below for a determination.
More on ACE #2 to follow below.
this resulted in not being able to send mail or not being able to
receive mail but it was one of these. When I added "access-list 102
permit tcp any host 192.168.0.20 eq smtp log" everything worked.
ACE #1 restored your ability to receive inbound connections "initiated" from both external clients and servers (no source port requirement defined).
If both ACLs were required for full functionality, that suggests that ACE #2 is impacting outbound mail. Since this ACE is applied inbound on the outside interface, this suggests that the ACE is addressing the return path for outbound connections. This suggest that you are not utilizing "inspection" to your advantage.
permit tcp any eq smtp host 192.168.0.20
ACE #2 is matching connections with a "TCP source port 25" (i.e.: an external SMTP server). This affirms my belief that server-to-server exchanges would occur port 25, to port 25.
The absence of ACE #2 would prevent your internal server from successfully establishing a TCP connection with an external SMTP server.
I would create an ACL on the inside interface to facilitate outbound connections, and use inspection to facilitate the return path. Similarly, I would create an ACL on the outside interface for inbound connections, and use inspection to facilitate the return path.
If you don't mind, please explain why the various ACEs blocked either
inbound or outbound mail. What is the simplest safe way to set up the
ACL properly?
1. Get to know your applications (i.e. the source and destination ports used).
2. Start with connection initiation from a client with a specific protocol/application, and provision for the outbound connection with ACLs.
3. Address the return path (typically provisioning with inspection).
4. Are clients on both the internal and external interfaces? If so provision for each. You need to examine all scenarios to get it under control.
5. Move on to the next protocol.
6. etc.
You should document what you know about each protocol and its requirements, and how each protocol is provisioned.
There are two MX records. Does that mean that *all* incoming mail
will be sourced from one of these hosts?
Sourced?
If the MX records are under your domain, I believe they would convey the IP addresses of your "receiving" SMTP servers to those who query for this info.
Will outbound mail exchange sessions always be with *only* the ISP's
smtp server?
Depends on the configuration. It is conceivable that it could be configured to forward mail through an ISP's SMTP server on its way to final destination. It is also conceivable that your server would forward to the recipients SMTP server. You'd have to examine the configuration of the server.
Has the ISP provided you with a pool of IP addresses, and are they performing static one-to-one translation with your internal hosts? If so, you would want to take steps to minimize the ports available on the SMTP server from outside hosts. A one-to-one mapping would expose all ports on the SMTP server.
We have a block of 16 public IP addresses. About half of these are
mapped to inside servers, including the Exchange server. I understand
the issue you raised about all the ports being open. This is why I
want to implement a better ACL.
In addition to the static translations, the ISP configured "ip nat
inside source list 1 NAME overload" for all the PCs on the inside. We
are doing no translation on our routers.
With an edge router managed by the ISP, I would assume that Port Address Translation (PAT) is not being used. PAT (NAT overload) translates all (or a subset of) internal addresses to a single external IP address. In such a scenario, you would need to establish a port specific translation such as the one above, which would forward inbound connections to TCP port 25, to the internal SMTP server.
PAT can be used along side static and dynamic NAT pools as well, but it is doubtful that this scenario would exist without your knowledge/involvement).
Please see my reply to the other post.That port is being committed for that purpose.Thank you. This was helpful, but I still have a bit of confusion
Any inbound connection setup would be directed at port 25.
Outbound SMTP connections from your server to an Internet-residing server would be from source port 25 with returning traffic coming to destination port 25.
With regard to random PAT ports, consider the following:
An internal client initiates a connection with source port 1200 to a server on the web. The packet is forwarded by the NAT router with source port 1200.
A second client initiates a connection with source port 1200 (coincidence) to any resource on the web. The NAT router will forward the packet with a "random unused source port" NOT involved in a pre-existing translation.
A random port is used when the desired source port is already being translated.
The random source ports (destination ports on the return path) aid PAT in associating returning packets with the correct internal host.
about source and destination well-known ports that I mentioned in the
previous reply. Can you help me clear this up?
Best Regards,
News Reader
Best Regards,
News Reader
.
- Follow-Ups:
- Re: SMTP and tcp ports
- From: News Reader
- Re: SMTP and tcp ports
- References:
- Re: SMTP and tcp ports
- From: Bob Simon
- Re: SMTP and tcp ports
- Prev by Date: Re: SMTP and tcp ports
- Next by Date: Re: SMTP and tcp ports
- Previous by thread: Re: SMTP and tcp ports
- Next by thread: Re: SMTP and tcp ports
- Index(es):
Relevant Pages
|