cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2607
Views
5
Helpful
18
Replies

NAT-PAT (covert SMTP port to another port)

ceaton333
Level 1
Level 1

Is there a quic and dirty way to convert port 25 incoming from the outside via PAT to another port (2025) on the inside?

We have an ASA5520 and we have a static NAT for our mailserver as well as the security rule that allows port 25 traffic in from a certain destination to our server on port 25 only.

I edited the NAT statement that is already in there to enable PAT to translate all port 25 from the outside

to port 2025 on the inside. It doesn't seem to want to translate the port though. I know this because when I turn of port 25 (receive) on the mail server I get no mail....turn it back on 25, I get mail, so no port translation is happening..

Any ideas?

1 Accepted Solution

Accepted Solutions

yes, or you could have a separate NAT for inside >> outside communication

like:

nat (inside) 1 mail-server-private-ip

global (outside) 1 some-other-public-ip

This might have to be a different public than the one used in the static, but you can try that same IP also, however most probably it will give a 'conflict with existing static' sort of message

Regards

Farrukh

View solution in original post

18 Replies 18

acomiskey
Level 10
Level 10

It should look something like the following...

static (inside,outside) tcp 25 2025 netmask 255.255.255.255

Corret. Actually, that is exactly what it looks like in my config...

Seems simple to me, and should work.

What happens when this PAT is in place is...

1. inside mail server cannot send outside the network on 25 or 2025. Which makes no sense...I must be missing something about how SMTP works..

2. inside mail server receives SMTP just fine, but only on port 25. This kinda makes sense in that SMTP from the outside is on port 25, and is allowed, so I assume it's just not translating it but just works anyway.

If your mail server daemon is listening on 2025 then there should be no problems here, just try the following (IF you are using the same interface as the outside IP of the firewall):

static (inside,outside) tcp INTERFACE 25 2025 netmask 255.255.255.255

Remove the outside-IP in the static statement and put the 'interface' keyword instead.

Regards

Farrukh

OK. I tried that INTERFACE 25 command and it did not work. Same results......cannot send out-going (cannot connect to external smtp servers) from inside port 25 nor 2025.

Here's what the regular NAT (without PAT) statement looks like...

static (inside,outside) Boimail-Out boimail netmask 255.255.255.255

...all on port 25 of course, everything is fine. if you put in PAT, it just won't connect from the inside out to another smtp server after you put in the PAT or the INTERFACE 25 commands...

Could it be security? We allow traffic to come in from a specific range source if the destination is our outside-e-mail address on port 25 only. Do I need to put in another statement to allow port 2025? I'm just assuming since the traffic already comes in on 25 and then is translated that the security would be fine...

Here's the security statement..

access-list OutsideIn extended permit tcp object-group Admin-Email-Servers object-group Email-Server-Out object-group SMT

P-TCP

No, you don't need to add an acl entry for 2025.

When you switch this PAT (from port 25 to 2025), do you change the port the mail service is listening to?

Also once you do the PAT, why don't you try to run the packet-tracer command, it really is amazing and mostly helps (except a few rare occasions pertaining to the AIP modules, multiple contexts etc.)

I would recommend to test using the 'packet-tracer' in both directions (inside to outside and vice versa)

Regards

Farrukh

Yes. Our e-mail server is listening on port 2025 and 25. I just did the PAT change again to translate 2025 from the inside to 25 on the outside and sent e-mail (telnet) outgoing on both ports 25 and 2025 and cannot connect.

I ran the packet tracer and it says that the traffic from our mail server outgoing on both 25 and 2025 is blocked by the implicit ACL that denies any any incoming. ?????

I thought that if the traffic was established on the inside then it should allow it back in?

On which interface is the packter-tracer showing the ACL block (inside or outside)?, do you have an ACL on the inside interface? If there is, is it possible to paste a sanitized version?

Regards

Farrukh

The block is on the OUTSIDE interface.

On the inside interface are the default implicit ACLS.... any any to any less secure net and then the deny any any ip.

On the outside, at the end of all the other "allowed" acls is also the implicit deny any any IP ...

See the problem is that your static statement does not cover what you are trying to test:

