Do I need a NAT for traffic to pass??

[Stevenjwilliams83]

I have an SD-WAN device at my internet edge that will be doing the NATing for the network. This is so that the device can decide which of 3 ISPs to use to forward traffic. My Palo Altos sit behind this device and will do the firewalling and URL filtering. I did not deploy in vwire mode, I cant seem to get traffic to pass through so my quesiton is do I need a nat statement or something regardless of what my SD-WAN device is doing? 

[kiwi]

Hi @Stevenjwilliams83 ,

Is it a L3 setup ?

NAT shouldn't be required if you're just passing through the Palo Alto Networks device and you're performing NAT on another device although some additional info on your setup could be useful.

Do you see traffic ingressing and egressing the correct interface ? Are you seeing any return traffic ? Are you allowing the traffic and is your policy being hit ? Are you seeing any drops ?

Cheers !

-Kiwi.

[Stevenjwilliams83]

Correct Layer 3 setup.

I see the traffic in the logs but I am only seeing "aged-out". 

[kiwi]

Hi @Stevenjwilliams83 ,

I'm suspecting asymmetric traffic.  Is it possible that your return traffic is using a different route ?

Cheers !

-Kiwi.

[Stevenjwilliams83]

Negative, only path in and one path out.

[fjwcash]

What subnets do you have configured on your "WAN" port (connected to the SD-WAN device) and your "LAN" port?  Are they different?  Do you have the SD-WAN device set as the next hop in the Virtual Router for the default route (0.0.0.0/0)?

For a strictly L3 routing setup, you don't need NAT rules.  But you do need to have your VR setup correctly to route traffic between the WAN subnet and the LAN subnet.  And you need your Zones setup, and your Security Policy using the correct Zones.

So, we'd need to see a lot more info than you've given so far.

LAN interface has an IP/subnet that matches clients.

WAN interface has an IP/subnet that matches the private side of the SD-WAN device.

LAN devices --> default route points to LAN interface on the PA.

Virtual Router on the PA includes the two interfaces, has static routes that point to LAN subnet and WAN subnet via their respective physical interfaces, and has a default route that points to the SD-WAN device.

Security Policies allow traffic from "LAN" Zone to "WAN" Zone.

[Stevenjwilliams83]

So lets assume I am network engineer and I understand routing, because I do.

Eth1/1 - Zone Untrust IP:10.153.1.6/29

AE1 - Zone Trust IP:10.153.0.1/29

Vrouter - default

- Static route - 0.0.0.0/0 next hop 10.153.1.1/29 (CloudGenix SD-WAN)

AE1 connected to Layer 3 Cisco 3650. Ports connected to AE1 Interfaces on vlan 3101. Cisco Switch has interface vlan 3101 IP:10.153.0.2. Default route on Cisco switch 0.0.0.0 0.0.0.0 10.153.0.1

Palo Alto Vrouter peering OSPF with Cisco layer 3 switch for all internal networks. 

Eth1/1 is connected to a switch that is bridging the active/passive PAs with the CloudGenix SD-WAN device (all on vlan 3000) I created an SVI on this switch: interface vlan 3000 IP: 10.153.1.2.

From firewall CLI:

admin@CEN-EDGE-PA-01(active)> ping source 10.153.1.6 host 10.153.1.2
PING 10.153.1.2 (10.153.1.2) from 10.153.1.6 : 56(84) bytes of data.
--- 10.153.1.2 ping statistics ---
30 packets transmitted, 0 received, 100% packet loss, time 29015ms

So this is telling me the outside interface of palos cannot even get to the connected switch.....

Interfaces have Mgmt profile that is allowing network services SNMP and Ping

Policy allows ICMP and traceroute.

Routing says default route to SD-WAN device, routes to internal subnets are 10.153.0.2 which is SVI on cisco 3650 connected to AE1 interfaces on Palo. 

[fjwcash]

Does you rpolicy also allow the ping application, which is separate from ICMP (in Palo Alto terms)?  If not, then ping packets won't pass through the firewall.

[Stevenjwilliams83]

The issue was an upstream issue with pretty much a Cisco Layer 2 switch between the firewall and the SDWAN device. It would appear that the palo alto MAC address timelimit is longer then a Cisco Switch and was causing issues with this scenario because production traffic wasnt passing regularly. If it was I would have never seen the issue.