We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

------------------------------
JOHN WILLIAMSON
------------------------------

This is zero help but your config looks ok to me. Not sure I tested this on a SRX though. 

filter FBF_1 {

    term 1 {

        from {

            source-address {

                100.0.0.126/32;

            }

        }

        then {

            routing-instance ROUTING_TABLE_NORTH;

        }

    }

   term 2 {

        then accept;

    }

}

root@ISP1-R12# show interfaces ge-0/0/5 

unit 0 {

    family inet {

        filter {

            input FBF_1;

        }

      }

}

[edit]

root@ISP1-R12#

root@ISP1-R12# show routing-instances                       

ROUTING_TABLE_NORTH {

    instance-type forwarding;

    routing-options {

        static {

            route 0.0.0.0/0 next-hop 192.168.31.9;

        }

    }

}

root@ISP1-R12# show routing-options

interface-routes {

    rib-group inet COPY_INET_ZERO;

}

rib-groups {

    COPY_INET_ZERO {

        import-rib [ INET.0 ROUTING_TABLE_NORTH.INET.0 ];

    }

}

 
------------------------------
JNCIE-ENT 907
------------------------------

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

Nikolay,

"In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself."

This is our firewall which is beyond any gateway device.  The next-hop is the IP of the interface reth2, one of two interfaces that our IPSs are connected to.  We have a pool of public IPs provided from each of our ISPs and the one I have listed in the filter is one of the IPs from one of the ISPs. 

"if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface"

See the previous answer. 

"Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?"

I've used mixed capital andlower-case letters in plenty of my configs. I guess I'm not superstitious. 

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

Nikolay,

We based our filter on this one, which also has two ISPs, but in our case, we are not trying to create an HA configuration, just force traffic out one interface. They reference the IP of the interface.

https://supportportal.juniper.net/s/article/How-to-configure-Filter-Based-Forwarding-on-SRX-for-a-typical-dual-ISP-scenario?language=en_US

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

"On ethernet connections, the next-hop address is the address of the device where traffic should go next, so in your case that's the ISP's address"

I will dig into this, but I am not quite sure that is required because we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. 

Another source: https://jncie.wordpress.com/wp-content/uploads/2008/09/350136_filter-based-forwarding.pdf

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

"we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. "

If those routes are in inet.0 then they won't matter for traffic that's trying to use Net-route-table.inet.0 for routing.

Consider, on an ethernet network, the SRX needs to put some destination MAC address in the outgoing frame. It uses the outgoing interface for the SOURCE MAC address, and the uses ARP on the next-hop address to determine the DESTINATION MAC address. It makes no sense to put the address of the SRX interface itself as the next-hop because the destination MAC address of the frame would then be the same as the source MAC address.

"On ethernet connections, the next-hop address is the address of the device where traffic should go next, so in your case that's the ISP's address"

I will dig into this, but I am not quite sure that is required because we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. 

Another source: https://jncie.wordpress.com/wp-content/uploads/2008/09/350136_filter-based-forwarding.pdf

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

Nikolay,

I need to confirm our gateway on the primary ISP.   What I have in my records can be seen outside our network. I can ping it from a device on cell service.  That means even going out our secondary ISP could still find it. That would mean using that as the next hop would not guarantee the traffic would be forced to go out the primary ISP interface. 

"we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. "

If those routes are in inet.0 then they won't matter for traffic that's trying to use Net-route-table.inet.0 for routing.

Consider, on an ethernet network, the SRX needs to put some destination MAC address in the outgoing frame. It uses the outgoing interface for the SOURCE MAC address, and the uses ARP on the next-hop address to determine the DESTINATION MAC address. It makes no sense to put the address of the SRX interface itself as the next-hop because the destination MAC address of the frame would then be the same as the source MAC address.

"On ethernet connections, the next-hop address is the address of the device where traffic should go next, so in your case that's the ISP's address"

I will dig into this, but I am not quite sure that is required because we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. 

Another source: https://jncie.wordpress.com/wp-content/uploads/2008/09/350136_filter-based-forwarding.pdf

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

