I have a PA 500, running 4.0.5 and I have two zones that are 'special' : PCI and DMZ. Both are setup identically but only one works. Here is how it is:
Zones: Rest1 (Tunnel.1), DMZ (1/8), External (1/1, 1/7), Internal (1/1, tunnel, Tunnel.2), PCI (1/6) and WiFi (1/4). Both Trust and Untrust show up but only as Virtual-Wire, no zones or VS.
VR1: Has a static route for for DMZ of 172.16.60.0/24 to Int 1/8, no next hop (PCI is setup same except for 1/6 and 172.16.50.0/24)
PCI and DMZ are both setup with an Interface: 172.16.50.254 (PCI) on 1/6 and 172.16.60.254 (DMZ) on 1/8. These IP addresses are used as the GW in the TCP/IP setup.
Both interfaces HAD a switch connected to them and devices connected via the switch. The switch uses vLAN to seperate the zones. I have disconncted the switch on the DMZ port and directly connected a test machine to port 1/8.
There is a rule that allows Internal Zone to go EVERYWHERE.
There WERE rules that allowed the DMZ to EXTERNAL (worked) and the DMZ to Internal (did not work) and were COPIED form existing rules that that were, and are, working on the PCI zone. I have ripped these out and am working on replacing from scratch.
On the core switch, a route sends all unknown traffic to the Palo Alto 1/1. Normally the core switch has a connection to the relevant interface (1/6 for PCI and 1/8 for DMZ) and uses vLAN tagging.Since the interface is the def GW, I don't think core routing is an issue but listed nonetheless.
As setup, with no rules with the DMZ at all I can hit and RDP to the test box. The test box can be ocntrolled and pinged form INTERNAL but cannot ping nor get out from DMZ (as presently configured); when I had the rules in place I could ping 126.96.36.199 but not local devices (such as teh computer controling it by RDP).
I had taken all the DMZ rules and placed them at the top of the rules list but it made no difference.
Any ideas what oculd be the proble, or how to either fix or troubleshoot? I'm going to try building the rules again from scrtach and hope it was something malformed or fat-fingered. of course, that is what I did earlier today, anyway.
Any suggestions or help most welcome.
I'm continuing to be very confused. When I had a rule in place allowing DMZ to internal traffic, I saw traffic and the logs showed it as allowed even if the pings failed.
I have since ripped out those rules and am still pinging. The pings are not going through but they are not showing up in the traffic logs as denied either. My RDP to it IS showing up.
/gun to head
Hi...I recommend checking the routing table for VR1. You only mentioned static routes to DMZ & PCI but not other routes. You should not need these static routes since they are directly connected to the PAN firewall.
I assume you have default 0.0.0.0/0 route to EXTERNAL? Do you have a static route 172.16.0.0/16 with thew core switch as the next-hop?
Message was edited by: rmonvon
Actually solved it and for those that follow, here is how:
We have a policy based route that sent everything form our desktop vLAN that was not directed to internal addresses out one of the ISPs. unfortunately when that was setup, the DMZ addresses were not defined and not included. So when I pinged into the DMZ, it sent it out to the internet. Once I updated the PBF section with the DMZ subnet, it started working (I would add 'as designed' but it was working as designed, I just had poorly designed it).
The funny thing was I called PA Support and they correctly diagnosed it as routing issue... but said it had to be a routing issue elsewhere as nothing on the Palo could be causing this. So points for identifyingthe issue, minus points for sluffing if off onto another device.
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!