Hi Mike, First.. Yikes!
Second - yes this is possible. It is perfectly legal to use FBF to bounce across routing instances and still match security policy - just ensure your security policy includes the source and destination zones for the *ultimate* destination of the flow is correct - whether it exists in the instance the traffic ends up in is ignored by the flow engine. On 8 Nov 2013, at 12:37 am, Mike Williams <mike.willi...@comodo.com> wrote: > Hi all, > > I might have painted myself into a corner here, so I'm here looking for > options from people far cleverer than I. > > Firstly, a bit of history. > > We're using J6350s, and SRX650s, as "security devices on a stick". > Our Ms and MXs punt packets into a routing instance on the "security devices" > with firewall filters. Those routing instances purposely only use the most > basic of static routes possible (10/8, 192.168/16, etc), so we can be certain > what zones packets pass through so the policies match. > > That all works fine. > > > We're also centralising our inter-site IPSec onto the Js and SRXs, but need > OSPF there, so have a second routing-instance and a partial mesh of routed > tunnels between them. > Still, all good. > Offices and what-not have tunnels tied directly to the IPSec > routing-instances > and OSPF metrics keep traffic flows sane. > All hunky dory. > > > > Now the problem. > > I need to take traffic from servers behind an M/MX have it policy'd by the > "security" routing instance, then encrypted by the IPSec routing-instance. > If I punt traffic into "security", let it come back to the router, then punt > it back into "ipsec", everything works as expected. > However each packet has to pass across the M/MX<->J/SRX link 4 times, in out, > in out. Shake it all about. > > Obviously this would be better if we could shortcut the M/MX step in the > middle and move packets from "security" to "ipsec", and "ipsec" to "security" > directly. > > As "security" doesn't run OSPF/BGP/ISIS/etc adding a static route "next-table > ipsec.inet.0" is fine. > "ipsec" *does* run OSPF though, so I need to do FBF to override that. I've > tried a "then routing-instance security" filter applied on output on the > interface facing the M/MX, but my traffic get lost somewhere. Security > policies from 'input-ipsec-zone' to 'output-security-zone' were added. > > > I'm wondering if 'moving' packets from routing-instance to routing-instance > on > a flow-mode device simply screws up security policies. As one of the input or > output interface don't exist in the routing-instance. > So I figured *routing* packets from routing-instance to routing-instance > would > be better. Time for some logical tunnels! J-series devices don't support > logical tunnels though. > > Argh! > > -- > Mike Williams > _______________________________________________ > 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