Quantcast
Channel: All SRX Services Gateway posts
Viewing all articles
Browse latest Browse all 17645

Re: SRX flowd problem

$
0
0

Thanks for the configuration. It's like I suspected but good to get confirmed.

 

First of all - to avoid any misunderstandings: firewall filters equals to access-list on eg. Cisco devices. The actual firewall rules are named 'security policies'. The security policies doesn't force return traffic back via the receiving interface for the initial flow.

 

The SRX uses the route table as it's source of truth for next hop of the traffic and in your case both vlan.3 and vlan.401 are placed in the global routing table named inet.0 with a next-hop for 0/0 towards 2.2.2.2 on ge-0/0/15.0 - so obviously a packet destined for 217.66.159.146 will go out this way even that it's received via vlan.401.

 

You have then solved the assymetrical routing via filterbased forwarding, where you via a firewall filter (access-list) manipulates the next hop of the traffic with source 192.168.0.0/24 on vlan.3. This is also just as expected.

 

Your options are as follows:

 

1) Create hide-nat in the Cisco FTD so traffic from 217.66.159.146 towards 192.168.0.0/24 are nat'ed behind 10.1.16.2. That way the SRX can send the return traffic correctly back to the FTD without configuring filter-based forwarding.

 

2) Create a seperate routing-instance (type virtual-router) on the SRX where you place vlan.401 and vlan.3.

There you configure the default route towards 10.1.16.2. If you need to reach other interfaces or routes from the inet.0 route table, you can import these into the new routing-instance. Remember to include import/export filters so the default route from inet.0 doesn't show up in your new routing-instance.

 

3) Keep using your filter-based forwarding with a firewall-filter on vlan.3. It's perfectly fine, security policies are still evaluated. Remember - this is just changing your next-hop, not disabling the firewall process (flow daemon). To disable the firewall process, the firewall filter should include terms with "then packet-mode". Otherwise security is still being enforced.

 

I hope this clarifies. Let us know if you have further questions.


Viewing all articles
Browse latest Browse all 17645

Trending Articles