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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

After changing STATIC command, CLEAR XLATE not persistent 1

Status
Not open for further replies.

A1Friend

IS-IT--Management
Feb 21, 2006
13
US
I am very new to the Cisco world so please don't be too harsh.

I have a PIX 515E in which I made what I thought was a simple change supporting our Exchange Web Mail.

There were two STATIC entries formatted like this:

static (inside,outside) tcp 64.64.64.64 https 10.32.10.32 https netmask 255.255.255.255 0 0

static (inside,outside) tcp 64.64.64.64 255.255.255.255 0 0

which allowed ports 80 and 443 heading for 64.64.64.64 on to our exchange server at 10.32.10.32.

We built a newer exchange server that we want to be the main one now, and applied changed the STATIC entries as such:

static (inside,outside) tcp 64.64.64.64 https 10.2.0.32 https netmask 255.255.255.255 0 0

static (inside,outside) tcp 64.64.64.64 255.255.255.255 0 0

But after doing so, we must continually enter the 'CLEAR XLATE' command in order for clients to hit the server. When we enter 'CLEAR XLATE' we have about 30 seconds of functionality before we lose the ability to hit the exchange server.

I have put a sniffer on the 10.2.0.32 server and see the traffic come thru to it for those 30 seconds, and then nothing, like the PIX is filtering it.

I'm at my wit's end now and am reaching out for assistance. Does anyone know why this is behaving like this? Have I missed something simple (very likely with me).

Thanks.

Dennis
 
I realize the config is strange, and definately needs to be reviewed, but there is a reason for the multiple IP's heading for the same system. We separate the functions. 1 for OWA, 1 for SMTP inbound, 1 I can't actually figure out what its used for. :)

However, if that was what was causing the issue, would it not display the same errors and functional characteristics when we point it to the old exchange server address?

Here is the capture of outside interface:

