SMTP and tcp ports

SMTP and tcp ports
NewsGroups | Search | Tools
User Password
Register Now! Lost Password?
 comp.dcom.sys.cisco  Post an article  get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content  add this group's latest topics to your Google content  YahooMyWeb Yahoo!  Google Google  Windows Live Favorites Windows Live  del.icio.us del.icio.us  digg digg  Add to Netscape Netscape
Subject Author Date
SMTP and tcp ports Bob Simon 04-30-2008
Posted by News Reader on April 30, 2008, 6:37 pm
If you were  Registered and logged in, you could reply and use other advanced thread options

>> Since ACE #60 would match both connection types, you could eliminate ACE
>> #50.

>
> The customers called me because they were not getting their mail so I
> added the other ACE with source port eq smtp. If I placed the new
> statement AFTER the old statement would it have received no hits?

I'm not sure which you are referring to as old vs. new.

Since they are both permit ACEs, with no deny ACE between them, changing
the order of the ACEs would only change the order in which they were
evaluated against inbound packets. The functional results would be the same.

However, it would have been beneficial for you to have changed the order
of the ACEs first, and monitored the resulting matches, rather than
deleting ACE #50.

Had you done so, matches on the resequenced ACE would have demonstrated
that both ACEs were required to retain functionality, and your customer
would not have experienced a service interruption.

Best Regards,
News Reader

Posted by Bob Simon on April 30, 2008, 8:19 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
wrote:

>
>>> Since ACE #60 would match both connection types, you could eliminate ACE
>>> #50.
>
>>
>> The customers called me because they were not getting their mail so I
>> added the other ACE with source port eq smtp. If I placed the new
>> statement AFTER the old statement would it have received no hits?
>
>I'm not sure which you are referring to as old vs. new.

In this context, I meant the ACE with seq # 50.
>
>Since they are both permit ACEs, with no deny ACE between them, changing
>the order of the ACEs would only change the order in which they were
>evaluated against inbound packets. The functional results would be the same.
>
What I meant was, since you said that I only needed seq # 60, if it
were first then 50 would get no hits. Isn't that correct?

>However, it would have been beneficial for you to have changed the order
>of the ACEs first, and monitored the resulting matches, rather than
>deleting ACE #50.
>
>Had you done so, matches on the resequenced ACE would have demonstrated
>that both ACEs were required to retain functionality, and your customer
>would not have experienced a service interruption.

I understand. Thanks.

Posted by News Reader on April 30, 2008, 12:30 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Bob Simon wrote:
> I have an access list applied inbound on the outside interface of a
> 2600 connected to the edge router. I found that I needed smtp ACEs
> for both the source port and for the destination port to our exchange
> server.
> 50 permit tcp any eq smtp host 192.168.0.20 (99012 matches)
> 60 permit tcp any host 192.168.0.20 eq smtp log (880 matches)
>
> Why is this? I thought inbound traffic to the server would be on
> random destination ports allocated by PAT on the edge router; no?

You have static NAT setup for the SMTP server don't you?

e.g.:        ip nat inside source static tcp 192.168.0.20 25 interface
<external-interface> 25

That port is being committed for that purpose.

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.

Best Regards,
News Reader

Posted by Bob Simon on April 30, 2008, 2:36 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
wrote:

>Bob Simon wrote:
>> I have an access list applied inbound on the outside interface of a
>> 2600 connected to the edge router. I found that I needed smtp ACEs
>> for both the source port and for the destination port to our exchange
>> server.
>> 50 permit tcp any eq smtp host 192.168.0.20 (99012 matches)
>> 60 permit tcp any host 192.168.0.20 eq smtp log (880 matches)
>>
>> Why is this? I thought inbound traffic to the server would be on
>> random destination ports allocated by PAT on the edge router; no?
>
>You have static NAT setup for the SMTP server don't you?
>
>e.g.:        ip nat inside source static tcp 192.168.0.20 25 interface
><external-interface> 25

Yes, but NAT is handled by the edge router, which is managed by the
ISP, so I can't see exactly what is going on in that box.

>
>That port is being committed for that purpose.
>
>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.
>
Thank you. This was helpful, but I still have a bit of confusion
about source and destination well-known ports that I mentioned in the
previous reply. Can you help me clear this up?

Posted by News Reader on April 30, 2008, 3:46 pm
If you were  Registered and logged in, you could reply and use other advanced thread options
Bob Simon wrote:
> wrote:
>
>> Bob Simon wrote:
>>> I have an access list applied inbound on the outside interface of a
>>> 2600 connected to the edge router. I found that I needed smtp ACEs
>>> for both the source port and for the destination port to our exchange
>>> server.
>>> 50 permit tcp any eq smtp host 192.168.0.20 (99012 matches)
>>> 60 permit tcp any host 192.168.0.20 eq smtp log (880 matches)
>>>
>>> Why is this? I thought inbound traffic to the server would be on
>>> random destination ports allocated by PAT on the edge router; no?
>> You have static NAT setup for the SMTP server don't you?
>>
>> e.g.:        ip nat inside source static tcp 192.168.0.20 25 interface
>> <external-interface> 25
>
> Yes, but NAT is handled by the edge router, which is managed by the
> ISP, so I can't see exactly what is going on in that box.

The information you provided lead me to believe that you were
successfully connecting to your internal SMTP server from outside
clients and servers. Correct me if I am wrong.

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.

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).

>
>> That port is being committed for that purpose.
>>
>> 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.
>>
> Thank you. This was helpful, but I still have a bit of confusion
> about source and destination well-known ports that I mentioned in the
> previous reply. Can you help me clear this up?

Please see my reply to the other post.

Best Regards,
News Reader

Similar ThreadsPosted
close ports and limit port smtp August 21, 2006, 9:52 am
PIX506 DNS SMTP March 10, 2005, 1:25 am
PIX / SMTP question - Help? January 5, 2006, 10:04 am
PIX firewall 6.3 and SMTP February 22, 2007, 6:37 pm
Pix 506 - Fixup SMTP August 26, 2008, 5:30 am
block smtp traffic December 28, 2004, 9:40 pm
Blocking SMTP traffic February 1, 2007, 5:22 am
Problems with pix firewall and SMTP May 17, 2007, 11:59 am
ASA 5505 problem with smtp May 5, 2008, 8:42 am
SMTP proxy to another Internet host July 19, 2004, 2:24 am

other useful resources:
The Federal Communications Commission (FCC)
Telecommunications Industry Association
Electronic and Software Security Products and Services
International Telecommunication Union

Custom CGI Perl and PHP programming by 1-Script.com

Contact Us | Privacy Policy
The site map in XML format XML site map