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 have asymmetric routing and TCP sessions don't like that. If you allowed asymmetric TCP sessions on your PA then I guess 192.168.1.200 must be a firewall and not just a router?
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 ?
Disabling TCP checks and the asymmetric protection is generally a bad idea,I would strongly advise against it
the only alternative is to add static routes on all the clients which is a PITA ;)
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,
also guys is it possible to check (and how) somewhere whether a packet is being discarded because of the asymettric problem reason, because from the traffic logs i cant see anything being discarded
Yes, ICMP protocol (ping) survives asymmetric routing. While TCP doesn't if it's a session state aware firewall on the way.
You can see if NAT is working in traffic logs, you just need to add the SNAT or DNAT coloumn to your view.
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!