Routing through same interface

[myrdin]

HI

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:

192.168.1.254

192.168.1.200

192.168.2.1 

so there is bidirectional communication,

but again apart from ping nothing else passes. I have put another dumb router, and everything perfectly works. 

thanks

[bmorris1]

Hi Myrdin,

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,

Ben

[santonic]

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?

[reaper]

Hi

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 ?

How to Configure U-Turn NAT

Video Tutorial: How to Configure U-Turn NAT

[santonic]

Yeah, source NAT to PA address would do the trick as well.

[reaper]

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 😉

[santonic]

Totally agree about asymmetric routing. But he said he already disabled that 🙂

[myrdin]

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,

thanks heaps

[myrdin]

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

thanks

[santonic]

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.

[santonic]

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.

From CLI:

show counter global name tcp_drop_packet

And if you want to turn off asymetric check on WHOLE PA appliance for all zones:

configure

set deviceconfig setting tcp asymmetric-path bypass

But if i understand correctly you already did that?

[reaper]

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

[myrdin]

thanks guys.

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

[santonic]

Palo Alto is slow? You have obviously never tried firewalls from other manufacturers 🙂

[reaper]

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 🙂