Policy Based Forwarding - Enforce Symmetric Return

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Policy Based Forwarding - Enforce Symmetric Return

L3 Networker

Hi,

I am planning a firewall migration right now and trying to solve the problem that traffic comes in through two different interfaces during the migration (Internet through old firewall, Internet through new firewall). I was looking at policy based forwarding and stumbeled across the "e, nforce symmetric return" option, which unfortunately is not very well documented. Did anyone here use this yet and can shed some light on it for me?

If I understand it correctly, with this feature I could simply attach a PBF rule with no matching criteria (well, "any any") to an interface, select the "No PBF" action, and enable the "enforce symmetric return". Then traffic for that interface would always be routed back through the interface it came in through. Is this right?

Thanks

Sascha

1 accepted solution

Accepted Solutions

L4 Transporter

Hello,

Here's a good document with a network diagram which can help,

Hope that helps!

Thanks,

Aditi

View solution in original post

8 REPLIES 8

L4 Transporter

Hi Sascha

I think it is great to tackle new features, and I will be glad to try and answer your response.

I will attempt to write this out, but drawing it is a little easier.  :smileysilly:

For ease of example:

Eth1/1 connects to ISP1 (old FW??) (1.1.1.2)

Eth1/2 connects to traffic from ISP2 (2.2.2.1)

Eth1/4 connects to subnet(s) (10.x.x.x or whatever)

In the new FW, there is only 1 static route bound, and it point to the eth1/1 interface (next hop is ISP = 1.1.1.102)

Return traffic FROM the internet, comes in on ISP2 (and therefore eth1/2) (next hop is 2.2.2.101)

The traffic goes through the FW and leaves (to the trusted network

You symmetric return would look like this:

SOURCE (eth1/2)

Destination (10.x,x,x)

ACTION:  Forward

Egress Interface eth1/4

Enable Symmetric Return

Next Hop  (2.2.2.101)

The "NO PBR rule" states that it will fall back the virtual router (not what you want it to do.  You NEED a PBF Foward action rule)

PBF has to match a certain policy, hence the name :smileysilly:

In this example, as with other rules managing destination NAT, be sure to use the pre-NAT value for the destination address in the PBF rule since the rules are evaluated before the NAT changes are applied.


Thanks. Trying to wrap my head around this. So in your example, outgoing traffic would go out through ISP1/old_FW (the only static route on the PA), return traffic would come in through ISP2, go into trusted and response for that would go out through ISP2 again?

Say I have a DMZ and internet uplink on new_FW and a third interface to old_FW. Some traffic for DMZ server #1 is coming in through old_FW and some is coming in through new_FW. Could I use the enforce symmetric return feature to make sure response traffic from server #1 goes out the same interface the requests came in through?

and what is the NO PBF option good for if it basically disabled PBF?

So in your example, outgoing traffic would go out through ISP1/old_FW (the only static route on the PA), return traffic would come in through ISP2, go into trusted and response for that would go out through ISP2 again?

Yes... in a sense... WHAT if traffic comes INBOUND from ISP2?  The default route on the FW states to go out Eth1/1, but that is not where the traffic originated.  We need to enforce symmetric return. :smileysilly:

Could I use the enforce symmetric return feature to make sure response traffic from server #1 goes out the same interface the requests came in through?

Again, if the default GW is already eth1/1, then inbound traffic from Old_FW, going into the DMZ, would already go (based on the default GW) out eth1/1 (no need to enforce)

• No PBF—Do not alter the path that the packet will take.

This is a good question.  My only comment would be, depending on how granular your PBF rules are, there could be some unique matching characteristics where PBF would forward traffic, and you need to tell it to specifically NOT to do it.

I do not have a great example to provide you. 

Sorry, I am still not really getting it (might be a language barrier, not a native english speaker here). Let's say:

eth1 - old FW

eth2 - new FW (default route)

eth3 - DMZ

What I want:

Traffic for DMZ comes in at eth1: Send return traffic back out eth1

Traffic for DMZ comes in at eth2: Send return traffic back out eth2

For this I would put a PBF rule on the eth4 (DMZ) interface, right? The rule: src:any - dst:any - action:forward + enforce symetric return (next hop: eth1). DId I get that right?

As for "No PBF" action: Got it! Makes sense! Smiley Happy

Thanks!

You are somewhat correct.

My recommendation is I do not think you can put the src any and dest any.... you must create a policy, otherwise it matches ALL traffic.

Create an address group object of all subnets or addresses that you want to enforce on eth1

Yes sure, but I do want to match all traffic. I want all return traffic from the DMZ to go out the interface the requests came in through.

L4 Transporter

Hello,

Here's a good document with a network diagram which can help,

Hope that helps!

Thanks,

Aditi

It sure does, Aditi. Thanks a lot. It's basically how I understood in the first place (except for that I was thinking the PBF rules should be bound to the DMZ Interface, but it's the other way around). Kudos!

  • 1 accepted solution
  • 7755 Views
  • 8 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!