[j-nsp] Asymmetric flow, session reset, breaking SSH

[Tom Storey]

Hi all, hoping there is someone familiar with J Series flow handling
that can help me out with this.

I have a network situation (deliberate by design, not accidental in
any sense) that results in asymmetric data flow. There are 3 devices
involved, a PC, J2320, and a Cisco 1811. The PC is plugged into a
switch port on the 1811 configured as an access port in VLAN10. This
VLAN is trunked via a second switch port on the 1811 to ge-0/0/2
(configured for VLAN tagging) on the J2320 where the default gateway
for the PC lives. The J2320 is also connected via ge-0/0/1 to Fa0 on
the 1811, and this is used for pure routing.

Initiating an SSH session from the PC results in IP packets being
switched through the 1811 and into the J2320 where they then exit via
ge-0/0/1 and into port Fa0 on the 1811. There is an SVI configured on
the 1811 in the same subnet that the PC lives in (along with
ge-0/0/2.10), so when the 1811 sends packets back to the PC they go
straight out and into the PC rather than back through the J2320.

This results in a session on the J2320 which has data flow in one
direction, but not the other. After about 10 or so seconds, the J2320
clears this session and sends an RST back to the PC, dropping the SSH
session, but not the 1811 it seems (which ties up VTY lines - but this
is ok, they clear themselves up after exec-timeout is reached.)

If I "set security flow tcp-session no-syn-check" on the J2320 the
problem seems to disappear, and it no longer seems to care about one
way data flow. But the session doesnt clear away after I end the SSH
session (via ~. or "exit"), not at least for 40 minutes or so anyway.

Does anyone know how to "properly" handle situations like this? At the
moment the configuration is just in a lab, pre-deployment. Otherwise
the only practical way I can see to get around this is to remove the
SVI from the 1811 so that it doesnt have a direct route back to the
PC. This will just require a slight modification to the design, and
I'll need to acquire additional IPs to assign to the 1811 (e.g. a /32
assigned to a loopback interface) in place of sitting it in what will
be a DMZ subnet via the SVI.

Thanks.
Tom