Problem with connections on pix

Unanswered Question
Jul 1st, 2009

Hi

I have a VPN between 2 locations and I can see the servers are communicating. Can ping between the servers all the time. however the connection times out after some time. There is no specific time it times out. The data is continuous and the other end server dont receive ack from my server.

I checked the firewall from my end and see the logs as below

PIX(config)# s logg | i 10.129.20.5

inside:192.168.20.10/29220 (10.129.20.5/29220)

302013: Built inbound TCP connection 3225742 for outside:172.16.32.10/60321 (172.16.32.10/60321) to inside:192.168.20.10/29220 (10.129.20.5/29220)

302013: Built inbound TCP connection 3225743 for outside:172.16.32.10/60323 (172.16.32.10/60323) to inside:192.168.20.10/29220 (10.129.20.5/29220)

302013: Built inbound TCP connection 3225744 for outside:172.16.32.10/60326 (172.16.32.10/60326) to inside:192.168.20.10/29220 (10.129.20.5/29220)

106015: Deny TCP (no connection) from 172.16.32.10/60326 to 10.129.20.5/29220 flags ACK on interface outside

106015: Deny TCP (no connection) from 172.16.32.10/60326 to 10.129.20.5/29220 flags PSH ACK on interface outside

106015: Deny TCP (no connection) from 172.16.32.10/60326 to 10.129.20.5/29220 flags ACK on interface outside

PIX# sh logging | i 192.168.20.10

inside:192.168.20.10/29220 (10.129.20.5/29220)

302013: Built inbound TCP connection 3225740 for outside:172.16.32.10/60318 (172.16.32.10/60318) to inside:192.168.20.10/29220 (10.129.20.5/29220)

302013: Built inbound TCP connection 3225741 for outside:172.16.32.10/60320 (172.16.32.10/60320) to inside:192.168.20.10/29220 (10.129.20.5/29220)

302014: Teardown TCP connection 3225740 for outside:172.16.32.10/60318 to inside:192.168.20.10/29220 duration 0:00:00 bytes 0 TCP FINs

302014: Teardown TCP connection 3225741 for outside:172.16.32.10/60320 to inside:192.168.20.10/29220 duration 0:00:01 bytes 1380 TCP Reset-I

Real inside IP of my server: 192.168.20.10

Natted Ip of my server - 10.129.20.5

Remote server - 172.16.32.10 sending traffic to port 29220 to my server.

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00

timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

I see lot of conversations on this and I came to know that PIX does not have an established connection and that is why it is dropping out. But I do not see why there will not be an established connection when the traffic is continuous.

checking the logs I see reset-I which means a reset is coming from host on the high secuirty interface which would be my server. But not sure why the server is sending a reset.

I have the timeout values as above and wanted to know if I have to change them.

Any explanation on this is much appreciated as I have these problems since few days and getting critical now

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
branfarm1 Wed, 07/01/2009 - 05:55

You mentioned early on that this is a VPN connection (site-to-site I assume). Have you investigated whether the VPN tunnel is still up during the times you are experiencing the difficulties? At first glance, it sounds to me like the VPN may be timing out and not rebuilding.

techtips03 Wed, 07/01/2009 - 06:45

Pretty sure the VPN is up as the pings work betweent the servers when the interfaces are down.

Kureli Sankar Thu, 07/02/2009 - 05:21

Thanks for the clear problem description and the logs. Not many people do this.

The conn gets torn down for reset-I reason and then further ack and push ack packets from the remote client are dropped by the firewall as expected with the 106015 syslog message (deny tcp no connection).

Now, your question is why you see the Reset-I and why your server sends a reset.

I do not have an answer to that as we do not know if it is this server that sends a reset or some other host.

Collect capture on the inside interface where you can see clear traffic close to the server and see if the server's MAC address is responsible for the reset.

If you are running 7.2.4 or 8.x code you can do a match on the capture line

cap capin int inside match ip host 192.168.20.10 host 172.16.32.10

sh cap capin detail | i R

watch for the source mac and then address that. If it is the server, then you need to investigate from the server side. If you find out if it is some websense or other content filtering host then, fix that or remove that from the picture and test again.

techtips03 Thu, 07/02/2009 - 08:54

Hello Sankar

Thanks for the update. I am running v6.3(2). Will the capture commands work on that and should I use the same?

Thanks

techtips03 Wed, 07/08/2009 - 05:05

Thanks for that. I will try this today. Actually the link provided is not working. Can you please advise if any of the timeout values below effect the connection?

timeout conn 1:00:00 half-closed 0:10:00

Thanks

techtips03 Wed, 07/08/2009 - 06:30

I was able to run that capture as below

capture CAPIN access-list CAPIN-ACL interface inside

access-list CAPIN-ACL permit tcp host 192.168.20.10 host 172.16.32.10

sh capture CAPIN detail is giving me outputs. However the interfaces are up now so I have to check the capture when the interface is down.

I looked at the definitions of the timeout values below and I see the conn timeout is idle time after which a connection closes and half-closed is for tcp timeout setting. I think these timeouts are to free the connection table on the PIX after timeouts. Are these to eliminate memory usage because of unused connections?

Anyway I changed both to 0:00:00

timeout conn 1:00:00 half-closed 0:10:00

Actions

This Discussion