I'm getting lost a little bit in what you mean about "finding" "it," "local static route," and other aspects. Your configuration snippet is extremely limited, so I'm not sure I have a good picture of what you're dealing with and what you're trying to achieve.

Generally, dual-ISP setup looks something like this:

The "Gateway" addresses x.x.x.2 and y.y.y.2 are assigned to ISP equipment, under ISP control. I'm not sure what you mean by "find" exactly, but the ISPs decide whether those addresses can be pinged from the internet or not. Some ISPs allow it, some don't, and I imagine if you were to request it one way or the other, some ISPs would honor your request and set their configuration accordingly, and some won't honor your request. 

You're in control of the pings to the addresses assigned to your SRX -- x.x.x.1 and y.y.y.1 -- and your configuration will determine if the SRX will respond to ping on those.

And in any case, I also don't see how pinging gateway addresses from an external device (your phone) is relevant to your original question about Filter-Based Forwarding.

If your situation doesn't match the diagram above, please clarify. Actually, now that I look at your configuration again, I'm not sure reth1 is going to ISP1. In fact, seems more likely that reth1 is facing your internal network. But reth2 is going to ISP2, right?

Anyway, please provide more information / configuration.

Assuming your firewall filter is correctly matching the e-sports devices, pick some destination address z.z.z.z they're trying to reach and check what route would be selected for that destination with: show route z.z.z.z table New-route-table.inet.0

If the New-route-table instance is configured correctly, the output of that command should indicate a 0.0.0.0/0 route using interface reth2 showing the x.x.x.2 address as next hop.

The routes configured / active in the main inet.0 table are irrelevant. Whether you can ping a gateway address from the internet or not is also irrelevant.

Nikolay,

I need to confirm our gateway on the primary ISP.   What I have in my records can be seen outside our network. I can ping it from a device on cell service.  That means even going out our secondary ISP could still find it. That would mean using that as the next hop would not guarantee the traffic would be forced to go out the primary ISP interface. 

"we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. "

If those routes are in inet.0 then they won't matter for traffic that's trying to use Net-route-table.inet.0 for routing.

Consider, on an ethernet network, the SRX needs to put some destination MAC address in the outgoing frame. It uses the outgoing interface for the SOURCE MAC address, and the uses ARP on the next-hop address to determine the DESTINATION MAC address. It makes no sense to put the address of the SRX interface itself as the next-hop because the destination MAC address of the frame would then be the same as the source MAC address.

"On ethernet connections, the next-hop address is the address of the device where traffic should go next, so in your case that's the ISP's address"

I will dig into this, but I am not quite sure that is required because we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. 

Another source: https://jncie.wordpress.com/wp-content/uploads/2008/09/350136_filter-based-forwarding.pdf

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

Nikolay,

"And in any case, I also don't see how pinging gateway addresses from an external device (your phone) is relevant to your original question about Filter-Based Forwarding."

If both paths, ISP1 and ISP2 can discover a way to the Gateway of ISP1 is it possible that traffic could go out the ISP2 interface to get to the gateway I put into the filter?   If I can specify the interface leading to ISP1 then I don't have any issues with traffic going out the ISP2 interface. 

I'm getting lost a little bit in what you mean about "finding" "it," "local static route," and other aspects. Your configuration snippet is extremely limited, so I'm not sure I have a good picture of what you're dealing with and what you're trying to achieve.

Generally, dual-ISP setup looks something like this:

The "Gateway" addresses x.x.x.2 and y.y.y.2 are assigned to ISP equipment, under ISP control. I'm not sure what you mean by "find" exactly, but the ISPs decide whether those addresses can be pinged from the internet or not. Some ISPs allow it, some don't, and I imagine if you were to request it one way or the other, some ISPs would honor your request and set their configuration accordingly, and some won't honor your request. 

You're in control of the pings to the addresses assigned to your SRX -- x.x.x.1 and y.y.y.1 -- and your configuration will determine if the SRX will respond to ping on those.

And in any case, I also don't see how pinging gateway addresses from an external device (your phone) is relevant to your original question about Filter-Based Forwarding.