14 packets captured
12:15:56.076412 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625694562[|tcp]> (DF) (ttl 51, id 41232)
12:15:57.440223 0030.8043.5700 000c.3001.1de6 0x0800 60: 70.213.139.185.3939 > 63.228.182.134.80: R [tcp sum ok] 0:0(0) win 0 (ttl 242, id 0)
12:15:58.666545 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1176 > 63.228.182.134.443: S 112159935:112159935(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625694821[|tcp]> (DF) (ttl 51, id 41233)
12:15:58.976588 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1177 > 63.228.182.134.443: S 3546597983:3546597983(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625694852[|tcp]> (DF) (ttl 51, id 41234)
12:15:59.281861 0030.8043.5700 000c.3001.1de6 0x0800 60: 70.213.139.185.3940 > 63.228.182.134.80: R [tcp sum ok] 0:0(0) win 0 (ttl 242, id 0)
12:16:02.458060 0030.8043.5700 000c.3001.1de6 0x0800 60: 70.213.139.185.3941 > 63.228.182.134.80: R [tcp sum ok] 0:0(0) win 0 (ttl 242, id 0)
12:16:02.827548 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625695237[|tcp]> (DF) (ttl 51, id 41235)
12:16:05.416604 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1176 > 63.228.182.134.443: S 112159935:112159935(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625695496[|tcp]> (DF) (ttl 51, id 41236)
12:16:05.793950 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1177 > 63.228.182.134.443: S 3546597983:3546597983(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625695527[|tcp]> (DF) (ttl 51, id 41237)
12:16:09.661831 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625695912[|tcp]> (DF) (ttl 51, id 41238)
12:16:16.490010 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625696587[|tcp]> (DF) (ttl 51, id 41239)
12:16:23.305770 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625697262[|tcp]> (DF) (ttl 51, id 41240)
12:16:29.885253 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625697937[|tcp]> (DF) (ttl 51, id 41241)
12:16:36.576065 0030.8043.5700 000c.3001.1de6 0x0800 78: 68.26.232.208.1178 > 63.228.182.134.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625698612[|tcp]> (DF) (ttl 51, id 41242)
14 packets shown

And here is the capture of the inside interface:

7801 packets captured
12:16:09.048459 000d.6558.803f 000c.3001.1de7 0x0800 1434: 10.2.0.88.52603 > 216.22.18.74.25: . 3859840094:3859841474(1380) ack 3063940539 win 65425 (DF) (ttl 127, id 6633)
12:16:09.189473 0030.8043.5700 000d.6558.803f 0x0800 54: 216.22.18.74.25 > 10.2.0.88.52603: . [tcp sum ok] 3063940539:3063940539(0) ack 3859838714 win 11040 (DF) (ttl 54, id 4211)
12:16:09.189977 000d.6558.803f 000c.3001.1de7 0x0800 1434: 10.2.0.88.52603 > 216.22.18.74.25: . 3859841474:3859842854(1380) ack 3063940539 win 65425 (DF) (ttl 127, id 6644)
12:16:09.190084 000d.6558.803f 000c.3001.1de7 0x0800 1434: 10.2.0.88.52603 > 216.22.18.74.25: . 3859842854:3859844234(1380) ack 3063940539 win 65425 (DF) (ttl 127, id 6645)
12:16:09.190160 000d.6558.803f 000c.3001.1de7 0x0800 936: 10.2.0.88.52603 > 216.22.18.74.25: P 3859844234:3859845116(882) ack 3063940539 win 65425 (DF) (ttl 127, id 6646)
12:16:09.237612 0030.8043.5700 000d.6558.803f 0x0800 54: 216.22.18.74.25 > 10.2.0.88.52603: . [tcp sum ok] 3063940539:3063940539(0) ack 3859841474 win 16560 (DF) (ttl 54, id 4213)
12:16:09.321135 0030.8043.5700 000d.6558.803f 0x0800 54: 216.22.18.74.25 > 10.2.0.88.52603: . [tcp sum ok] 3063940539:3063940539(0) ack 3859844234 win 22080 (DF) (ttl 54, id 4215)
12:16:09.321425 0030.8043.5700 000d.6558.803f 0x0800 82: 216.22.18.74.25 > 10.2.0.88.52603: P 3063940539:3063940567(28) ack 3859845116 win 24840 (DF) (ttl 54, id 4217)
12:16:09.337842 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52603 > 216.22.18.74.25: P [tcp sum ok] 3859845116:3859845122(6) ack 3063940567 win 65397 (DF) (ttl 127, id 6656)
12:16:09.485555 0030.8043.5700 000d.6558.803f 0x0800 76: 216.22.18.74.25 > 10.2.0.88.52603: P 3063940567:3063940589(22) ack 3859845122 win 24840 (DF) (ttl 54, id 4219)
12:16:09.485799 0030.8043.5700 000d.6558.803f 0x0800 54: 216.22.18.74.25 > 10.2.0.88.52603: F [tcp sum ok] 3063940589:3063940589(0) ack 3859845122 win 24840 (DF) (ttl 54, id 4221)
12:16:09.485875 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52603 > 216.22.18.74.25: F [tcp sum ok] 3859845122:3859845122(0) ack 3063940589 win 65375 (DF) (ttl 127, id 6658)
12:16:09.485921 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52603 > 216.22.18.74.25: . [tcp sum ok] 3859845123:3859845123(0) ack 3063940590 win 65375 (DF) (ttl 127, id 6659)
12:16:09.638730 0030.8043.5700 000d.6558.803f 0x0800 54: 216.22.18.74.25 > 10.2.0.88.52603: . [tcp sum ok] 3063940590:3063940590(0) ack 3859845123 win 24840 (DF) (ttl 54, id 4223)
12:16:09.661922 0030.8043.5700 000d.6558.803f 0x0800 78: 68.26.232.208.1178 > 10.2.0.88.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625695912[|tcp]> (DF) (ttl 51, id 41238, bad cksum 6f59!)
12:16:11.633207 000d.6558.803f 000c.3001.1de7 0x0800 62: 10.2.0.88.52605 > 69.25.142.11.25: S [tcp sum ok] 426522503:426522503(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 6696)
12:16:13.930036 000d.6558.803f 000c.3001.1de7 0x0800 201: 10.2.0.88.52496 > 198.60.208.153.25: . 1139737582:1139737729(147) ack 1821086792 win 65218 (DF) (ttl 127, id 6783)
12:16:14.275788 0030.8043.5700 000d.6558.803f 0x0800 54: 198.60.208.153.25 > 10.2.0.88.52496: . [tcp sum ok] 1821086792:1821086792(0) ack 1139737729 win 147 (DF) (ttl 109, id 19264)
12:16:16.490102 0030.8043.5700 000d.6558.803f 0x0800 78: 68.26.232.208.1178 > 10.2.0.88.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625696587[|tcp]> (DF) (ttl 51, id 41239, bad cksum 6f58!)
12:16:17.648754 000d.6558.803f 000c.3001.1de7 0x0800 62: 10.2.0.88.52605 > 69.25.142.11.25: S [tcp sum ok] 426522503:426522503(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 6829)
12:16:19.289352 000d.6558.803f 000c.3001.1de7 0x0800 201: 10.2.0.88.52496 > 198.60.208.153.25: . 1139737729:1139737876(147) ack 1821086792 win 65218 (DF) (ttl 127, id 6847)
12:16:19.683894 0030.8043.5700 000d.6558.803f 0x0800 54: 198.60.208.153.25 > 10.2.0.88.52496: . [tcp sum ok] 1821086792:1821086792(0) ack 1139737876 win 147 (DF) (ttl 109, id 19309)
12:16:23.305861 0030.8043.5700 000d.6558.803f 0x0800 78: 68.26.232.208.1178 > 10.2.0.88.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625697262[|tcp]> (DF) (ttl 51, id 41240, bad cksum 6f57!)
12:16:24.539248 000d.6558.803f 000c.3001.1de7 0x0800 201: 10.2.0.88.52496 > 198.60.208.153.25: . 1139737876:1139738023(147) ack 1821086792 win 65218 (DF) (ttl 127, id 6917)
12:16:24.682444 000d.6558.803f 000c.3001.1de7 0x0800 62: 10.2.0.88.52607 > 216.168.224.70.25: S [tcp sum ok] 505847294:505847294(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 6921)
12:16:25.018141 0030.8043.5700 000d.6558.803f 0x0800 54: 198.60.208.153.25 > 10.2.0.88.52496: . [tcp sum ok] 1821086792:1821086792(0) ack 1139738023 win 147 (DF) (ttl 109, id 19335)
12:16:25.681300 000d.6558.803f 000c.3001.1de7 0x0800 62: 10.2.0.88.52609 > 63.253.45.99.25: S [tcp sum ok] 835537297:835537297(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 6934)
12:16:25.935300 0030.8043.5700 000d.6558.803f 0x0800 62: 63.253.45.99.25 > 10.2.0.88.52609: S [tcp sum ok] 1181061879:1181061879(0) ack 835537298 win 16384 <mss 1380,nop,nop,sackOK> (ttl 116, id 64359)
12:16:25.935452 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52609 > 63.253.45.99.25: . [tcp sum ok] 835537298:835537298(0) ack 1181061880 win 65535 (DF) (ttl 127, id 6946)
12:16:26.171072 0030.8043.5700 000d.6558.803f 0x0800 126: 63.253.45.99.25 > 10.2.0.88.52609: P 1181061880:1181061952(72) ack 835537298 win 65535 (DF) (ttl 116, id 64363)
12:16:26.171377 000d.6558.803f 000c.3001.1de7 0x0800 88: 10.2.0.88.52609 > 63.253.45.99.25: P 835537298:835537332(34) ack 1181061952 win 65463 (DF) (ttl 127, id 6956)
12:16:26.369197 0030.8043.5700 000d.6558.803f 0x0800 262: 63.253.45.99.25 > 10.2.0.88.52609: P 1181061952:1181062160(208) ack 835537332 win 65501 (DF) (ttl 116, id 64366)
12:16:26.370494 000d.6558.803f 000c.3001.1de7 0x0800 90: 10.2.0.88.52609 > 63.253.45.99.25: P 835537332:835537368(36) ack 1181062160 win 65255 (DF) (ttl 127, id 6959)
12:16:26.820834 0030.8043.5700 000d.6558.803f 0x0800 54: 63.253.45.99.25 > 10.2.0.88.52609: . [tcp sum ok] 1181062160:1181062160(0) ack 835537368 win 65465 (DF) (ttl 116, id 64376)
12:16:27.256136 0030.8043.5700 000d.6558.803f 0x0800 103: 63.253.45.99.25 > 10.2.0.88.52609: P 1181062160:1181062209(49) ack 835537368 win 65465 (DF) (ttl 116, id 64387)
12:16:27.256471 000d.6558.803f 000c.3001.1de7 0x0800 84: 10.2.0.88.52609 > 63.253.45.99.25: P 835537368:835537398(30) ack 1181062209 win 65206 (DF) (ttl 127, id 6968)
12:16:27.553285 0030.8043.5700 000d.6558.803f 0x0800 102: 63.253.45.99.25 > 10.2.0.88.52609: P 1181062209:1181062257(48) ack 835537398 win 65435 (DF) (ttl 116, id 64391)
12:16:27.553575 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52609 > 63.253.45.99.25: P [tcp sum ok] 835537398:835537404(6) ack 1181062257 win 65158 (DF) (ttl 127, id 6972)
12:16:27.820346 000d.6558.803f 000c.3001.1de7 0x0800 62: 10.2.0.88.52607 > 216.168.224.70.25: S [tcp sum ok] 505847294:505847294(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 6975)
12:16:27.866517 0030.8043.5700 000d.6558.803f 0x0800 104: 63.253.45.99.25 > 10.2.0.88.52609: P 1181062257:1181062307(50) ack 835537404 win 65429 (DF) (ttl 116, id 64394)
12:16:27.866913 000d.6558.803f 000c.3001.1de7 0x0800 718: 10.2.0.88.52609 > 63.253.45.99.25: P 835537404:835538068(664) ack 1181062307 win 65108 (DF) (ttl 127, id 6977)
12:16:28.435127 0030.8043.5700 000d.6558.803f 0x0800 54: 63.253.45.99.25 > 10.2.0.88.52609: . [tcp sum ok] 1181062307:1181062307(0) ack 835538068 win 64765 (DF) (ttl 116, id 64404)
12:16:29.822299 0030.8043.5700 000d.6558.803f 0x0800 139: 63.253.45.99.25 > 10.2.0.88.52609: P 1181062307:1181062392(85) ack 835538068 win 64765 (DF) (ttl 116, id 64468)
12:16:29.836306 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52609 > 63.253.45.99.25: P [tcp sum ok] 835538068:835538074(6) ack 1181062392 win 65023 (DF) (ttl 127, id 7006)
12:16:29.885345 0030.8043.5700 000d.6558.803f 0x0800 78: 68.26.232.208.1178 > 10.2.0.88.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625697937[|tcp]> (DF) (ttl 51, id 41241, bad cksum 6f56!)
12:16:30.007857 000d.6558.803f 000c.3001.1de7 0x0800 201: 10.2.0.88.52496 > 198.60.208.153.25: . 1139738023:1139738170(147) ack 1821086792 win 65218 (DF) (ttl 127, id 7009)
12:16:30.054486 0030.8043.5700 000d.6558.803f 0x0800 100: 63.253.45.99.25 > 10.2.0.88.52609: P 1181062392:1181062438(46) ack 835538074 win 64759 (DF) (ttl 116, id 64518)
12:16:30.054745 0030.8043.5700 000d.6558.803f 0x0800 54: 63.253.45.99.25 > 10.2.0.88.52609: F [tcp sum ok] 1181062438:1181062438(0) ack 835538074 win 64759 (DF) (ttl 116, id 64519)
12:16:30.054852 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52609 > 63.253.45.99.25: F [tcp sum ok] 835538074:835538074(0) ack 1181062438 win 64977 (DF) (ttl 127, id 7011)
12:16:30.054898 000d.6558.803f 000c.3001.1de7 0x0800 60: 10.2.0.88.52609 > 63.253.45.99.25: . [tcp sum ok] 835538075:835538075(0) ack 1181062439 win 64977 (DF) (ttl 127, id 7012)
12:16:30.270173 0030.8043.5700 000d.6558.803f 0x0800 54: 198.60.208.153.25 > 10.2.0.88.52496: . [tcp sum ok] 1821086792:1821086792(0) ack 1139738170 win 147 (DF) (ttl 109, id 19380)
12:16:30.270356 0030.8043.5700 000d.6558.803f 0x0800 54: 63.253.45.99.25 > 10.2.0.88.52609: . [tcp sum ok] 1181062439:1181062439(0) ack 835538075 win 64759 (DF) (ttl 116, id 64532)
12:16:33.726616 000d.6558.803f 000c.3001.1de7 0x0800 62: 10.2.0.88.52607 > 216.168.224.70.25: S [tcp sum ok] 505847294:505847294(0) win 65535 <mss 1460,nop,nop,sackOK> (DF) (ttl 127, id 7088)
12:16:35.257768 000d.6558.803f 000c.3001.1de7 0x0800 201: 10.2.0.88.52496 > 198.60.208.153.25: . 1139738170:1139738317(147) ack 1821086792 win 65218 (DF) (ttl 127, id 7105)
12:16:35.489598 0030.8043.5700 000d.6558.803f 0x0800 54: 198.60.208.153.25 > 10.2.0.88.52496: . [tcp sum ok] 1821086792:1821086792(0) ack 1139738317 win 147 (DF) (ttl 109, id 19400)
12:16:36.260454 0030.8043.5700 000d.6558.803f 0x0800 101: 63.209.10.245.59298 > 10.2.0.88.25: P 931268270:931268305(35) ack 1623200922 win 6432 <nop,nop,timestamp 501086424 3108749> (DF) (ttl 55, id 59974)
12:16:36.260835 000d.6558.803f 000c.3001.1de7 0x0800 102: 10.2.0.88.25 > 63.209.10.245.59298: P 1623200922:1623200958(36) ack 931268305 win 65401 <nop,nop,timestamp 3109064 501086424> (DF) (ttl 127, id 7140)
12:16:36.293411 0030.8043.5700 000d.6558.803f 0x0800 66: 63.209.10.245.59298 > 10.2.0.88.25: . [tcp sum ok] 931268305:931268305(0) ack 1623200958 win 6432 <nop,nop,timestamp 501086427 3109064> (DF) (ttl 55, id 59975)
12:16:36.576157 0030.8043.5700 000d.6558.803f 0x0800 78: 68.26.232.208.1178 > 10.2.0.88.443: S 2282726794:2282726794(0) win 33580 <nop,wscale 1,nop,nop,timestamp 625698612[|tcp]> (DF) (ttl 51, id 41242, bad cksum 6f55!)
 
When you point it to the old address are you pointing both statics to it?

The odd part is that I dont see any replies from 10.2.0.88.443 regardless of whether it was abad packet unless it is replying on port 25. Is this a new setup? does it work for internal traffic? Is this a 2003 Server? Is the firewall enabled on the server?
 
Yes, when we point it back to the old Exchange server, we change both of the two statics for the 134 address.

Yes, this is a new server we built to replace the old server. We configured it to match the old one, just bigger hardware. We also had MS product team webex and do the config once to make sure we have it setup correctly, and they didn't see any issues.

Internally, pointed to the 10.2.0.88 it works perfectly, using the same URL as is being used on the outside, https included.

We're running Exchange Server 2003SP2 on Windows Server 2003 SP1, and the firewall is disabled on the server.

Thanks,

Dennis.
 
so if you type https:\\10.2.0.88 into your browser you have no issues getting there? The only thing I can tell from the capture is that reply packets for the http and https traffic are not going back through the firewall. Do you have anything behind the firewall in between the mailserver? If you look at the logs for IIS are you seeing anything there?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top