NAT isnt evil, its just misunderstood. :) On 8 August 2012 16:06, Tom Storey <t...@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 <m...@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 <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