Powered By Blogger

Wednesday 24 August 2011

My first 802.1Q VLAN

The other day I had to create my first 802.1Q VLAN. Why? To stop 2 customers potentially seeing each other's networks!! At our radio mast site we have a Draytek Vigor 3300 router which our customers connect to via IPSEC VPNs. We have a VPN tunnel that we use ourselves to link our Nottingham radio trunk with our Mansfield radio triunk and we share the local IP subnet (192.168.1.x) with one customer which is fine.

However we don't want our next customer to also be on that subnet. This is where the VLAN comes into play! On the Draytek 3300, go to Advanced and then LAN VLAN setting. Select 802.1Q VLAN as in the picture below:

Make sure that all ports are ticked as active (you could lock yourself out otherwise!!!) and make sure all frames are 'untagged'.  Equally important is to make sure 'enable management port for P4' is still ticked our again you could lock yourself out (not good if you already have customer's VPNs setup on there!!!).

You will then have to reboot the router as you've re-configured the LAN subnet for the router.
When the router has rebooted, click on Network and then LAN and you will now be presented with the following window:


You can now assign each of the 4 LAN ports their own unique subnet; therefore keeping them seperate from the other ports!



You may need to adjust any existing VPN settings to include the new subnet created on the other LAN ports.



I've whipped up a couple of Visio diagrams as a before and after which I hope better illustrates what I wanted to and have achieved.

Before:

After:

If at all possible it's worth forward planning with the subnets of the other LAN ports. As I said earlier, making a change to the local LAN address requires a reboot of the router (the more customers you have on the less desirable this is!!!).

Monday 8 August 2011

Remote Work Webplace times out for SBS2011 with a Draytek Vigor2930

Recently I migrated our companies old & tired SBS2003 server over to a nice new SBS2011 server. All went well inlcuding migrating the old sharepoint database (had to use an interim Win 2003 server running Sharepoint 3 in a VM as a staging server) as well as Exchange and all the files. One big change we had to make was how we connect to the internet. The old server had two network cards in (1 for the LAN and the other for the WAN with a public IP that connected directly to a cable modem). We also used a POP connector to collect emails.

As SBS2011 only supports one network card I decided to install a Draytek Vigor 2930 router that connects to the cable modem for internet access. Whislt I was at it I changed our emails over from using a POP connector to using direct SMTP. All very straight forward stuff (or so I thought!!). On the router I forwarded the following ports to our new server:
25 - for emails
80 - for remote web access
443 - for remote web access
987 - for remote web access
3389 - for remote web access and access to the server

I then proceeded to test Remote Web Access from a computer outside our network and it timed out! Internally it worked fine but externally it didn't. My first thought was that it was the router so I double checked all the port settings and ran a GRC test as well as telnetting to each port from an external PC but it seemed fine. I also enabled UPNP on the router and ran the SBS connect wizard which detected UPNP was on and was happy with it but still nothing. To cut an already long story short I logged the case with Microsoft and gave their technician remote access to the server. He couldn't see that I did anything wrong so asked me to download a packet tracing program and to install it on both the server and the external PC. I did this and sent the traces to him. It looked as though the HTTPS requests weren't reaching the server.

This confirmed what I initially suspected about the router being at fault. To further prove this I gave the server the router's public IP address and plugged it straight into the cable modem. I ran my test from the external PC and Remote Web Workplace all worked fine!!

So back to the router. After digging around I found that someone else had had similar issues. Now at this point I hadn't enabled remote access to the router itself (this defaults to 443 for HTTPS but can be changed) but even though it wasn't configured it was interfering with HTTPS traffic and not forwarding the requests as it should do.

So to get around this I changed the HTTPS port number anyway to 4443:

I also read somewhere that SSL VPN defaults to 443. Again I wasn't using this but changed this anyway. On the router this can be found under: SSL VPN - General Setup & I changed the port to 8443:



I then rebooted the router and it works fine!! As a courtesy I sent my findings and solution to the Microsoft technician that was very helpful for which he was very grateful. So for what turned out to be a few hours of getting to the bottom of this problem; it could have been solved within 5 minutes by changing 2 simple settings!! Isn't that always the case though?