[j-nsp] Asymmetric flow, session reset, breaking SSH
mark at deimark.net
Wed Aug 8 10:08:43 EDT 2012
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
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)
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.
> juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp