Link to home
Start Free TrialLog in
Avatar of babatoke
babatokeFlag for United States of America

asked on

Cisco ASA

i have an email server being natted via my cisco asa firewall. i created a static for it and allowed smtp access via an access list. it works perfectly for a few hours and all of a sudden it loses connectivity to the internet while all other users being patted via the asa interface ip address still browse. if i remove the following (below), access is restored.
1) remove the static command
2)  put the email servers ip address on the external interface of my firewall for a afew seconds.
3) remove the ip address from the firewall interface and configure it back for my email server using the static command
4) issue a cl xl command

it works again after this for a few hours and gets knocked off again. if i repeat the process above, access is restored again for a few hours. any ideas on how to get this sorted permanently is much appreciated.
Avatar of Svet Paperov
Svet Paperov
Flag of Canada image

Can you paste here the related configuration commands from the running-config: interface, static, nat?

Did you verify the debugging log of Cisco ASA for any messages?  
Avatar of babatoke

ASKER

static (inside,outside) x.x.x.1 y.y.y.y dns 1500 120 udp 1500
access-list 101 permit tcp any host x.x.x.1 eq smtp
access-group 101 in int outside

int e0/0
nameif outside
ip add x.x.x.2 255.255.255.0
 thats basically it. hopes it answers you
The debug log from the moment where the problem appears will be the key element to resolve this.


You didn’t publish the nat/global commands but I presume that you are natting the inside IP range to the outside interface address. You are using different external IP address for the mail server in the static doing full nat. I presume this is by design. You know that you could use static with the interface keyword (interface IP addresses) to have pat to specific port (like smtp, for example) instead of full nat, right?
nat (inside) 1 0  0 dns
global (outside) 1 int

i prefer doing the full 1 - 1 nat for my email and web servers, have enough ip add to cover those 2.

which debugs would you like me to capture exactly.
I don't know yet. It could be an overload problem. Which version of ASA we are talking about?
Did you try cl xl and cl conn without removing static first?

ASDM has a monitoring that can show and filter at least 1000 lines of debug. I would use it as starting point. Then we can narrow more precisely the problem. You need to know what exactly happens just before losing connectivity.
ver 8.2

yeah i always do a cl xl, sometimes i even reload.
You could set up an external log server and send syslog there with debugging (7) level and wait for the problem. Or, if you don’t have an external syslog server, you could use ASDM – I checked – it can keep up to 2000 syslog messages in the buffer. The external syslog server is a better solution because it will not require staying in front of the screen.

I am using a Linux server but there are some good free Windows-based log servers out there. I’ve heard good words for Kiwi syslog server.

The default syslog facility of Cisco ASA is local4 (20).

I hope this could help.
Avatar of pgolding00
do you have access to the router on the internet side of the firewall? this sounds like arp time-out, but you would need to access the router to verify.

from the firewall, "show arp" next time the problem shows up. also "show access-list 101" when the problem exists and verify if the "permit ... smtp" entry hitcnt is incrementing. increments indicate that traffic continues to arrive at the firewall. also as spaperov indicated, check the log when problem occurs, look for arp or teardown messages. (make sure "logging enable" and "logging buffered debug" are configured beforehand).
dont have access the upstream router, it belongs to the isp an i have informed them about the problem but so far they have no answer for me. once the server gets knocked off nothing hits again neither can it get out to the internet as well on any port.

what sort of stuff can they check on the router or commands to verify what the issue is when it occurs, i can speak with their boss and get them to do it if i know exactly what they need to be checking for.
have the isp verify that there is an arp entry in their router for both the firewall interface address and for the static address, and that the mac of each entry is the same.

at the same time, it wont hurt to check arp in the firewall (show arp) and verify that there is an entry for the router and that it does not change over time.

again, check the firewall log also, as often all sorts of useful stuff hides in there.
ASKER CERTIFIED SOLUTION
Avatar of babatoke
babatoke
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
is this on the same server that your users have problems with when accessing from the internet - the other case you have open at the moment that we are discussing?
no, this is a different set up entirely. not the same network.
ok, try changing isp, although its still worth trying to verify the cause - at least determine is the default gateway arp entry missing from the firewall when things stop? knowing what the isp router sees would be more useful, but not always possible.

i would also be taking a close look at the asa logs at the time traffic stops, to see if the asa thinks its a normal session ending or something else.

one late thought - what does "show run all sysopt" say about proxyarp on the outside interface? having a static normally makes the firewall respond to arp requests for the configured statics, but there have been bugs in the pix arp code in the past.
ok will check, to speed things up, what is the correct statement that should be there or what do you want me to put there.
when traffic stops working, "show arp" on the asa and verify if the email server arp entry is present.

in the logs, heres a normal session teardown message:
May 16 2011 14:46:49: %ASA-6-302014: Teardown TCP connection 378787 for backup:202.205.176.115/53128 to identity:x.x.x.x/22 duration 0:00:05 bytes 867 TCP FINs
if you see anything other that TCP FINs then something is not normal. you might also see session timeout messages, again indicating something not right.

for sysopt you should see "no sysopt noproxyarp outside" or whatever the outside interface is named, if it says "sysopt noproxyarp outside" then enter the no version in config mode.
this is the only option that worked for me.