If your situation doesn't match the diagram above, please clarify. Actually, now that I look at your configuration again, I'm not sure reth1 is going to ISP1. In fact, seems more likely that reth1 is facing your internal network. But reth2 is going to ISP2, right?

Anyway, please provide more information / configuration.

Assuming your firewall filter is correctly matching the e-sports devices, pick some destination address z.z.z.z they're trying to reach and check what route would be selected for that destination with: show route z.z.z.z table New-route-table.inet.0

If the New-route-table instance is configured correctly, the output of that command should indicate a 0.0.0.0/0 route using interface reth2 showing the x.x.x.2 address as next hop.

The routes configured / active in the main inet.0 table are irrelevant. Whether you can ping a gateway address from the internet or not is also irrelevant.

Nikolay,

I need to confirm our gateway on the primary ISP.   What I have in my records can be seen outside our network. I can ping it from a device on cell service.  That means even going out our secondary ISP could still find it. That would mean using that as the next hop would not guarantee the traffic would be forced to go out the primary ISP interface. 

"we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. "

If those routes are in inet.0 then they won't matter for traffic that's trying to use Net-route-table.inet.0 for routing.

Consider, on an ethernet network, the SRX needs to put some destination MAC address in the outgoing frame. It uses the outgoing interface for the SOURCE MAC address, and the uses ARP on the next-hop address to determine the DESTINATION MAC address. It makes no sense to put the address of the SRX interface itself as the next-hop because the destination MAC address of the frame would then be the same as the source MAC address.

"On ethernet connections, the next-hop address is the address of the device where traffic should go next, so in your case that's the ISP's address"

I will dig into this, but I am not quite sure that is required because we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. 

Another source: https://jncie.wordpress.com/wp-content/uploads/2008/09/350136_filter-based-forwarding.pdf

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

"On ethernet connections, the next-hop address is the address of the device where traffic should go next, so in your case that's the ISP's address"

I will dig into this, but I am not quite sure that is required because we have a local static route on the firewall for all internal traffic next-hop to the two ISPs gateways. 

Another source: https://jncie.wordpress.com/wp-content/uploads/2008/09/350136_filter-based-forwarding.pdf

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }

As written in the snippet you provide, the filter term should match all traffic. If there were actual conditions that were simply omitted from your post, then add a "counter" action to that filter term so you can see if things are getting matched.

In the New-route-table instance, the 0.0.0.0/0 route should specify the address of the other device (gateway) connected to reth2, not the ip_of_reth2 itself.

This really doesn't matter, but if traffic coming on reth1 can only go to the internet (via reth2) and no other place via any other interface, then you really don't need to import any routes into the new routing instance.

Lastly, out of superstition maybe use only lowercase letters for the routing-instance name?

We have a simple filter setup to ensure that specific source IPs get routed out one interface on the SRX.  When I added it to the SRX config, it did not appear to have any hits on traffic going through it, as if nothing met the criteria to apply to the filter. 

In a nutshell, I want a given group of IPs entering the SRX on reth1 to be sent out the SRX on reth2.  Can anyone see a reason this filter would not match traffic?  I have confirmed that the IP for reth2 is in the route table.

[edit interfaces reth1]
+    unit 1500 {
+        family inet {
+            filter {
+                input classify-Outgoing-Interface;
+            }
+        }
+    }
[edit firewall]
+   filter classify-Outgoing-Interface {
+       term eSports-Devices {                               ## The groups of IPs to send out reth2
+           then {
+               routing-instance New-route-table;
+           }
+       }
+   
+       term default {
+           then accept;
+       }
+   }
[edit routing-instances]
+   New-route-table {
+       instance-type forwarding;
+       routing-options {
+           static {
+               route 0.0.0.0/0 next-hop (ip_of_reth2 interface) ;  ## real IP removed for this example
+           }
+       }
+   }
[edit routing-options]
+   interface-routes {
+       rib-group inet fbf-group;
+   }
+   rib-groups {
+       fbf-group {
+           import-rib [ inet.0 New-route-table.inet.0 ];
+       }
+   }