You want to use your Server 2008 as a VPN for accessing remote applications and data at your workplace instead of your VPN firewall or a router that has that option? Understandable. Exciting that you found this post huh? No? Only useful? Well, okay.
First, install the server role.
The server role isn't called 'vpn' or anything like that. Go to Start > Server Manager > Add Roles > Select Network Policy and Access Services > Next > Next.
Select Remote Access Service > Next > Install > The Service takes a long time so make a sandwich or a salad if you're a vegetarian. When it finishes, click close.
Now go to Start > Administrative tools > Routing and Remote Access > The Server will have a red "south" Arrow on it > Right Click the Server and Select "configure and enable routing and remote access"
Next > Select "Custom Configuration" > Next.
VPN Access > Next
When prompted select "Start Service" > service will start > you can now close the Routing and Remote Access Console.
Make sure the user has 'dial-in access' in Active Directory Users and Computers. For example find Joe Smith in Active Directory. Go to his properties. In the dial-in tab, click "allow access."
Now we must go to the Sonicwall device.
Since the Server 2008 box is behind our firewall we must open the correct port and protocol to Server 2008. TCP Port 1723 and GRE (Generic Routing Encapsulation) to be exact.
You will need two rules in your Sonicwall. The first one is NAT.
Source original - any
Source translated - original
Dest original - your public IP
Dest Translated - your vpn server internal IP
Service original - pptp
service tranlated - original
The second rule is a firewall rule.
Wan to Lan
Source - any
Destination - my external IP
Service - pptp
Action - allow
These two rules cover the TCP port 1723 and the GRE protocol requirements.
Now you need to connect your remote client to the VPN server (your server 2008 box).
The following is for Windows Vista and Windows 7 machines.
Click on Start > Control Panel > Network and sharing Center > Connect to a Network > Set up a Connection or Network > Connect To a Workplace > Next.
Use My Internet Connection (VPN) > Enter the public IP address of the VPN server > Enter a Name for the Connection > Next > Enter your Domain Logon details > Connect.
I hope this helps. I couldn't find a single post covering all of this. There might be one out there. I couldn't find one so that's why I wrote this post. Enjoy!
Showing posts with label sonicwall. Show all posts
Showing posts with label sonicwall. Show all posts
Wednesday, January 23, 2013
Application Authentication Through VPN Tunnel Problem
This is a good "from the trenches" story, especially if you like networking. I've been working on this problem for exactly a week (no, not a crazy long time, but still, it's a while) and today I finally fixed the issue.
At work our main application for hr, payroll, general ledger, and employee self-service is called Springbrook. It's a nice, though slightly bloated, application that works for us. It's important to know how Springbrook is used for this story to make sense. Please bear with me while I give you the rundown.
The Springbrook application is installed on server1 along with the programs OpenEdge and Progress to handle all of the data processing for Springbrook. We have a separate drive just for Springbrook, OpenEdge and Progress. When the app is executed, the login page is opened in Internet Explorer. Springbrook uses the LDAP protocol (in our case Active Directory) to authenticate the user trying to login against the login id’s already inside of Springbrook, so when the session is established it requires that the user logs in and is authenticated to the domain which in turn makes the connection to the LDAP connector which verifies user info and allows them access.
How do the users run Springbrook? I have setup a mapped drive to the server on their workstations. I setup a desktop shortcut to the executable so the employees don't have to go that mapped drive each time and double-click the executable. So, it looks and feels like Springbrook is installed locally on their workstations.
This setup works great for local users right? What about remote users? We have those. One currently, but we're about to have one more permanent remote user. I decided to go with the VPN option in our Sonicwall TZ 210. It worked great. It was fast, surprisingly, and the user didn't have to go through remote desktop to use Springbrook which was nice. I mapped a drive to the server so she was able to use it just like the local users do. Fantastic.
Well, eight days ago Springbrook ran a service pack for the application. No problem because they do that on occasion to correct problems in the modules. The next day my remote user couldn't use Springbrook. I asked her if the VPN connected fine and she said "yeah, I can connect to the network, but I can't login to Springbrook." I told her to wait and I would be there in about fifteen minutes. I went through the checklist and found that nothing should be preventing her from logging in to Springbrook. I was so confused. The only change was the service pack install. I contacted Springbrook about this and the tech told me that somehow the authentication isn't happening in the VPN tunnel.
Okay. I knew that, haha
He then said that they use Citrix for their remote employees. I'm sure Citrix has a very nice WebApp tool, but if I can do this through a VPN tunnel and save us money that would be great. I don't like to go with paid solutions if we can implement a solution with equipment and software we already have. So, since I couldn't figure the problem out I decided to hit the forums. A person at serverfault recommended the VPN option in Windows Server 2008. I thought, "Why not?" I set that up in my lab. The VPN connection was fast, smooth, and near painless. *I'm going to write a blog post about it because it's so simple and there wasn't a single post containing all of the steps, instead I had to piece it together from multiple posts - ugh* Anyway, I connected to the VPN server, accessed the Springbrook share, ran Springbrook and guess what? I couldn't login to Springbrook. THE EXACT SAME PROBLEM. I understood possibly having an authentication issue using Sonicwall's VPN but there is no way that my server couldn't authenticate me because I connected to that server with my Active Directory credentials.
I was livid. Suddenly, I thought, "Why don't I try adding the .local to the domain name in the domain field?" The Springbrook login window requires a username, password, and a domain. All users and I mean all of our users don't have to put the .local for the domain however when you're up against a wall you try anything. I added .local to the domain name and then Springbrook launched. That fixed the issue. I couldn't believe it. I then wondered if that was the problem going through Sonicwall? I called the remote user, asked her when I could work on this for her, she said now and so I went to her office. I enabled the Sonicwall VPN connection, ran the Springbrook application, added the .local to the domain name and like a charm I was running Springbrook. The user was happy and yeah I was happy, but I want to know why I have to add .local to the domain name when logging in remotely now. Remote users didn't have to do that before last week. Why now?
I'm not satisfied. Could it be the recent Springbrook service pack update? I contacted Springbrook support and hopefully I'll hear back from them soon.
Anyway, lesson is try the easy things first. Like usual.
At work our main application for hr, payroll, general ledger, and employee self-service is called Springbrook. It's a nice, though slightly bloated, application that works for us. It's important to know how Springbrook is used for this story to make sense. Please bear with me while I give you the rundown.
The Springbrook application is installed on server1 along with the programs OpenEdge and Progress to handle all of the data processing for Springbrook. We have a separate drive just for Springbrook, OpenEdge and Progress. When the app is executed, the login page is opened in Internet Explorer. Springbrook uses the LDAP protocol (in our case Active Directory) to authenticate the user trying to login against the login id’s already inside of Springbrook, so when the session is established it requires that the user logs in and is authenticated to the domain which in turn makes the connection to the LDAP connector which verifies user info and allows them access.
How do the users run Springbrook? I have setup a mapped drive to the server on their workstations. I setup a desktop shortcut to the executable so the employees don't have to go that mapped drive each time and double-click the executable. So, it looks and feels like Springbrook is installed locally on their workstations.
This setup works great for local users right? What about remote users? We have those. One currently, but we're about to have one more permanent remote user. I decided to go with the VPN option in our Sonicwall TZ 210. It worked great. It was fast, surprisingly, and the user didn't have to go through remote desktop to use Springbrook which was nice. I mapped a drive to the server so she was able to use it just like the local users do. Fantastic.
Well, eight days ago Springbrook ran a service pack for the application. No problem because they do that on occasion to correct problems in the modules. The next day my remote user couldn't use Springbrook. I asked her if the VPN connected fine and she said "yeah, I can connect to the network, but I can't login to Springbrook." I told her to wait and I would be there in about fifteen minutes. I went through the checklist and found that nothing should be preventing her from logging in to Springbrook. I was so confused. The only change was the service pack install. I contacted Springbrook about this and the tech told me that somehow the authentication isn't happening in the VPN tunnel.
Okay. I knew that, haha
He then said that they use Citrix for their remote employees. I'm sure Citrix has a very nice WebApp tool, but if I can do this through a VPN tunnel and save us money that would be great. I don't like to go with paid solutions if we can implement a solution with equipment and software we already have. So, since I couldn't figure the problem out I decided to hit the forums. A person at serverfault recommended the VPN option in Windows Server 2008. I thought, "Why not?" I set that up in my lab. The VPN connection was fast, smooth, and near painless. *I'm going to write a blog post about it because it's so simple and there wasn't a single post containing all of the steps, instead I had to piece it together from multiple posts - ugh* Anyway, I connected to the VPN server, accessed the Springbrook share, ran Springbrook and guess what? I couldn't login to Springbrook. THE EXACT SAME PROBLEM. I understood possibly having an authentication issue using Sonicwall's VPN but there is no way that my server couldn't authenticate me because I connected to that server with my Active Directory credentials.
I was livid. Suddenly, I thought, "Why don't I try adding the .local to the domain name in the domain field?" The Springbrook login window requires a username, password, and a domain. All users and I mean all of our users don't have to put the .local for the domain however when you're up against a wall you try anything. I added .local to the domain name and then Springbrook launched. That fixed the issue. I couldn't believe it. I then wondered if that was the problem going through Sonicwall? I called the remote user, asked her when I could work on this for her, she said now and so I went to her office. I enabled the Sonicwall VPN connection, ran the Springbrook application, added the .local to the domain name and like a charm I was running Springbrook. The user was happy and yeah I was happy, but I want to know why I have to add .local to the domain name when logging in remotely now. Remote users didn't have to do that before last week. Why now?
I'm not satisfied. Could it be the recent Springbrook service pack update? I contacted Springbrook support and hopefully I'll hear back from them soon.
Anyway, lesson is try the easy things first. Like usual.
Wednesday, October 10, 2012
Change the Interface DHCP Lease Is Bound To in Sonicwall
* Note: this blog post is about Sonicwall firmware version
"SonicOS Enhanced 5.8.1.5-46o"
So you've went through the VPN wizard. It's running. You have people using it. It's great. Oh wait! What's that? In your security log you see "attacks" labeled as "IP Spoof." Looking at the log, it shows the user logging in on interface X0, but their IP on your network is a X2 address. Sonicwall thinks it is an IP spoof. You see the external IP. You recognize the external IP is from one of your remote sites. It's no threat, but you would like for Sonicwall to not log it anymore. How do you fix it? I'm glad you asked.
Example setup.
X0\ LAN\ Static\ 192.168.10.XXXX\ you use this for DHCP for your wifi users
X1\WAN
X2\ LAN\ Static\ 192.168.1.XXXX\ this is your production network that doesn't utilize DHCP every user on this network has a static IP
In your VPN setup, Sonicwall binds the DHCP lease to the interface that uses DHCP (genius idea right?). So you've built this VPN connection. On the client's machine, you install the Sonicwall VPN client software to connect to the network. You want her to be on the production network though, so you change the virtual adapter the Sonicwall client uses on her machine to a 192.168.1. address. Now, she is able to access production network resources like she wanted. Great.
Back home, you see in the security logs, the IP Spoof stuff. How is that fixed? In the Sonicwall admin panel, go to VPN\DHCP over VPN. Click the dropdown box, select Remote Gateway then click configure.
You should see the following, "DHCP Lease Bound To:" and a dropdown box next to that with the various interfaces. Following our example above, choose the X2 interface so the client will be on the production network when logged in using the VPN.
Then click OK. You might see a goofy red message, but it won't keep you from making the change to the DHCP lease binding.
So you've went through the VPN wizard. It's running. You have people using it. It's great. Oh wait! What's that? In your security log you see "attacks" labeled as "IP Spoof." Looking at the log, it shows the user logging in on interface X0, but their IP on your network is a X2 address. Sonicwall thinks it is an IP spoof. You see the external IP. You recognize the external IP is from one of your remote sites. It's no threat, but you would like for Sonicwall to not log it anymore. How do you fix it? I'm glad you asked.
Example setup.
X0\ LAN\ Static\ 192.168.10.XXXX\ you use this for DHCP for your wifi users
X1\WAN
X2\ LAN\ Static\ 192.168.1.XXXX\ this is your production network that doesn't utilize DHCP every user on this network has a static IP
In your VPN setup, Sonicwall binds the DHCP lease to the interface that uses DHCP (genius idea right?). So you've built this VPN connection. On the client's machine, you install the Sonicwall VPN client software to connect to the network. You want her to be on the production network though, so you change the virtual adapter the Sonicwall client uses on her machine to a 192.168.1. address. Now, she is able to access production network resources like she wanted. Great.
Back home, you see in the security logs, the IP Spoof stuff. How is that fixed? In the Sonicwall admin panel, go to VPN\DHCP over VPN. Click the dropdown box, select Remote Gateway then click configure.
You should see the following, "DHCP Lease Bound To:" and a dropdown box next to that with the various interfaces. Following our example above, choose the X2 interface so the client will be on the production network when logged in using the VPN.
Thursday, August 30, 2012
Create an Alternate HTTPS port in Sonicwall
For my new project with Remote Desktop Services, specifically Remote Apps offered externally to our network, I had to create an alternate HTTPS port in my Sonicwall TZ210 because we couldn't afford a new external IP (politics). Anyway, here's what you do.
Login to your Sonicwall appliance. In the left column, under network, click on Services. You're now in the Services section. Under Services, click on "add." The Add window opens allowing you to create your service. You should have fields for name, protocol, port range, and sub-type. After you've named your Service, select TCP for IP type and now put in the port range you want. For this setup, you probably only want one port number, so the range fields need the same number, e.g. beginning 1500 and ending with 1500. Click Add and you're done.
Just above Services is Service Groups. Click on Add Group. The Add Group window will open and you can customize your Service Group (I labeled mine <server name> RD Web). After you've named it, find the Service you created and add the Service to your Service Group. Click OK and you're done. You've created the alternate port for 443!
This is how you should feel after this accomplishment. Celebrate by yelling and beating your chest.
Login to your Sonicwall appliance. In the left column, under network, click on Services. You're now in the Services section. Under Services, click on "add." The Add window opens allowing you to create your service. You should have fields for name, protocol, port range, and sub-type. After you've named your Service, select TCP for IP type and now put in the port range you want. For this setup, you probably only want one port number, so the range fields need the same number, e.g. beginning 1500 and ending with 1500. Click Add and you're done.
Just above Services is Service Groups. Click on Add Group. The Add Group window will open and you can customize your Service Group (I labeled mine <server name> RD Web). After you've named it, find the Service you created and add the Service to your Service Group. Click OK and you're done. You've created the alternate port for 443!
This is how you should feel after this accomplishment. Celebrate by yelling and beating your chest.
Tuesday, August 21, 2012
Issues with camera system
At work we have a 12 camera Geovision surveillance system that runs a TCP/IP service allowing LAN users to access the system and a Web service allowing authorized WAN users/devices to access the system from outside our network. This has been in place for at least 2 years now. Well, the other day I decided to access the system from home to see if our PTZ camera was working (I had heard a complaint). I couldn't connect. More specifically, using the external IP and the port number only resulted with Google telling me it couldn't find anything related to such madness. Curious, I contacted my boss and asked him the last time he accessed the system from his iPad (geovision app). He told me it had been a long time and to not worry about fixing the problem until the next day at work. Cool.
When I arrived at work I checked the following, but I didn't follow my policy of starting with external then going internal; if I had, then I would have fixed the issue sooner. What I did was start the complete opposite. Doh!
What I did
Began with the camera server. I checked the local firewall settings. Windows Firewall was on and allowing exceptions. I had all of the correct exceptions checked too. I then moved to turning off the local firewall on the camera server and accessing externally, but that didn't work. The Web Cam service was running also on the camera server. So, no problem with that device.
I then move to what I should have checked to begin with: Sonicwall. I checked the access rules, but I didn't see anything out of the ordinary. Everything we use was right there in the list. I then go to the NAT policies. Ah-ha! I see an odd NAT service called "our server name"-services with http and https. What? My comment on the NAT rule sucked too: sick/vacation. That didn't make sense to me because I had the correct mail server stuff running and I couldn't imagine why this NAT rule could be used for mail server stuff. My geovision services use http (8080) for the web access and this random NAT service also using 8080 was conflicting with the geovision service, which is why we couldn't access the camera system externally. I turned off the random NAT rule, tried the web cam externally and like a charm I was able to access the camera system. It wasn't cheer time just yet though because I had to make sure our mail service with our employee self-service system was still running with that random NAT service turned off. I tried it out and yes, it still worked.
What did I learn from this experience? I learned a few things (things I already know, but haven't put into habitual practice yet - FAIL).
1. Work from external to internal. Working this way keeps things simple because it's easy to get the external stuff out of the way first since there aren't as many things external as there are internal.
2. Document clearly. Even non-firewall things need to be documented clearly. When you're doing something at your work leave notes on why you're doing this or doing that. I have no idea why I made that NAT rule and the comment didn't help me at all. I was testing something, but failed to turn it back off. If I had documented clearly then I would have known the purpose of that NAT rule.
3. When you turn a service off or on or replace/whatever make sure your production services are running just as they should be. You know you've done something right when the only thing the employees notice is the new thing they were expecting or nothing at all after your network project.
When I arrived at work I checked the following, but I didn't follow my policy of starting with external then going internal; if I had, then I would have fixed the issue sooner. What I did was start the complete opposite. Doh!
What I did
Began with the camera server. I checked the local firewall settings. Windows Firewall was on and allowing exceptions. I had all of the correct exceptions checked too. I then moved to turning off the local firewall on the camera server and accessing externally, but that didn't work. The Web Cam service was running also on the camera server. So, no problem with that device.
I then move to what I should have checked to begin with: Sonicwall. I checked the access rules, but I didn't see anything out of the ordinary. Everything we use was right there in the list. I then go to the NAT policies. Ah-ha! I see an odd NAT service called "our server name"-services with http and https. What? My comment on the NAT rule sucked too: sick/vacation. That didn't make sense to me because I had the correct mail server stuff running and I couldn't imagine why this NAT rule could be used for mail server stuff. My geovision services use http (8080) for the web access and this random NAT service also using 8080 was conflicting with the geovision service, which is why we couldn't access the camera system externally. I turned off the random NAT rule, tried the web cam externally and like a charm I was able to access the camera system. It wasn't cheer time just yet though because I had to make sure our mail service with our employee self-service system was still running with that random NAT service turned off. I tried it out and yes, it still worked.
What did I learn from this experience? I learned a few things (things I already know, but haven't put into habitual practice yet - FAIL).
1. Work from external to internal. Working this way keeps things simple because it's easy to get the external stuff out of the way first since there aren't as many things external as there are internal.
2. Document clearly. Even non-firewall things need to be documented clearly. When you're doing something at your work leave notes on why you're doing this or doing that. I have no idea why I made that NAT rule and the comment didn't help me at all. I was testing something, but failed to turn it back off. If I had documented clearly then I would have known the purpose of that NAT rule.
3. When you turn a service off or on or replace/whatever make sure your production services are running just as they should be. You know you've done something right when the only thing the employees notice is the new thing they were expecting or nothing at all after your network project.
Subscribe to:
Posts (Atom)