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