just ran into a very weird issue today. A PA running version 7.1
The PA has IP 192.168.1.254 and it is the default gateway for the network. There is another network 192.168.2.0/24 reachable through 192.168.1.200. There is a route in the PA that says to reach 192.168.2.0/24 go to 192.168.1.200. This is same-zone routing. I have also disabled the thingy to allow asymetric routing.
I have a rule that allows same zone traffic as a client will get to 192.168.1.254 to reach 192.168.2.0/24 via 192.168.1.200
Now the issue: if i am sitting on a client with ip 192.168.1.1 and ping 192.168.2.1 (which is a host in the 2.0/24 network) i can actually ping but nothing else works. i.e. 192.168.2.1 is a webserver and i should be able to browse to it. There is no rule blocking https, but it simply does not work. No logs either, i get logs about the pings.
Trace goes like this:
so there is bidirectional communication,
but again apart from ping nothing else passes. I have put another dumb router, and everything perfectly works.
You can try overriding the default intrazone rule and set this to log in order to see the traffic, by default intrazone traffic is allowed and not logged. Additionally if there are no logs have you considered running a packet capture to 100% verify that traffic is indeed getting to the firewall and passing through correctly? Though I would advise you try and log the traffic first. Also are you running any source NAT? Check to see if you have set the source zone to 'any' and change this to the correct zone.
hope this helps,
you will actually need to apply a little trick called U-Turn NAT, this is because this routing setup introduces asymmetric routing:
client A sends a packet which goes to the default gateway PANW, it forwards the packet to the router and on to the final destination clientB. so far so good.
The client responds to the syn with an ack and sends that to the router, the clientA machine, however, is directly connected to the router so the packet is delivered directly. It does not pass by the PANW
This causes the initial session that was createrd on the firewall to not see the ack, and the session is timed out (handshake incomplete). The next packet sent by clientA is not a SYN and no longer corresponds to an existing session or does not match the sequence, so it is discarded.
The trick is to apply source-nat, applying the firewall's own IP as the NAT source, that way any reply packets from clientB will be forwarded to the firewall and then returned to clientA
hope this makes sense ?
thanks all you guys heaps.
I will try the U-TURN, i didnt know i would need this kind of configuration in an asymetric routing situation.
Would this explain the fact that ping was passing but not https connection? Is that because https will start a tcp handshake and ping does not use TCP (so no ACK etc)?
I can troubleshoot via the monitor but i dont know a way to sniffer the packets via ssh, is there a troubleshooting guide somewhere? or do you guys can give me some commands i can use? I essentially need to sniffer the NAT translations to see whehter it is hitting a NAT rule it shouldnt and actually see the traffic at very low level on that LAN interface,
You can do packet capture in GUI with apropriate filters and look at what is cpatured in drop stage of processing.
You can also monitor global counters, but here you will just see counter increasing and not which packet was actually dropped.
show counter global name tcp_drop_packet
And if you want to turn off asymetric check on WHOLE PA appliance for all zones:
set deviceconfig setting tcp asymmetric-path bypass
But if i understand correctly you already did that?
Please check out this article regarding packetcaptures 🙂 Getting Started: Packet Capture
Please be very careful with the asymmetric-path configuration as it could open up unexpected avenues of attack : sessions bypassed this way will not be L4-L7 scanned by appID/contentID and could contain malicious payload you will not be able to identify, this setting is global so could also impact packets coming from untrusted networks.
For more information regarding the impact of the setting: Palo Alto Networks TCP Settings and Counters
I thought about it and i came to the conclusion that the Palo is slow already as it is, if i even am to add a NAT to translate WITHIN the LAN every packet to another internal segment, it will catch fire.
I found an article that explains how to create a zone protection and i will apply on the trust zone only so to avoid enabling the bypass globally, and in the zone protection to avoid dropping traffic because of the syn sequential number problem
thanks to all pointing in the right direction
also, any latency you might experience is purely the management plane, the dataplane has it's own set of cpu/memory/... and is quite fast
you can check available resources for both planes with these commands:
Dataplane > show running resource-monitor Managementplane > show system resources
please consider going with the NAT option, I promise your firewall won't catch fire 🙂
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!