11-18-2012 04:40 PM
Hello all,
I have a question if Destination NAT with PBF is supported.
I have two site A and B. All internet bound traffic is supposed to go out site A. Site B sends its traffic over a VPN tunnel to site A due to a default route. There are however some devices that rely on the public IP's given to us so I had to maintain the static NAT locally.
The solution I came up with was a PBF that would take the traffic from these servers and if destined for public it would send out the local internet facing port with its static nat and if it was internal it would go over the VPN tunnel.
The problem I am having is that site B's firewall is NAT'ing the incoming traffic correctly according to logs and packet captures but the return traffic is getting lost somewhere. When I did not have the PBF in and all traffic heading out locally the static NAT's worked perfectly. I was able to also test to make sure the outbound traffic for these devices headed out site B and they do. So I do not know where the packet is getting lost. According to the packet captures on the firewall I see the correct addresses but the 3-way handshake is never completing.
Anyone have any ideas? I was thinking about going with virtual routers but these servers are mixed between trust and dmz traffic.
Thanks in advance.
11-19-2012 12:27 AM
Would the new return to sender feature in PANOS 5.0 be something of your taste?
"
Symmetric Return (Return to Sender) – This feature extends the functionality of Policy Based Forwarding (PBF) rules to circumvent the route lookup process and the subsequent PBF lookup for return traffic (server to client). The firewall will use the original incoming interface as the egress interface. If the source IP is in the same subnet as the incoming interface on the firewall, symmetric return will not take effect. This feature is useful when you have servers accessible through two ISP connections (on different ingress interfaces) and the return traffic must be routed through the ISP that originally routed the session.
"
11-19-2012 11:21 AM
Yes that sounds like it would fix the issue however, we are really hesitant to jump on a .0 release. Usually wait for a couple of hot fixes to roll in.
11-19-2012 04:27 PM
Personally I dont think it really matters if it says .0 or .8 as with 4.1 series where even 4.1.8 had one or another serious bug.
As I understand 5.0.0 contains the same fixes as 4.1.9 so if you are happy to run 4.1.9 you should be equally happy to run 5.0.0.
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!
