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

[Tom Storey]

NAT is evil. :-)

Removing the SVI from the Cisco seems the cleanest solution to me,
allowing packets to just "route" naturally.

Thanks.

On 8 August 2012 15:08, Mark Menzies <mark at deimark.net> wrote:
> 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
>
>