Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ASA times out, doesn't answer outside interface

Status
Not open for further replies.

bull3000

Technical User
Sep 6, 2007
11
US
I've got a 5510, configured as an outside,dmz,inside firewall. It is configured to allow access by dns, ssh. The problem is that when the connections time out, the device won't answer again for some random-long time. Example... I can ssh to a server behind the firewall. Talk to it for a while. When it times out and disconnects I can't access it and it returns an error that indicates the ip address is unreachable.

I can usually get through one of the ssh interfaces, I can then contact other systems through the DMZ. It is unpredictable which/if any will answer.

Http simply times out and indicates that the host couldn't be contacted.

I know the back end servers are alive and can communicate with the network, because they answer on the DMZ correctly. The issue is access through the outside interface.

This looks like a routing problem. The block of addresses is a new block from the ISP. I'm beginning to wonder if the problem is outside of my network.

Pruned configuration follows. Thanks for any ideas.

:
ASA Version 7.0(6)
!
hostname a****
names
name xx.xx.xx.12 Web Server
name xx.xx.xx.11 mail description Mail Server
name xx.xx.xx.10 dns description Primary DNS Server
dns-guard
!
interface Ethernet0/0
nameif outside
security-level 10
ip address yy.yy.yy.130 255.255.255.192
!
interface Ethernet0/1
nameif DMZ
security-level 25
ip address xx.xx.xx.1 255.255.255.0
!
access-list inside_pnat_outbound extended permit ip any any
access-list inside_access_in extended permit ip any any
access-list DMZ_access_in extended permit ip any any
access-list outside_access_in extended permit udp any host yy.yy.yy.131 eq dnsix
access-list outside_access_in extended permit tcp any host yy.yy.yy.133 eq www
access-list outside_access_in extended permit tcp any host yy.yy.yy.133 eq ssh
access-list outside_access_in extended permit tcp any host yy.yy.yy.132 eq ssh
access-list outside_access_in extended permit tcp any host yy.yy.yy.131 eq ssh
ip verify reverse-path interface outside
arp timeout 14400
nat-control
global (outside) 1 yy.yy.yy.138
nat (inside) 1 access-list inside_pnat_outbound
static (DMZ,outside) yy.yy.yy.131 dns netmask 255.255.255.255
static (DMZ,outside) yy.yy.yy.132 mail netmask 255.255.255.255
static (DMZ,outside) yy.yy.yy.133 255.255.255.255
static (DMZ,outside) yy.yy.yy.140 awx01 netmask 255.255.255.255
static (DMZ,outside) yy.yy.yy.141 cm01 netmask 255.255.255.255
access-group inside_access_in in interface inside
access-group DMZ_access_in in interface DMZ
access-group outside_access_in in interface outside
route outside 0.0.0.0 0.0.0.0 yy.yy.yy.129 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:20:00 absolute uauth 0:10:00 inactivity
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map global_policy
class inspection_default
inspect dns maximum-length 512
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
 
Since I didn't get any takers to this question... Perhaps the resolution will be useful to somebody else at some point in the future...

This turned out to be multiple problems. First, there was another firewall programmed to accept SOME of the same addresses. Hence, the two firewalls were fighting over the incoming requests and creating the appearance of a timeout. Second, there was a routing problem (as I sort of expected). The combination of these problems created something that looked absolutely unpredictable.

Working through this problem did raise one interesting question about how the 55xx series works internally.

In the following configuration snippet, what value is used for 'www' in the access-list rule?

name xx.xx.xx.12 Web Server
access-list outside_access_in extended permit tcp any host yy.yy.yy.133 eq www
static (DMZ,outside) 216.84.38.133 255.255.255.255
access-group outside_access_in in interface outside

Is it 80 or the address of the web server?
 
Glad you got it figured out. Sounds like a messy situation.

The "www" keyword stands for port 80 on the security appliance. In your ACL it stands for 80, also. That's because of it's position in the ACL after the "eq". The only thing that can come after "eq" is a port.

I see how things could get confusing when you define a name as " though, because in your static xx.xx.xx.12!

Just for fun, if you were doing static PAT you could make things really confusing:

static (dmz,outside) tcp 216.84.38.133 www

That would forward traffic destined to port 80 on the interface IP to port 80 on the server named www. :p



Matt
CCSP
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top