I'm wondering if newer versions of Junos can overcome the limitation described below or if anyone has any conceptual ideas on how to simplify what I had to do below.
Our SRX210 cluster setup has to be able to selectively route traffic between multipe sites, each site having two ISP's and two VPN tunnels, choosing which tunnel based on business rules according to traffic type, and using filter-based forwarding. I learned long ago (Junos version 11.2R43, to be exact), that the only way to accomplish this is to have:
- two virtual routers, one for each ISP, containing the ISP gateway interface and associated VPN tunnels using that interface
- two security zones, each paired to the corresponding virtual router, resulitng in the associated VPN tunnels being in the same (untrusted) security zone as the public ISP interface
- identical inbound rules, duplicated in both security zones, for every VPN subnet allowing tunnel traffic from the various subnets
- another pair of identical policies within each security zone for inbound destination-NAT traffic so that our web servers etc. can be reached via either interface
- Parallel/duplicated source-NAT policies for each security zone
- Importing static and interface routes back and forth between the three zones
All of this complicaton and duplication works, but is needed for only one simple and frustrating reason: the SRX routers simply cannot consistently return outbound traffic via the same interface it came in on, any other way. Filter-based forwarding doesn't work with a much simpler VR type=forwarding arrangement with only one 'Untrust' security zone for just the two public ISP interfaces and all the tunnels in the 'Trust' zone. FBF works great when traffic originates from the local router, but is IGNORED when it comes to traffic originating from the remote site. So an inbound packet on tunnel st0.1 from ISP-A, originating from the remote site, will go back out tunnel st0.2 from ISP-B via the default routing-instance (configured via an "instance-import from-ISPB-to-default" statement on local router) regardless of FBF rules trying to simply return the packet out the same interface it came in on, out the same VR it came in on.
The older Netscreen routers we replaced the SRX's with just did this automatically! I am hard-pressed to understand why any router wouldn't just by default return packets via the same interface they came in on and make you go through such trouble to avoid asymmetric routing.
The duplicatiion is OK for one or two sites but it gets old keeping up with the configuration as more sites and more businesss rules come into play. I am using 'apply-groups' where I can but still...
Just wondering if newer versions of Junos overcome this limitation so I can bring back Netscreen-like simplicity to the configuration, or barring that if someone conceptually can see a simpler way to do what I need to do. Thanks.