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

[Mark Menzies]

We can go about this in one of 2 ways here.

1.  Remove the cisco SVI and force all the traffic to be passed through the
J series

2.  Add interface NAT to the initial SSH session when passing the SYN
through to ge-0/0/2.10.  This achieves the same aim as 1 by forcing the
reply traffic back through the J series as the source address of the SSH
connection seems to be the J series.

If we do the no-syn-check, we are basically negating any benefit we get
from the J series as a firewall and I would not normally recommend that.

The nat solution in 2 is common place for traffic that the firewall needs
to see for some local network traffic (ie switched rather than routed)

HTH




On 8 August 2012 15:00, Tom Storey <tom at snnap.net> wrote:

> 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
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>