Kindly help me with this PIX problem

Like I said in the firewalls newsgroup, you have a very old PIX operating system and there are known bugs in the NAT translation in that version.

Inability to ping an IP address does not affect ability to send or receive email. It is NOT part of the smtp protocol to ping an address before attempting to connect to it on tcp port 25.

Always a better idea than posting in the general firewalls newsgroup; there are more people here who are familiar with PIX and something might occur to one person that the other people missed.

Alas, I appear to be the resident PIX 6 expert, and I'm the one who told you that you really need a software upgrade.

You cannot telnet to the outside interface of a PIX 6 firewall (at least not without VPN layers that are not present in your configuration.) You *can* ssh to the outside interface of a PIX 6 firewall, if you have set up a few things ahead of time. In particular,

That command allows ssh to the PIX, but only from the host njrep1 on the -inside- interface. You would need an 'ssh' configuration command that ended in 'outside' in order to ssh from outside.

Putty is able to ssh without difficulty, so your reference to 'telnet' might just have been a terminology mistake.

Really, multiple threads doesn't help.

Sorry, but this is Usenet, and people respond or they don't. Multiple threads tend to annoy people. When you say that a situation is urgent, and that your ISP doesn't want to help, what you are telling us is that your situation calls for a consultant, either a private firm hired, or a support contract or "incident" call with Cisco. Particularily on a weekend, when people have family things, or yards to tend, or festivals to go to, or vacation to, urrr, vacate.

Anyhow, if your smtp has stopped, then double-check your DNS entries for the affected IP address. Ensure that the IP address has a valid reverse address translation -- better yet, a valid reverse address translation in the same domain as people are sending the email to.

Oh yeah, another thing: if you won't have access to the device until Monday then the situation must not be quite so urgent. An urgent situation is when you get the company president out of bed to get the doors open for you, and the company president is happy to do so because the president realizes what the technical problem means to the company.

Hi Walter Thank you very much for posting your reply. I don't understand what you mean by NAT. The firewall configuration uses static to map inside and outside IP's. If you have read the configuration that I posted, you'd know that we don't use NAT. Or may be I am an ignoramus. Also, the firewall configuration didn't change over many years and it did work exceptionally well despite the drawbacks you mention. Kindly read the configuration and let me know what's wrong with it.

I would like to start with a minimal configuration and build on it. Can you please suggest what minimum rules are required for the PIX6 to work and at the same time make the mail server available?

You are right. I have allowed all icmp messages to pass through the firewall. The firewall, however, is blocking SMTP. Somewhere I have read that the following line is more robust

no fixup protocol smtp 25

As it will allow ESMTP commands as well.

Thank you sir for the suggestion. I want to get this email thing right in my heads. There is no point in aspiring for better things when I am stuck at a very basic level. I hope I am being clear and communicative. I want the PIX 6 configuration to work before I go and make an upgrade. Further more, this configuration has worked for 5 years without a hitch in the email delivery.

Thanks for the clarification. How do I make any host from outside to connect to PIX?

Will "ssh any 255.255.255.255 outside" work?

The email issue is back logged for more than 4 days now. So I was very desperate to get it fixed. I don't know what a consultant can do or how to advertise for a consultant. Our company is a startup and has a very tight budget. We do all the development in house. We have a windows maintenance contract with Primary Support. I called them and they were not helpful. They wanted to telnet/ssh to the firewall and that was not possible now. Please note that my intention is not to abuse the usenet. I want to learn as I go through your response. You have been very kind in the past and as always in explaining things. So my kind regards to you.

With respect, you shouldn't be let anywhere near a production firewall if that is the case.

You have been told that the pix code rev you are running has serious issues and your response of

Shows that you're failing to comprehend the message.

At your present level of technical expertise you are incapable of fixing the problem. Time to pay someone who does or find an alternative solution until you do.

greg

NAT is Network Address Translation, and NAT applies to nearly all traffic between different interfaces on a PIX. It is most obvious when a host has a different inside address and outside address, but as far as the PIX 6.1 is concerned, it also applies to five of the six different ways to have an IP address be the same on the inside and the outside... and you don't happen to be using that sixth way.

Bugs do not always manifest immediately.

ssh 0.0.0.0 0.0.0.0 outside

A consultant could go on site and debug the problem more thoroughly -- and be available in case of further problems.

That could be a problem. Consultants can be a bit expensive, especially for a short contract. But not getting in someone to fix your problem can be even more expensive.

Yes and no. Clients that want to speak ESMTP are required by the RFC's to -try- an EHLO packet, and if that doesn't work then to revert to HELO, and servers are not supposed to drop connections upon merely seeing an initial error (e.g., a packet not understood.) But PIX with the smtp fixup did get that wrong for several releases, dropping the connection immediately.

It is possible that the smtp fixup is interfering, but if that were the case then you would be able to telnet from the outside to the smtp port and get -some- answer, from the PIX itself: even in the releases that made the mistake of dropping the session too early, you would get the SMTP prompt from the PIX. However, when I test, I don't get an answer.

Unfortunately my workplace temporarily has some icmp turned off while a DoS attack calms down, and my residential firewall cannot cope with traceroute, so I cannot easily figure out where the block exists. It could be at your ISP even.

How is this different from paying Cisco for tech support? Sharing company secrets with an unknown consultant could backfire. Besides, as I had already mentioned, we retain Primary Support as our consultants. They couldn't figure out where the problem lies.

I worked as a consultant. It is hard to fill extremely short jobs. Besides, these days consultants land into the USA on airlines and are quite pricy. This is not a consultant's job. But I could be wrong.

There are several different levels of technical support contract with Cisco. Unfortunately unless you are big company spending a lot of money, then you don't usually get the full attention of even one person at Cisco. Even a regular "onsite premium service"

And what do you know about your building cleaners? If you do have reason to trust them, then how did you develop that trust?

Sorry, I did not (and do not) recognize "Primary Support". You used the name in the phrase "Windows Primary Support", so I assumed it was either a Microsoft support contract (whom I wouldn't expect to know -anything- about firewalls other than Windows XP built in firewall) or else a company that specializes in Windows (and so wouldn't be expected to know much about firewalls.)

You indicated that the ISP set up the firewall (and now doesn't want anything to do with it); the fact that you did not earlier turn the support over to Primary Support suggests to me that whatever else they do, Primary Support does not have any PIX specialists on staff.

Yes, but there are good people out there.

I'm not sure what you mean by that. It's true that if -I- were to take on the job, I'd have to fly in from outside the USA (a 2 day bus ride would be just too much fun for me to survive), but I'm one of those rare Canucks that hang out here (Merv is another but he's a lot closer.)

If you need someone who *really* understands Cisco equipment, is -very- trusted, and is close by, talk to Networking Unlimited, Tenafly, NJ. I wouldn't want to even estimate their pricing; I get the impression that their pricing structure is somewhat flexible. If nothing else, they can probably refer you to someone local.

I don't mean to sound rude, but you appear to be over your head on this problem. I scanned your configuration, and without having studied it line by line, I would say that the only obvious problem with the configuration is the old PIX softwar release. That means you have a non-trivial network problem to debug, and you don't know how to debug it. So who, then?

I have some ideas on what's wrong, but describing them to you and remotely guiding you through the testing would take a few hours. There are probably other people with the necessary skills also following the thread to some extrent; I suspect strongly that they too are thinking, "This could probably be debugged, but it would take several hours of work." Not that many people with the necessary skills have that much time to -volunteer-, especially on short notice.

(To disambiguate a point: I am not in the consultancy business, and I seldom accept "side jobs", especially ones in the USA, as I do not have an appropriate business structure or insurance set up.)