- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
07-17-2013 08:58 AM
ta, Im having a heck of a problem.
One zone out to an ftp server is working frie but from another zone the conputers can connect but they cant get file listings of xfer data ata ll. Routing is fine, obviously, the rules they are hitting is ok, NAT and Sec.
Both connections go through two VRs to get out to the ftp server. One zone hits two rules, the other only hits one.
Im running out of ideas of things to check.
Anyone else here have this problem in the past? What was the issue? Thanks.
07-18-2013 12:43 PM
5.x:
set deviceconfig setting tcp asymmetric-path bypass bypass-exceed-oo-queue yes
Here are all the options under asymmetric-path:
admin@PA-200# set deviceconfig setting tcp asymmetric-path bypass
+ bypass-exceed-oo-queue whether to skip inspection of session if out-of-order packets limit is exceeded
+ check-timestamp-option whether to drop packets with invalid timestamp option
+ urgent-data clear urgent flag in TCP header
<Enter> Finish input
admin@PA-200#
prior versions:
set deviceconfig setting tcp asymmetric-path bypass yes
This disables the sliding window and sequence number checking. Looks like you are doing asymetric routing and the firewall is dropping tcp out of sequence packets.
Hope that helps.
-chadd.
07-17-2013 09:16 AM
oh and ive tried both passive and active connection types.
07-17-2013 09:23 AM
Hi,
You can also do the following to see what might be causing the issue
1. Need to setup the filters for the traffic we are interested in. To do this, execute the following steps:
Navigate to Monitor--Packet Capture
Click 'Manage Filters'
Set Filter ID 1 to be the source IP and destination IP of traffic you feel is affected ( leave all other fields blank )
Set Filter ID 2 to be the exact inverse of what you did in step 3 (destination IP in source field, Source IP in destination field)
2. Setup up the captures
Create and name the file stage for a packet capture on all the stages (receive, transmit, firewall and drop)
3. Enable filters and captures
debug dataplane packet-diag set filter on
debug dataplane packet-diag set capture on
4. open 2 CLI windows
on 1 run the following command to look at the counter ( make sure it run this command once before running the traffic)
show counter global filter packet-filter yes delta yes
on the 2nd window run the following command to look at he sessions
show session all filter source <ip address> destination <ip address>
5. Now run the test for ftp while it is failing to look at the counters and captures and sessions to determine what is causing the issue.
6. Once you have finished testing and capturing. Make sure to turn off the debugs.
Hopefully this helps you resolve your issue.
Thank you
07-17-2013 09:54 AM
thanks very much, i will try that out asap.
07-17-2013 03:10 PM
thanks again, that worked, well just going to review the files.
btw, i guess the CMD line stuff is just to make sure its actually working/capturing as you test ..?
07-17-2013 05:50 PM
You may also want to check the path of the FTP transfer that is not working, to make sure that the return path does not need a route between VRs. If it does, you may need to add a route which says "Next VR", so the return traffic gets back. Just a thought. I like the suggestion from mbutt as well, that should point you in the right direction.
-chadd.
07-18-2013 09:38 AM
thanks for the reply,
im sure the routes are ok as i can always login to the ftp server just fine, its just everything stalls on the LIST command in one PA zone, but its fine in another.
I have the captures, there is about 30 packets in the drop pcap but they are from/to ips/ports that are allowed. I have to dig around a bit more.
07-18-2013 11:20 AM
so, ive got a pcap capture from one ftp connection out from our machine that does not work, and there are two dropped packets (see wireshark screen for example)
both packets dropped were 192.168.* -> 205.207.*:50046 (its reaching out to make the data connection via passive mode)
however the same type of packet that was dropped above, is also allowed (according to the PA logs).
FYI: the client PC that DOES work to this ftp server never reaches out to a random port for passive mode, doesnt even reach out to port 20, according to the logs.. it only reached out to port 21, or thats all i see anyways.
Not sure where to go from here.
07-18-2013 11:54 AM
When your packet filter is set up as mbutt recommended, run:
show counter global filter packet-filter yes delta yes
This will tell you why the packets are being dropped. Anything with a 'drop' message is an indication of what is happening. Just make sure to run that command once before the test starts to clear the counter stats.
From the screenshot, it shows a length of 0 on that packet, so I assume it is a SYN on that port. As long as the firewall is able to read the initial setup packets, and there's a rule allowing FTP, it will create a 'predict' session matching the chosen PASV port and allow that traffic.
What do you see from the global counter output?
-Greg
07-18-2013 12:10 PM
thanks, seems packets that are 'out of window' are being dropped.
only one link in forum i found
https://live.paloaltonetworks.com/message/14806#14806
maybe i could disable this ... function ..
im not sure what the window error is.
07-18-2013 12:43 PM
5.x:
set deviceconfig setting tcp asymmetric-path bypass bypass-exceed-oo-queue yes
Here are all the options under asymmetric-path:
admin@PA-200# set deviceconfig setting tcp asymmetric-path bypass
+ bypass-exceed-oo-queue whether to skip inspection of session if out-of-order packets limit is exceeded
+ check-timestamp-option whether to drop packets with invalid timestamp option
+ urgent-data clear urgent flag in TCP header
<Enter> Finish input
admin@PA-200#
prior versions:
set deviceconfig setting tcp asymmetric-path bypass yes
This disables the sliding window and sequence number checking. Looks like you are doing asymetric routing and the firewall is dropping tcp out of sequence packets.
Hope that helps.
-chadd.
07-18-2013 01:25 PM
ok, thanks, im going to try turning that off then.
07-18-2013 02:43 PM
thank you sweet lord problem solved. thanks very much for all the help. man that was a doozey.
show counter global filter packet-filter yes delta yes
thats one hell of a command and im going to make sure i make good use of it in the furture.
10-06-2013 07:11 PM
Hello cchristiansen,
Its command could be applied after system rebooted? right? or applied immediately when commanding on CLI?
Thanks.
Regards,
Roh
10-07-2013 01:38 AM
You're in configure mode and it will work immediately as I know.And also it will stay after reboot.
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!