"I ran the packet tracer and it says that the traffic from our mail server outgoing on both 25 and 2025 is blocked by the implicit ACL that denies any any incoming. ?????"

Your static statement reads:

Outside >> Inside (Reverse Flow of command)

Any traffic having destination = mail-server-public-IP and port = 25 > translate destination IP to >> mail-server-local-IP and change destination port to 2025

Inside >> Outside (Actual Flow of command)

For any traffic having source IP = mail-server-local-IP and source port = 2025, change source IP to >> mail-server-public-IP and change SOURCE port to 25.

So there is really no 'outgoing' traffic on port 2025 from mail-server-local-IP going out......

You have to test like this:

packet-tracer input outside tcp 1025 25 detailed

OR

packet-tracer input inside tcp 2025 25 detailed

Let me know the results for both, if possible paste the sanitized output

Regards

Farrukh

OK. Thank you for all the response.

I will continue this tomorrow!

:-)

OK. I did the packet traces as you say, with the correct interface inputs chosen. I found that 1/2 of the problem is an ACL. We get our Internet SMTP mail from "Admin-Email-Servers" and so we only allow from those IP's only to a destination of port 25. So, I copied the same ACL and just changed the port to 2025. So, with the new NAT/PAT translation going on, we were able to receive incoming SMTP on port 2025.

However, I still cannot send SMTP from inside to outside (to the Internet). Whenever I change the NAT statement to add PAT from..

static (inside,outside) Boimail-Out boimail netmask 255.255.255.255

to..

static (inside,outside) tcp Boimail-Out 25 boimail 2025 netmask 255.255.255.255

I cannot telnet into any Internet SMTP server using port 25 or 2025... with the following command... telnet 67.29.153.40 25

or telnet 67.29.153.40 2025

Which means I cannot send mail outgoing.

As soon as I take the PAT stuff out, I

can telnet to 25...

And if I do a packet trace on this....

packet-tracer input inside tcp 2025 25 detailed

like you say.... it says that the packet is allowed. But this is only one direction. And of course packets aren't making it back for some reason..

Is there a way with packet tracer to tell it analyze the already ESTABLISHED (ACK) traffic from the opposite direction like...??

packet-tracer input outside tcp 25 2025 detailed

Here are the two access lists on the outside interface that allow for incoming SMTP just fine...

access-list OutsideIn extended permit tcp object-group Admin-Email-Servers object-group Email-Server-Out object-group SMTP-TCP

access-list OutsideIn extended permit tcp object-group Admin-Email-Servers object-group Email-Server-Out eq 2025

So, 50% fixed!

Ok I'm glad that we have 50% success :)

Now for the remaining 50%

"Is there a way with packet tracer to tell it analyze the already ESTABLISHED (ACK) traffic from the opposite direction like...?? "

If the packet-tracer sees a corresponding entry in the current state-table it does take that into consideration....no keyword is required to accomplish this...if it's not, then there isn't any entry matching this tcp flow in the firewall's state table.

"I cannot telnet into any Internet SMTP server using port 25 or 2025... with the following command... telnet 67.29.153.40 25

or telnet 67.29.153.40 2025 "

Please read my first post again, I said this Static PAT statement does not cover email sending from inside to outside (unless the source port is 2025). Let me quote that part again:

"Inside >> Outside (Actual Flow of command)

For any traffic having source IP = mail-server-local-IP and SOURCE PORT = 2025, change source IP to >> mail-server-public-IP and change SOURCE port to 25. "

So you have to make sure your email server is using port 2025 (and NOT port 25) so send outgoing email.....I see no reason why outbound email would not work if the server is doing that...perhaps you can disable its listening on port 25 for a while and test?

Regards

Farrukh

You are correct sir. The outgoing mail problem is indeed that I do not know what the source port is inside the packet. In Exchange you have a receive port and a send port. If I blow away port 25 and put only port 2025 on the recieve listening port and 2025 on the send outgoing port, it still does not work. So, what I'm guessing is that Exchange just uses random ports as the source but sends and receives on specific ports. Does this make sense?

I will investigate how you can maybe hard code the Exchange source port....

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: