NSa 4700 and Outbound Rules
Hello Everyone,
I have a number of could based Extreme AP's. When performing a firmware update, this fails with Device Update Failed. I have spoken with Extreme who have said it looks like a Firewall issue. I tend to agree as I took one of the AP's home and this updated with no issue.
I have created Address Objects/Address Group and created a LAN to WAN policy for this with no luck. There must be something obvious I am missing bit can't place this at the moment.
Any help appreciated.
Screenshots below.
Extreme AP failure message:
SW Policy:
SW Destination:
Does have a range of IP's. I have used FQDN and Network with no luck.
SW Destination Service:
Thanks Everyone.
Best Answer
-
BWC Cybersecurity Overlord ✭✭✭
@Asif_Iqbal about the TCP Flag drop, did you checked this article?
--Michael@BWC
0
Answers
@Asif_Iqbal like I suggest in many other cases, crank up a Packet-Monitor and filter for the IPs of your APs, this will show you if the Firewall is dropping the traffic.
It might be related to DNS, Enforced SSO or anything else, but first things first.
--Michael@BWC
@BWC Apologies I should have mentioned I have done a packet trace and I can see the below.
I've just run another packet trace showing dropped packets only and have the below.
Now that looks to me like I should have port 41473 whitelisted. However, this is not mentioned anywhere on the list of ports issued by Extreme.
Thanks,
Not quite.....that packet capture almost certainly shows that 41473 is a source port, ie it is randomly generated by the client. Source ports are irrelevant to access rules 99.9% of the time. So the packet is probably dropped because the destination IP does not match. I see an RST in there, the Sonicwall removes the connection from the table when it sees an RST and then the subsequent replies from the client are then dropped.
@Asif_Iqbal 41473 is the dynamic source port, safe to ignore.
What does the packet detail show for the droped traffic? I assume no event log entries from a security service subsystem? SSO is not enforced for LAN?
--Michael@BWC
@BWC should have expanded the dropped packets as below.
@Asif_Iqbal the Packet Cache reasons can be safely ignored the invalid TCP flags are strange. Do you have DPI-SSL activated?
Again, no SSO enforced?
--Michael@BWC
@BWC - thanks for your replies and SSO is not enforced if you mean Single Sign On for the LAN concerned.
DPI-SSL I believe is not activated for the Client or Server please see below.
Thanks,
@BWC - Ah, I have just gone through this and toggle ON the Allow TCP Urgent Packet's and this looks to have worked as I now have no packet drops and the AP's are updating first time, Great news! Is there any downside to this and Is there anything else you can with the rule I have created for the Extreme AP's.
Much Appreciated.
@Asif_Iqbal if any of the participating devices is setting this TCP flag you might be forced to enable it via Access Rule.
I cannot see any negative impact, especially that you limited it with a tight Access Rule restricting it to your APs and the Extreme Cloud Services.
I can't recall ever had to set this flag in a rule, but it's good to know that it is there :)
--Michael@BWC
@BWC - That's great and like you I have never had to use this feature on any rule before. This has worked fine on the 2 AP's I have now updated and I am not seeing any packet drops. I will let Extreme know about this too as it may influence what packet priorities they send out.
Many thanks as always Michael :).
Kind Regards,