KB ID 0000702 Dtd 30/10/12
If you look after a firewall, sooner or later something will fail, and the blame (rightly or wrongly), will be leveled at the firewall. I came back from holiday this week to find a client had got a problem with secure POP email. The problem had been fixed (temporarily) by dropping the affected users into a group, and opening all ports. As this had fixed the problem then it’s fair to say that the ASA was the root cause of the problem.
So I was asked to take a look and open the correct ports and lock the firewall back down again.
Step 1 – Setting up logging on the ASA
I’m going to do some real time testing, so the internal buffer on the ASA will hold enough logs for me, if you have an intermittent problem you might want to setup an external syslog server. I’m going to set the log buffer size, and the logging level, and finally turn logging on.
Step 2 – Attempt communication
At this point I got the client to attempt connection to the secure POP server, then had a look at the logs. I could view the whole log with ‘show logg’, but I filtered it down just to include traffic to and from this client (192.168.1.2).
Note: The ports being used are highlighted in red, (YES I know that these are the ports required for secure POP, but your application could be using anything!)
Step 3 – Open the Ports required
There are a few ways of doing this. I just created some network objects, then if any other hosts need secure POP, I can simply add them to the object group.
WARNING: This assumes you DON’T have an outbound traffic access list. If you DO replace the word ‘outbound’ with the name of yours. Also remember as soon as you allow traffic like this all other traffic gets blocked!
Step 4 – Disable Logging
Simply prefix your earlier command with the word ‘no’.
Related Articles, References, Credits, or External Links