01-02-2013 10:16 AM
I am running my PA-2050 on layer 2. The system runs great except for one issue. My wireless zones are subnetted. The PA can see the subnetted traffic, allows it to go out, but the packets get lost on the return back. I know there is nothing wrong with any devices in the upstream since all other content filtering systems we have ran before never had a problem with the subnets. Any suggestions?
01-08-2013 03:48 AM
Hi Steve
Looks like you have a lot of non-syn drops.. these are usually caused by asymmetric routing.
This could also explain why ping seems to work but tcp not so much, as ping is stateless and will usually find it way back regardless of which route it takes.
Can you give this cli command a shot to see if this improves your connectivity: > set session tcp-reject-non-syn no
Next step would be to figure out where the asymmetry lives, by going over each hop from the AP out to the internet and doublechecking routing tables (make sure there are both inbound and outbound routes for the wifi subnets and default gateways etc. on every single hop) and verifying if there's any static/faulty arp entries that could be interfering with proper routing.
kind regards
Tom
01-02-2013 12:31 PM
Is this a new install or has it worked before? Are other networks connected to the PA affected? Can you ping your wireless subnets from the upstream device?
AK
01-02-2013 12:44 PM
This is a new install. Our main production network is connected and works great. It's only the wireless subnets that are the issue. I can ping back from any upstream device back to the workstation without any issue. I can even tracert to any site such as google without any problems. I just can't get the return packets to get Internet access in these subnets.
01-02-2013 12:45 PM
What's the upstream device?
01-02-2013 12:50 PM
So if I understand correctly from your description the traffic is passing through the Paloalto in outbound direction and the return traffic hitting Paloalto and is getting blocked . Are you able to see the sessions on Paloalto ? If so how are the sessions, are they stuck in incomplete ? The weird thing is that you are saying the ping and the trace route from the upstream is working fine which makes me believe that you are having proper routes. Also please check your NAT and security policies.
Tx,
Sandeep T
01-02-2013 12:53 PM
Cisco ASA 5520. Everything worked great with the current configs until we installed the PA. We had a Cymphonix content filter before this and didn't have any routing issues. The PA is using the same IP address as the previous filter so no routes would need to be updated. We had a Cisco tech verify the configs once more and they are very adamant that it's the PA that is the issue.
01-02-2013 12:55 PM
Sandeep,
You are correct in your understanding. The session is visible and stuck in incomplete.
Steve
01-02-2013 01:48 PM
If the session is incomplete means the TCP hand shake is not complete. So try to see the monitor logs on Paloalto and check if paloalto is dropping the return traffic. If you do not find anything useful there then you have to set your packet filters to match the traffic of our interest and run the counters to see if there is any drops and the reason for the same.
Once you have the filters correct try to run the following command from the cli to see the drop counters
"show counter global filter delta-yes packet filter yes | match drop"
Run this a couple of time with 10 seconds delay and look for the output. If you do find any drops you will the reason for the drops too.
I would advise you to open a ticket with support so we can help you !!!
01-03-2013 07:26 AM
Here is the output that I get:
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_policy_nofwd 2 0 drop flow session Session setup: no destination zone from forwarding
flow_tcp_non_syn_drop 88 1 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 6637 76 drop flow forward Packets dropped: no desitnation MAC
flow_fwd_l2_same_interface 4 0 drop flow forward Packets dropped: destination MAC on same interface
flow_action_close 30 0 drop flow pktproc TCP sessions closed via injecting RST
url_request_pkt_drop 5 0 drop url pktproc The number of packets get dropped because of waiting for url category request
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 13 0 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 1974 76 drop flow forward Packets dropped: no desitnation MAC
flow_fwd_l2_same_interface 12 0 drop flow forward Packets dropped: destination MAC on same interface
flow_action_close 9 0 drop flow pktproc TCP sessions closed via injecting RST
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 5 2 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 144 70 drop flow forward Packets dropped: no desitnation MAC
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 1 0 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 165 62 drop flow forward Packets dropped: no desitnation MAC
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 1 0 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 173 73 drop flow forward Packets dropped: no desitnation MAC
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 9 2 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 270 86 drop flow forward Packets dropped: no desitnation MAC
flow_action_close 1 0 drop flow pktproc TCP sessions closed via injecting RST
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 10 2 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 329 80 drop flow forward Packets dropped: no desitnation MAC
flow_action_close 6 1 drop flow pktproc TCP sessions closed via injecting RST
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_fwd_l2_nomac 147 62 drop flow forward Packets dropped: no desitnation MAC
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 1 0 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 311 96 drop flow forward Packets dropped: no desitnation MAC
flow_action_close 6 1 drop flow pktproc TCP sessions closed via injecting RST
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 5 1 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 283 80 drop flow forward Packets dropped: no desitnation MAC
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 3 1 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 226 76 drop flow forward Packets dropped: no desitnation MAC
flow_fwd_l2_same_interface 1 0 drop flow forward Packets dropped: destination MAC on same interface
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 4 0 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 448 96 drop flow forward Packets dropped: no desitnation MAC
url_request_pkt_drop 1 0 drop url pktproc The number of packets get dropped because of waiting for url category request
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 9 2 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 202 61 drop flow forward Packets dropped: no desitnation MAC
flow_action_close 1 0 drop flow pktproc TCP sessions closed via injecting RST
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 6 1 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 261 74 drop flow forward Packets dropped: no desitnation MAC
flow_fwd_l2_same_interface 1 0 drop flow forward Packets dropped: destination MAC on same interface
flow_action_close 2 0 drop flow pktproc TCP sessions closed via injecting RST
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 4 1 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 249 82 drop flow forward Packets dropped: no desitnation MAC
admin@PA-2050> show counter global filter delta yes packet-filter yes | match drop
flow_tcp_non_syn_drop 2 0 drop flow session Packets dropped: non-SYN TCP without session match
flow_fwd_l2_nomac 328 76 drop flow forward Packets dropped: no desitnation MAC
01-08-2013 03:48 AM
Hi Steve
Looks like you have a lot of non-syn drops.. these are usually caused by asymmetric routing.
This could also explain why ping seems to work but tcp not so much, as ping is stateless and will usually find it way back regardless of which route it takes.
Can you give this cli command a shot to see if this improves your connectivity: > set session tcp-reject-non-syn no
Next step would be to figure out where the asymmetry lives, by going over each hop from the AP out to the internet and doublechecking routing tables (make sure there are both inbound and outbound routes for the wifi subnets and default gateways etc. on every single hop) and verifying if there's any static/faulty arp entries that could be interfering with proper routing.
kind regards
Tom
01-08-2013 07:06 AM
Tom,
That did the trick! Thank you so much for your insight.
Steve
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!
