Tech Blog

So VPN’s in my world normally surround work related matters such as a site-to-site VPN to connect two sites or buildings together.  That was however until NordVPN very kindly sent me a free trial of the software…..and I must admit I’m impressed.

So to begin with you get a huge array of download options including some Raspberry Pi and DD-WRT:

The install itself is a breeze, firstly it installs virtual NIC (which is normal practice, Dell and Cisco etc all do the same with their VPN clients):

Next…well its done:

Before I login, click the settings button and here’s the bit I like:

DNS Servers – This fixes a common problem “DNS Leak”, yes having a VPN is great unless your DNS isn’t working properly and your “leaking” meaning potentially your DNS is being hijacked (spoofed or injected with false IPs) or being snooped upon.  This settings sorts this issue and so long as you trust NordVPN who have promised me they don’t keep any logs!

Below this is Process Kill List, which means if the VPN drops for any reason then the list processes you’ve added will be stopped.

Once you login you’ll be presented with a huge array of countries to connect to and two options, either TCP or UDP:

TCP is a reliable protocol like a phone call its two way,

UDP protocol is like a post card, you know if it gets to its destination or not but is faster than TCP.

So that’s pretty much it, you can test your VPN is working by opening:

https://www.dnsleaktest.com/ – if its not then close and reopen your browser.

You now have a “safe” connect to the interweb and all its content!!

Boom

Hi all,

As well as our main site we have a remote site, lets call it Remote1. Remote1 is on a basic ADSL line, the site connects to the main site via a site to site VPN between two SonicWall’s.  Remote1 has two Meru Access Points (AP332e) which are configured to communicate with the Meru controller at the main site which is where our issue was.

Here’s a pretty picture to help see what I’m on about:

With the help of Meru support who were brilliant I carried out the follow analysis:

So normally Meru AP’s talk to the controller via UDP broadcast packets i.e. UDP port 9292, 9393.  If that doesnt work it uses layer 3 IP routing.

From the remote site I can ping (IP address, server name and broadcast address), telnet and http access the Meru Controller via the VPN. Great Layer 3 is good to go.

From the Controller I can ping the Access Points. Again great.

We have two AP’s on the remote site, to test one is set to L3 and one to L2 but neither work…hmmmm

From connecting to the AP’s via a cable we can see the packets are broadcasting and the AP’s have a valid IP address,

A packet trace on the firewalls show the UDP broadcast packets arrive and leave the remote firewall, are ingested and forwarded at the main site,

A port mirror on the controller shows no traffic from the remote site subnet.

A port mirror of the Main Sites firewall show the packets entering the network but when you connect to the next switch and port mirror I cant see any traffic (see wireshark results below):

So what the hell is going on???  Well it turned out I hadnt drawn the network diagram properly (above), here’s the proper topography:

Between the firewall and the first switch we have a Lightspeed Rocket that does a great job of email protection and website filtering.  Well after looking on the main web filtering page I noticed a tick box under “Block all unidentified UDP connections, Skype, UltraSurf type traffic, and file-sharing networks such as BitTorrent.”….well bugger!!

So I un-ticked this section and Boom the AP’s came one line!!

Now this isnt great as users could start using P2P so I re-ticked the box and added a exception for AP’s and we have a winner!!!

Big thanks to Meru Support, Lightspeed Support, SonicWall Support, HP Support and Commercial LTD (who in the end helped find my missing piece in the diagram).