But don't take it from us. The Firebox M370 is Miercom tested and Miercom approved, outperforming its competitors for stateless and stateful traffic throughput scenarios. Learn more about the M370, M470, M570 and M670 and find the right solution for your organization today!
COURSE of the MONTH
9 days, 8 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Outgoing emails fail to certain recipients, but not to others. Suspect Cisco PIX configuration is not allowing reverse lookups.
Posted on 2006-10-26
Firstly, a little about my system. I am using MS Small Business Server 2003, with f-secure proofpoint email gateway (it is fantastic!!!)and a Cisco PIX firewall. The proofpoing gateway is a recent addition and the problems started at the point that it was installed, and it is reasonable to point a finger either to that, or the changes made to the rest of the system in order to accommodate it - such as changes to the PIX.
Now the problem. I'm having some problems sending mail to certain addresses, where we get non-delivery receipts, often with custom worded error messages such as "sorry we don't accept mail from spammers" or "This system has been configured to reject your mail". I'm fairly sure that the problem is to do with certain mail systems performing reverse lookups, which are failing, but I'm a little unsure quite what to do about it.
Looking at a NDR received today, the sending address is 80.168.151.220 but our incoming mail is sent to 80.168.151.219; is this a common practice?
If I do a reverse lookup on 80.168.151.219, mail.prospec.co.uk is returned, but if I do a reverse lookup on 80.168.151.220 I get the response that there are no PTR records for this domain, which is understandable as this is the outgoing address.
I think it is a problem with the way in which the PIX is configured - it is not letting reverse lookups in.
It is important to note that I have made some recent changes to the PIX, and it is since those changes that the problems have started. To validate this, I have successfully sent a mail using the original PIX configuration, to a recipient that we get NDRs from when using the new PIX configuration, which proves that the problem is either a. a problem with the PIX configuration or b. a problem with the email gateway (f-secure proofpoint appliance), although I suspect it is the PIX.
The changes that I made were to accomodate the proofpoint appliance, where instead of all incoming traffic going to 10.0.0.2 (original configuration), I now filter smtp traffic and forward that to 10.0.0.3 (proofpoint appliance), and forward http to 10.0.0.2.
I guess that now that I am being specific about certain types of traffic, I must specifically allow reverse lookups in, but I haven't a clue where to start and can't find anything on the web.
The original PIX config used the following command to route traffic to the server "static (inside,outside) 80.168.151.219 10.0.0.2 netmask 255.255.255.255 0 0 ", but the changes that I have made routes smtp traffice to the email gateway and http to the server as follows "static (inside,outside) tcp 80.168.151.219 smtp 10.0.0.3 smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp 80.168.151.219 http 10.0.0.2 http netmask 255.255.255.255 0 0
static (inside,outside) tcp 80.168.151.219 https 10.0.0.2 https netmask 255.255.255.255 0 0 "
But, I don't understand why the reverse lookups worked in the first place - to 80.168.151.220 - because the only changes that I made were to the static commands, which did not include 80.168.151.220, but they did.
I look forward to a resolution to this problem, which may, or may not, be a problem with the PIX configuration - I may have got it badly wrong as this is not an area that I confess to being very knowledgable about.
TIA
Craig
Now the problem. I'm having some problems sending mail to certain addresses, where we get non-delivery receipts, often with custom worded error messages such as "sorry we don't accept mail from spammers" or "This system has been configured to reject your mail". I'm fairly sure that the problem is to do with certain mail systems performing reverse lookups, which are failing, but I'm a little unsure quite what to do about it.
Looking at a NDR received today, the sending address is 80.168.151.220 but our incoming mail is sent to 80.168.151.219; is this a common practice?
If I do a reverse lookup on 80.168.151.219, mail.prospec.co.uk is returned, but if I do a reverse lookup on 80.168.151.220 I get the response that there are no PTR records for this domain, which is understandable as this is the outgoing address.
I think it is a problem with the way in which the PIX is configured - it is not letting reverse lookups in.
It is important to note that I have made some recent changes to the PIX, and it is since those changes that the problems have started. To validate this, I have successfully sent a mail using the original PIX configuration, to a recipient that we get NDRs from when using the new PIX configuration, which proves that the problem is either a. a problem with the PIX configuration or b. a problem with the email gateway (f-secure proofpoint appliance), although I suspect it is the PIX.
The changes that I made were to accomodate the proofpoint appliance, where instead of all incoming traffic going to 10.0.0.2 (original configuration), I now filter smtp traffic and forward that to 10.0.0.3 (proofpoint appliance), and forward http to 10.0.0.2.
I guess that now that I am being specific about certain types of traffic, I must specifically allow reverse lookups in, but I haven't a clue where to start and can't find anything on the web.
The original PIX config used the following command to route traffic to the server "static (inside,outside) 80.168.151.219 10.0.0.2 netmask 255.255.255.255 0 0 ", but the changes that I have made routes smtp traffice to the email gateway and http to the server as follows "static (inside,outside) tcp 80.168.151.219 smtp 10.0.0.3 smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp 80.168.151.219 http 10.0.0.2 http netmask 255.255.255.255 0 0
static (inside,outside) tcp 80.168.151.219 https 10.0.0.2 https netmask 255.255.255.255 0 0 "
But, I don't understand why the reverse lookups worked in the first place - to 80.168.151.220 - because the only changes that I made were to the static commands, which did not include 80.168.151.220, but they did.
I look forward to a resolution to this problem, which may, or may not, be a problem with the PIX configuration - I may have got it badly wrong as this is not an area that I confess to being very knowledgable about.
TIA
Craig
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
3-
3
8 Comments
Could be a combination of things. Your email server is sending outbound email with one source IP and the MX record for inbound email is a different IP? This is a potential for confusion of upstream mail systems that look you up before accepting mail from you.
You need to make sure the outbound traffic of the email server matches the PTR and MX records. Since you changed from a 1-1 static nat to a port-forwarding pat, you might want to consider a conditional nat statement (need 6.3x or higher)
access-list email_nat permit ip 10.0.0.2 any eq smtp
global (outside) 10 80.168.151.219
nat (inside) 10 access-list email_nat
This is the only way to assure that outbound email from the internal mail server goes out with the same IP address that is used for inbound email.
You may need to adjut the fixup dns on your PIX depending on what version OS.
If you're running 7.x on the PIX, you may need to disable fixup esmtp
You need to make sure the outbound traffic of the email server matches the PTR and MX records. Since you changed from a 1-1 static nat to a port-forwarding pat, you might want to consider a conditional nat statement (need 6.3x or higher)
access-list email_nat permit ip 10.0.0.2 any eq smtp
global (outside) 10 80.168.151.219
nat (inside) 10 access-list email_nat
This is the only way to assure that outbound email from the internal mail server goes out with the same IP address that is used for inbound email.
You may need to adjut the fixup dns on your PIX depending on what version OS.
If you're running 7.x on the PIX, you may need to disable fixup esmtp
Hi
Thank you for your response. I think I ought to tell you that I perhaps should have rated myself as a newbie/beginner on this subject, particularly with Cisco PIX.
I have looked at your suggestion, which seems to make a lot of sense, although I suspect there was probably a good reason why different addresses were used for incoming and outgoing transmission.
The first line of your suggestion sets up an ACL, but the PIX doesn't accept it, and I wonder whether there is something missing. The way that I am working is to clear the configuration, modify the configuration in a text file and use the "configure net" command to upload the new configuration. When I do this I get the following error:
ERROR: invalid IP address any
Config Error -- access-list email_nat permit ip 10.0.0.2 any eq smtp
Global 80.168.151.219 will be Port Address Translated
.ERROR: access-list <email_nat> does not exist
I would appreciate your further input
Regards
Craig
Thank you for your response. I think I ought to tell you that I perhaps should have rated myself as a newbie/beginner on this subject, particularly with Cisco PIX.
I have looked at your suggestion, which seems to make a lot of sense, although I suspect there was probably a good reason why different addresses were used for incoming and outgoing transmission.
The first line of your suggestion sets up an ACL, but the PIX doesn't accept it, and I wonder whether there is something missing. The way that I am working is to clear the configuration, modify the configuration in a text file and use the "configure net" command to upload the new configuration. When I do this I get the following error:
ERROR: invalid IP address any
Config Error -- access-list email_nat permit ip 10.0.0.2 any eq smtp
Global 80.168.151.219 will be Port Address Translated
.ERROR: access-list <email_nat> does not exist
I would appreciate your further input
Regards
Craig
My error in the syntax... try this:
access-list email_nat permit tcp 10.0.0.2 any eq smtp
^^ "tcp" vs "ip" makes all the difference...
>The original PIX config used the following command to route traffic to the server "static (inside,outside) 80.168.151.219 10.0.0.2 netmask 255.255.255.255 0 0
The original config guaranteed the same inbound and outbound IP address for email.
access-list email_nat permit tcp 10.0.0.2 any eq smtp
^^ "tcp" vs "ip" makes all the difference...
>The original PIX config used the following command to route traffic to the server "static (inside,outside) 80.168.151.219 10.0.0.2 netmask 255.255.255.255 0 0
The original config guaranteed the same inbound and outbound IP address for email.
Hi
Thank you for your revised solution. However, it still doesn't work as shown below:
ERROR: invalid IP address any
Config Error -- access-list email_nat permit tcp 10.0.0.2 any eq smtp
Like I said, I'm a newbie, especially when it comes to Cisco PIX and need some guidance on this.
I look forward to your response.
Regards
Craig
Thank you for your revised solution. However, it still doesn't work as shown below:
ERROR: invalid IP address any
Config Error -- access-list email_nat permit tcp 10.0.0.2 any eq smtp
Like I said, I'm a newbie, especially when it comes to Cisco PIX and need some guidance on this.
I look forward to your response.
Regards
Craig
Damn. Need more coffee... or maybe too much already..
One more time. I tested it this time..
access-list email_net permit tcp host 10.0.0.2 any eq smtp
^^
One more time. I tested it this time..
access-list email_net permit tcp host 10.0.0.2 any eq smtp
^^
Hi
Just to let you know there is still a problem implementing your solution, which I am reading about to ensure that I understand it properly. I believe that your solution is probably syntactically correct, and the problems are more to do with working it into my situation, where I have some existing conflicting commands.
Please bear with me - I haven't fallen off the face of the earth :-> - I'm just doing lots of reading (fitting it around many other tasks), which is why it is taking a long time to reply.
Thanks
Craig
Just to let you know there is still a problem implementing your solution, which I am reading about to ensure that I understand it properly. I believe that your solution is probably syntactically correct, and the problems are more to do with working it into my situation, where I have some existing conflicting commands.
Please bear with me - I haven't fallen off the face of the earth :-> - I'm just doing lots of reading (fitting it around many other tasks), which is why it is taking a long time to reply.
Thanks
Craig
Featured Post
Ready to get started with anonymous questions today? It's easy! Learn more.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
For months I had no idea how to 'discover' the IP address of the other end of a link (without asking someone who knows), and it drove me batty.
Think about it. You can't use Cisco Discovery Protocol (CDP) because it's not implemented on the ASAs.…
You deserve ‘straight talk’ from your cloud provider about your risk, your costs, security, uptime and the processes that are in place to protect your mission-critical applications.
Both in life and business – not all partnerships are created equal.
As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:
• Key questions to ask when considering a partnership to accelerate your business into the cloud
• Pitfalls and mistakes other partners…
Suggested Courses
Course of the Month9 days, 8 hours left to enroll
762 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.