Gaming PCs and Consoles with DIPP NAT

[jsalmans]

Hi all,

I've been researching this for a while now and I've also opened a case on the issue.  Basically we just moved off of our Cisco ASA platform and on to our Palo Alto and I've run into a snag with gaming devices.  We're a university with quite a few on-campus students and they understandably want to be able to use their entertainment devices on the network.  This all seemed to work fine with the ASA... each building had a single public IP address for NAT and the ASA used Port Address Translation and the gaming devices showed they were behind a "Type 2" or "Moderate" NAT.

My new config is an Active/Active deployment and I've set up four public IP addresses for each building using DIPP.  Gaming devices, as well as some PC game and voice applications, now show they're behing a "Type 3" or "Strict" NAT.  Certain game and voice functionality will not work in this environment.

I know Palo Alto's first suggestion is Static NAT which is a bit problematic when we're talking about hundreds of devices.  Sure, it's possible but it's a bit of a management headache.  I'd love to just give them all public IPs and move away from NAT but we simply don't have enough IPv4.

I'm curious how others have resolved this?

[jsalmans]

@it-thomas I'll respond back to the case and ask about that.  If I remember correctly, there is a GUI setting now to allow or disallow asymetric traffic but it would be interesting if this was a cause... my understanding is that the firewall should be identifying if it is the owner of the session and, if not, pushing it across the HA link to the other firewall for processing.  As such, there shouldn't be any true asymetric traffic.

Also, my NAT rules are duplicated on both devices.  Originally I had though to separate them so that each device had two unique NAT IP addresses for each network and to advertise those out OSPF to our edge router.  This would essentially force return traffic to come back to the correct firewall.  However, after talking to the engineers and researching I realized if a firewall goes down, the other will just drop all return traffic since it doesn't have a NAT rule matching the IP addresses.

What I ended up doing was to create two versions of each NAT rule, both with the exact same IP address pools, and applying one to each firewall.  Then I advertised the entire range through OSPF out from each firewall.  This means that if a firewall fails the other should be able to process the traffic but the downside is returning traffic could go to the wrong firewall (but should then be routed to the proper one over the HA link as mentioned above).

My TAC engineer did look at packet captures and determined he didn't see a session being set up for the IP addresses Ubisoft was trying to reach... we're completely baffled on where the server is getting the idea to send traffic to that

*edit*

Not to derail the subjet but another solution just occured to me for the Active/Active NAT scenario I outlined above.  It might take more work and maintenance but I think it would both assist in enforcing return traffic to the correct firewall AND allow for a firewall to go down without simply dropping traffic.

• Split the 4 IP range I have now for each NAT pool so each has 2 IPs.. one pool would belong to firewall 0, the other to firewall 1.
• Continue to advertise the entire range through OSPF
• Add each pool to the HA Virtual Addresses as floating IPs setting the firewall priority accordingly so that each pool lives with it's owner firewall until one goes down.  Each NAT pool would now have a specific routes advertised out for the pools it owns and these would all migrate if a firewall goes down.
• Create two NAT rules for each firewall.  First rule is the one that firewall is designed to use for outgoing NAT.  The second rule uses the NAT pool the other firewall will use, but, since it is second, it should never get hit for outgoing use.  Instead it is just there to have a matching NAT rule for any return traffic still active if the other firewall goes down.

4 IP address pools is a bit overkill for DIPP with our traffic load... our ASA was doing Dynamic PAT with 1 address used... so 2 in each pool should handle all of the traffic if one firewall is down.

[jsalmans]

One of our Sales Engineers got back to us and let us know the feature request has been added and that priority is at least partially based on the number of similar requests so here is the information for anyone who wants to reach out to their team and add to it:

Feature Request:

FR ID: 7654

Requesting support of DIPP with non-strict recognition by devices.

*Edit* The feature request got resubmitted and got a new ID so I updated the ID here.