akjindalccc
IS-IT--Management
My customer wanted to add a SonicWall TZ 100 firewall/router to his existing network setup. He has several Aloha POS terminals and a server, a few office computers, VoIP phone, private WiFi, and WebCams. I'd never worked with Aloha before nor a SonicWall product.
The existing system was all on one network - 192.168.1.x routed through a LinkSys WRT54G connected to the Internet via DSL modem with some port forwarding to access the webcams from outside the restaurant.
The new system I designed had 3 subnets - all administered by the SonicWall. One subnet (192.168.1.x) for the POS system. One subnet (192.168.49.x) for the office computers/VoIP/WiFi. One subnet (192.168.77.x) for the webcams. The goal was to keep the POS computers firewalled from everything else and while I was at it, I created a separate DMZ zone subnet for the webcams that would be accessible from the Internet to keep them firewalled from the office computers. It all worked fine in my office test setup but I wasn't able to test Aloha in the mix - I was just able to confirm network traffic was flowing where it should and blocked where it should.
When we switched over to the SonicWall at the restaurant, credit card charges stopped working with a "network error". This was a mystery since the POS terminals could access web sites and ping each other. No IP addresses had changed since my goal was change as little as possible on the POS computers (they all had static IP addresses). We called a support number that the owner had and their only advice was to ensure that the SonicWall wasn't blocking port 443 for SSL transactions. The SonicWall was not blocking any ports as near as I could tell. In fact, we could browse to the HTTPS web sites just fine (they use port 443).
I took out the SonicWall and put the LinkSys back and and everything was working again. Clearly the SonicWall was causing the problem. Lunch was starting and he had a business to run so I left the LinkSys in place and went back to the office to see what I could figure out.
I did some web searching - which is how I found this forum - and saw that others had similar problems but I didn't see any answer beyond what we already had (make sure port 443 is open, make sure your internet connection is reliable). Since the problem was in the SonicWall, I poked around the configuration settings to see if there was anything else that could be blocking the credit card transactions.
Here is what I theorized (after much reading of SonicWall docs) - SonicWall TZ 100 has a feature called "Deep Packet Inspection Content Filtering" that examines traffic for content that might contain viruses, email spam or other undesirable content. I suspected that when Aloha connected to the payment processor the communication was encrypted using certificates on *both ends* to confirm the identity of the merchant as well as the payment processor (makes sense). In this situation SonicWall can't inspect the packets because they are encrypted and thus just throws them away leading to a network error. Simple HTTPS to the bank's web site works because only the web server uses a certificate to confirm its identity and the SonicWall has a way to insert itself into the encryption chain to inspect that traffic (technical details on how that works can be found at SonicWall).
The next morning, I put the SonicWall back in, disabled all the content filtering options and it worked!! On the TZ 100 it is under Network --> Zones. Edit the Zone and clear the checkboxes for Content Filtering Service, Client Anti-Virus Service, Gateway Anti-Virus Service, IPS, Anti-Spyware Service.
By the way, all these services require a paid subscription in order to be useful (sort of like virus definitions) and since my customer didn't subscribe (and wasn't intending to) disabling them isn't a big deal. I'm sure there is way to configure SonicWall to do content filtering in this scenario if desired but right now I just wanted to get my customer up and running.
Hope this helps!
The existing system was all on one network - 192.168.1.x routed through a LinkSys WRT54G connected to the Internet via DSL modem with some port forwarding to access the webcams from outside the restaurant.
The new system I designed had 3 subnets - all administered by the SonicWall. One subnet (192.168.1.x) for the POS system. One subnet (192.168.49.x) for the office computers/VoIP/WiFi. One subnet (192.168.77.x) for the webcams. The goal was to keep the POS computers firewalled from everything else and while I was at it, I created a separate DMZ zone subnet for the webcams that would be accessible from the Internet to keep them firewalled from the office computers. It all worked fine in my office test setup but I wasn't able to test Aloha in the mix - I was just able to confirm network traffic was flowing where it should and blocked where it should.
When we switched over to the SonicWall at the restaurant, credit card charges stopped working with a "network error". This was a mystery since the POS terminals could access web sites and ping each other. No IP addresses had changed since my goal was change as little as possible on the POS computers (they all had static IP addresses). We called a support number that the owner had and their only advice was to ensure that the SonicWall wasn't blocking port 443 for SSL transactions. The SonicWall was not blocking any ports as near as I could tell. In fact, we could browse to the HTTPS web sites just fine (they use port 443).
I took out the SonicWall and put the LinkSys back and and everything was working again. Clearly the SonicWall was causing the problem. Lunch was starting and he had a business to run so I left the LinkSys in place and went back to the office to see what I could figure out.
I did some web searching - which is how I found this forum - and saw that others had similar problems but I didn't see any answer beyond what we already had (make sure port 443 is open, make sure your internet connection is reliable). Since the problem was in the SonicWall, I poked around the configuration settings to see if there was anything else that could be blocking the credit card transactions.
Here is what I theorized (after much reading of SonicWall docs) - SonicWall TZ 100 has a feature called "Deep Packet Inspection Content Filtering" that examines traffic for content that might contain viruses, email spam or other undesirable content. I suspected that when Aloha connected to the payment processor the communication was encrypted using certificates on *both ends* to confirm the identity of the merchant as well as the payment processor (makes sense). In this situation SonicWall can't inspect the packets because they are encrypted and thus just throws them away leading to a network error. Simple HTTPS to the bank's web site works because only the web server uses a certificate to confirm its identity and the SonicWall has a way to insert itself into the encryption chain to inspect that traffic (technical details on how that works can be found at SonicWall).
The next morning, I put the SonicWall back in, disabled all the content filtering options and it worked!! On the TZ 100 it is under Network --> Zones. Edit the Zone and clear the checkboxes for Content Filtering Service, Client Anti-Virus Service, Gateway Anti-Virus Service, IPS, Anti-Spyware Service.
By the way, all these services require a paid subscription in order to be useful (sort of like virus definitions) and since my customer didn't subscribe (and wasn't intending to) disabling them isn't a big deal. I'm sure there is way to configure SonicWall to do content filtering in this scenario if desired but right now I just wanted to get my customer up and running.
Hope this helps!