Hello,
I've an issue packet reordering of packets with our 6509 sub720 and nat in
combination with our asa and/or pix.
Basically: when closing an (http) tcp session, quite often 2 packets are
reordered (only) in de closing state. The client/server are perfectly able to
cope with that, however, our asa (5520 fw 8.2) keeps the state open, and
causes an issue when reusing those ports for another connection.
It happens quite often, trigger-able with _just_ 1 connection/second. for
example a capture session of about 5 minutes shows 352 sessions, 32
reordered packets in de close state, from which 19 tries result in a reset
later. no other reordenings are happening, only in the tcp close state.
On the sup720-msfc we use source NAT, on the msfc we have an setting:
ip nat translation finrst-timeout 120
which causes the msfc to re-use it's source port after 2 minutes, which is
part of the problem, but probably leaving it default won't solve it..
When a new syn arrives, it gets source-nat-ed to a reused (source) port
which the asa hasn't forgot about, the asa send a PSH,ACK in return, (with
sequence number of the previous session). The client gets confused and send
a RST.
So basically in this way many sessions go wrong, about 20% to the particular
ip/server i investigated (production), which bothers us.
Tried to reproduce it in our test environment as close as possible, but no
luck (yet).
A possible workaround is disable the asa statefull engine for this session,
which works, however, the other side has a old pix, and they say the can't
"fix" it , so that leads to a dead end, and i don't consider it as valid solution.
Routing, without the nat, is also a fine workaround, but not acceptable for us.
Any idea what may causing this, and what would be a possible solution?
relevant hardware:
c6509 + WS-SUP720 + MSFC3 + PFC3A firmware s72033-advipservicesk9_wan-mz.122-18.SXF15a.bin
relevant software configurations:
inside:
vlan <X>, which has a route map to implement policy based routing
defined as nat inside
msfc: which routes the traffic and hold those vlan interfaces.
outside:
vlan <Y>, which is connected to our asa.
defined as nat outside
ip nat translation finrst-timeout 120
interface Vlan<X>
description inside (to CSM client vlan)
ip address <snip> 255.255.255.0
no ip proxy-arp
ip nat inside
ip policy route-map inside2outside_pbr
standby 1 ip <snip>
standby 1 priority 120
standby 1 preempt
standby 1 authentication <snip>
!
interface Vlan<Y>
description outside
ip address <IPPRIM> 255.255.255.240
no ip proxy-arp
ip nat outside
standby 1 ip <snip>
standby 1 priority 120
standby 1 preempt
standby 1 authentication <IPPRIM>
!
ip nat pool PRIM <IPPRIM> <IPPRIM> netmask 255.255.255.240
ip nat inside source list PRIM pool PRIM overload
ip access-list extended PRIM
permit icmp host ..
<snip>
permit udp host ...
<nip>
permit tcp host ..
<snip>
permit tcp host <sampleip1> gt 1023 host <sampleip2> range 6000 9000
<snip>
The captures created to research the situation where with a spanport on the physical
interface of vlan<Y>, and on vlan<X>
in the wireshark text output included is packet 59 and 60 reordered, and
later a new session with the same port experiences the problems caused by
the previous session.
Any ideas to further investigate, or perhaps ideas about it?
Arjan Filius
arjan.filius@saasplaza.com
+31612529987
