About Scott.DeLand

This author has not yet filled in any details.
So far Scott.DeLand has created 2 blog entries.

A Fortinet Site/Site IPSec VPN from a Valid Address…

2012-05-16T22:26:35+00:00 May 16th, 2012|Uncategorized|

It’s fairly common for two enterprises to temporarily connect their private data networks to each other for business purposes.  It’s actually pretty easy to do, especially when the main purpose of the connection is for one side to  access resources on the other.

However, over the past weeks we struggled a bit with a Fortinet firewall to connect to a Site-to-Site IPSec VPN.  Because in this case, we wanted to NAT all traffic destined for the distant network, and to have it appear to come from a valid address. 

All knowledge base articles we could find only showed NATing internal addresses.  Ultimately, the fix was to run the following lines from the Fortinet CLI (interestingly, no static/policy routes need to be added to the firewall):  

config vpn ipsec phase1 
edit "Phase 1 VPN Name"   
set interface *firewall external WAN interface*   
set nattraversal enable   
set proposal aes-md5 *or whatever encryption is used on the opposite end*   
set psksecret *Decided upon key*   
set remote-gw *IP Address of Remote Device* 
config vpn ipsec phase2  
edit "Phase 2 VPN Name"    
set keepalive enable    
set pfs enable    
set phase1name "Phase 1 VPN Name"    
set proposal aes-md5 *or whatever encryption is used on the opposite end*    
set replay enable    
set use-natip disable  
config firewall policy  
edit 9    
set srcintf internal *firewall Interal LAN interface*    
set dstintf wan1 *firewall external WAN interface*    
set srcaddr "Internal Range" *Group created to specify internal subnet needing to traverse VPN*    
set dstaddr "VPN Destination Subnets" *Group created of Firewall Addresses from subnets on remote VPN side*    
set action ipsec *Encrpyts the traffic across the VPN Tunnel*    
set schedule always    
set service ANY *Can be Specific*    
set natip X.X.X.X *Replace X.X.X.X with valid IP Address*    
set inbound enable    
set outbound enable    
set natoutbound enable    
set vpntunnel "Phase 1 VPN Name"  

We hope this helps you!


Easy Guest Access in Secure Wireless Networks

2017-07-27T00:01:08+00:00 November 17th, 2011|Uncategorized|

The Challenge

I’ve seen it happen; people sometimes hand out the corporation’s wireless security passphrases to allow visitors access to the internet.  Without the right equipment and design, this opens the internal network to the guest.  

Even though they’ve been warned that this behavior may put their infrastructure at risk, employees often want and need to give this access to their visitors.  It’s even more scary when policies are not in place to change pass phrases at regular intervals; possibly permitting the guest to retain the pass phrase for years without being noticed (obviously, I’m not talking about two factor authentication devices here).

One Solution

Several methods are available to allow guest access to the internet from your wireless network without sacrificing security.  Some require purchasing secondary wireless devices, and/or configuring VLANs throughout the network infrastructure.  Or if you’re lucky enough to have a Ruckus Wireless Controller, it’s built in.  Active Directory users can create their own guest passes on an easy-to-use webpage.

The Configuration

Within the Ruckus ZoneDirector, click the Configure tab.  Under the WLANs tab, create a new WLAN.  After the naming and description option, the Ruckus software allows three types of WLAN Usages (Standard, Guest Access, and Hotspot Service).  For Guest Access WLANs, the access is based on Guest Access Policies and access controls which are defined in Guest Access area of the Configuration tab.  Within here, you can define Authentication, compose your Terms of Use, and even Redirection of website requests.  Guest Pass Generation Authentication permissions can based either on a local database, or Microsoft’s Active Directory.  Most important within this section is Restricted Subnet Access.  The Ruckus setup acts as a proxy for guests thus easing the configuration by avoiding complex VLAN configurations throughout the networking infrastructure.

Problem solved!


Fatal error: Uncaught exception 'GuzzleHttp\Exception\ClientException' with message 'Client error: `POST https://dc.services.visualstudio.com/v2/track` resulted in a `400 Invalid instrumentation key` response: {"itemsReceived":1,"itemsAccepted":0,"errors":[{"index":0,"statusCode":400,"message":"Invalid instrumentation key"}]} ' in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php:113 Stack trace: #0 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Middleware.php(66): GuzzleHttp\Exception\RequestException::create(Object(GuzzleHttp\Psr7\Request), Object(GuzzleHttp\Psr7\Response)) #1 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(203): GuzzleHttp\Middleware::GuzzleHttp\{closure}(Object(GuzzleHttp\Psr7\Response)) #2 /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/promises/src/Promise.php(156): GuzzleHttp\Promi in /home/coretek/public_html/wp-content/plugins/application-insights/vendor/guzzlehttp/guzzle/src/Exception/RequestException.php on line 113