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