Select the two Alerts highlighted below to receive the minimal amount of email’s when your primary/secondary WAN enters or exits failover status.
SonicWall WAN Failover Alerts
Category: SonicWall
SonicWall Packet Monitor
I’ve never really understood Packet Monitor. So a kind SonicWall tech was able to explain it to me. Hold onto your packets!
- Packet capture is found under Investigate > Tools > Packet Monitor.
- Make sure it is Stopped and Cleared.
- Click Configure.
- Monitor Filter:
- Ether Type: ip
- IP Type: tcp (usually)
- Source IP Address: <source IP>
- Source Port: <optional>
- Destination IP Address: <also optional, but helps>
- Destination Port: <optional>
- Advanced Monitor Filter:
- Check ALL the boxes
- Click OK.
- Ready your test and click Start Capture.
- It is important to Stop Capture once you’ve concluded the test otherwise you will have an overflow of packets and fill up the buffer quickly. You can also click Clear to empty the buffer and start again.
Definition of Statuses
| Consumed | Packet stops at the firewall. Could be due to the packet being destined for the firewall such as a ping to the SonicWall’s IP address. |
| Generated | The opposite of Consumed. It means the SonicWall generated the packet. This is rare in troubleshooting. |
| Dropped | Packet is blocked at the firewall. This is usually due to a faulty or missing rule. Check the Packet Detail for more information. This is what you need to be looking for if you suspect the firewall is at fult. |
| Forwarded | This means traffic is passing normally and all is fine. The SonicWall forwarded the packet to its intended destination. |
| Received | The packet came to the firewall, but the SonicWall does not have a destination of where to send it. Usually caused by a faulty ARP table entry or the server is offline. Eventually the packet will become discarded. |
AH < ESP
Mom & Pop ISP blocking ESP traffic? Seems unlikely. But that’s what SonicWall claims. Remind me in a few days to switch the tunnel back to ESP. I don’t like my trousers down between Graytown and San Antonio.
SonicWALL SSL-VPN and Tunnel All Mode
I must remember this one. Scenario: you have setup SonicWALL’s SSL-VPN to accept external NetExtender client connections. You have configured the clients in “Tunnel All Mode” which means the external device will browse the Internet from the IP of the SonicWALL (useful for when you’re at a public hotspot or other connection-inhibiting location). Everything connects properly and yet you cannot browse the Internet. The fix is simple.
Go to Local Groups, edit the SSLVPN Services group. Go to the VPN Access tab. Add the entry WAN RemoteAccess Networks.
You’re welcome.
Don’t Forget the RTP Stream!
It’s been a rough day for SIP. Out of nowhere my Asterisk server stopped working properly. I suspected the SonicWALL and began a 2 hour long process of generating the configuration from factory defaults. I did this because a SonicWALL technician in his Indian accent chastised me for loading Beta firmware without having good backups. He blamed this for having a malfunctioning CFS policy. Anyway, I loaded new configuration and as it was it had no effect on the symptoms. Specifically, there was 1-way or no audio and the call disconnected right at about 30 seconds.
Every Asterisk forum and support post always describes the cause of this issue to be bad NAT-ing. However nothing had changed. I loaded the same configuration into the SonicWALL as was before the wipe.
Ultimately after much searching I came across a working solution. I added RTP ports UDP 10000-20000 to the firewall. Also I opened up the firewall to All incoming connections instead of my SIP trunk providers IP address. Possibly they changed the IP address for the media gateway but only a call to tech support would determine that. Fortunately I’ll do that tomorrow.
Side note that I also went through a couple hours worth of free SMTP quota in about 3 seconds. I turned on email alerts on the default SonicWALL configuration. I also had Geo-IP filter engaged for a measly few 12 of the baddest countries in the malware world. Let’s just say it’s a dangerous Internet out there. My SonicWALL sent an email every time someone tried to connect and was blocked yet the Geo-IP filter.
SonicWALL Content Filter Service, with LDAP and SSO
Last night I decided to tackle the task of enabling the SonicWALL CFS service on my new TZ 500 NFR model. I had done this with my NSA 240 years ago (circa 2009) and was very impressed with the end results. Now with another 365 days of free CFS service, better use it, right?
Not using any KB articles, I was able to complete the whole thing without much difficulty. The TZ 500 paired with LDAP (unsecured) using a non-admin service account and I installed the SonicWALL SSO Agent program on the DC and configured to run as a service. I tested the functionality pretty thoroughly and wherever I logged in as my account, the SonicWALL figured it out and adjusted the CFS automatically and perfectly.
The only issue is that I could not figure out how to manually log in as a user to authenticate via AD (and get special CFS policy) on non-Windows (or domain joined) devices such as guest systems and handheld devices. Hopefully I will post about that soon.