Hi,
Well, I would like to be certain, that I'm not missing something obvious.
I'm trying to let a FTPS explicit connexion goes through my ASA5520 with IOS 7.0(2).
Here's what I set up: - an ACL for having no inspection on ftp:
: access-list ftp-servers extended deny tcp any host _outside.ip_ : access-list ftp-servers extended deny tcp any host _outside.ip_ : access-list ftp-servers extended permit tcp any any eq 21 : access-list ftp-servers extended permit tcp any any eq 20
- an matching class-map : class-map ftp_traffic : description This definition allow for explicit ftps. : match access-list ftp-servers
- and the policy-map: : policy-map global_policy : class ftp_traffic : inspect ftp
Then : : Global policy: : Service-policy: global_policy : Class-map: ftp_traffic : Inspect: ftp, packet 118893, drop 0, reset-drop 0
And most of the TL'S handshake goes well, but around the end: : curl: (35) error:1406D0FD:SSL routines:GET_SERVER_HELLO:unknown remote error type
and on the firewall : : Feb 26 16:22:42 192.168.161.254 %ASA-4-106023: Deny tcp src outside:_outside.ip_/21 dst PRE-PRODUXION:_Patted_Inside.Ip_/28996 by access-group "IN-OUTSIDE"
I open this but same result!
So, I check the traces (only on the command port, the rest goes on port 3000): : 286: 15:00:39.012160 _outside.ip_.3000 > _Patted_Inside.Ip_.18862: P
1780843152:1780843159(7) ack 1625492240 win 16442 : 287: 15:00:39.012374 _outside.ip_.3000 > _Patted_Inside.Ip_.18862: R 1780843159:1780843159(0) win 0 : 289: 15:00:39.012587 _Patted_Inside.Ip_.18861 > _outside.ip_.21: F 2248722209:2248722209(0) ack 2499492131 win 5984 : 295: 15:00:39.053265 _outside.ip_.21 > _Patted_Inside.Ip_.18861: . ack 2248722210 win 16450 : 299: 15:00:39.127450 _outside.ip_.21 > _Patted_Inside.Ip_.18861: P 2499492131:2499492253(122) ack 2248722210 win 16450 : 300: 15:00:39.127617 _Patted_Inside.Ip_.18861 > _outside.ip_.21: R 2248722210:2248722210(0) win 0 : 304: 15:00:39.131996 _outside.ip_.21 > _Patted_Inside.Ip_.18861: F 2499492253:2499492253(0) ack 2248722210 win 16450Well, there is a problem with this output:
on sequence 300, the appliance sent a reset for no reason to the 299 push packet, coming from the outside. The problem being that even if we sent the FIN on 289, the connection is still half close and the packet should be accepted.
the timeout of half-close is set:
: timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
I suspect the asa to clear the table of connection too early (as soon as it sees the FIN) and then drop the packet as it is no longer associated with any connection.
Yet, I'm still willing to suspect that I've done something wrong...