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

[Mark Menzies]

NAT isnt evil, its just misunderstood.  :)

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

> 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
> >
> >
>