Do you need a network expert?

Enable Active FTP on Cisco ASA Firewalls - Chicago Network Experts

Tuesday, February 1, 2011 by Darren Sieck
On a Cisco ASA firewall, only passive FTP is supported by default.  Many 3rd party FTP servers use active FTP for file transfers. This includes users that enable the FTP service under IIS on a Windows Server and are using a browser as an FTP client. With the older Cisco PIX firewalls is was necessary to issue a fixup command but that format has been changed in the newer ASA.

**Note: Of course you will need a port forwarder or a static NAT rule, along with an access rule allowing the FTP protocol to your FTP server.**

To enable Active FTP on your ASA or PIX:

You may enter the following command on a Cisco ASA Firewall or PIX:  fixup protocol ftp 21

When entering that PIX command on an ASA it will auto convert to the ASA's MPF  command format automatically or you may enter the following MPF commands directly on the ASA:


class-map inspection_default
match default-inspection-traffic

policy-map asa_global_fw_policy
class inspection_default
inspect ftp

service-policy asa_global_fw_policy global

SkyByte has 12+ years of experience with Checkpoint Firewall 1 and Cisco firewalls. SkyByte is well versed in Checkpoint and Cisco ASA firewall upgrades and migrations.  Contact us today!

Enterprise Wireless Network Infrastructure Guide

Thursday, December 30, 2010 by Mario McGuire
Wireless networks are omnipresent, but an enterprise environment demands much more than a simple wireless router that you would use on a SOHO network. An enterprise-class router needs better security, better performance, and more features than basic routers. Most importantly, however, an enterprise wireless router needs to be able to manage the keys used to access it.

 

Standards-

Wireless standards have stabilized substantially in recent years. The older 802.11a, 802.11b, 802.11g, and 802.11N standards are well accepted. While you still need to make sure that the hardware in your network will support whichever standard you decide to use, the odds are good that if you're OK with the speeds the standard provides, you're not going to have to worry about what will and won't work on your network.

802.11a – Up to 54Mb/s 75’-100’ Indoor range 5Ghz

Least used technology due to the cost when it was initially adopted. Now it’s cost is not much more than b or g. Since the 2.4 GHz band is heavily used to the point of being crowded, using the relatively unused 5 GHz band gives 802.11a a significant advantage. However, this high carrier frequency also brings a disadvantage: the effective overall range of 802.11a is less than that of 802.11b/g.

802.11b – Up to 11Mb/s 125’-150’Indoor Range 2.4Ghz

The dramatic increase in throughput of 802.11b (compared to the original standard) along with simultaneous substantial price reductions led to the rapid acceptance of 802.11b as the definitive wireless LAN technology.

802.11b devices suffer interference from other products operating in the 2.4 GHz band. Devices operating in the 2.4 GHz range include: microwave ovens, Bluetooth devices, and cordless telephones.

802.11g – Up to 54Mb/s 125’-150’ Indoor Range 2.4Ghz

This works in the 2.4 GHz band (like 802.11b), and was rapidly adopted by consumers when it was released in 2003. It shares the same bandwidth as the 802.11b standard, and also most standard wireless adapters support b/g. 80211.g still suffers like 802.11b in that even devices like wireless keyboards can affect its signal.

802.11n – Up to 300Mb/s 200’-230’ Indoor Range 2.4/5Ghz

802.11n is a recent amendment which improves upon the previous 802.11 standards by adding multiple-input multiple-output antennas (MIMO). 802.11n operates on both the 2.4GHz and the lesser used 5 GHz bands. It has the longest range and also the least interference of all of the standards.

 Note that in some cases, using different standards at the same time can hurt your network's performance. If blazing-fast performance is your number one priority for your wireless network, only allow 802.11n connections.

 

Security-

A wireless network creates security problems that wired networks don't have to face. Potential attackers can sit outside of your building, point an antenna, and potentially access everything you've got. It's well known in security circles that some attempts at wireless security are virtually pointless—it's said that the Wired Equivalent Privacy (WEP) standard has been completely cracked and a determined attacker can get through WEP protection in under a minute.

An enterprise environment should definitely support the Wi-Fi Protected Access 2 (WPA2) encryption standard. You might have older wireless equipment that isn't compatible with WPA2, but the risk of leaving your network exposed isn't worth taking for old equipment. Keep the older, pre-WPA2 equipment in mind, however—if you have older laptops or expect on-site guests with them, you'll need to provide an alternative, like a wired network.

Encryption isn't the only defense for your wireless network. Most enterprise-class wireless routers support VPN tunnels, and other features such as integration with a security suite are common. Remember that you have to protect your network, but also remember that advanced security features often carry a performance cost, so carefully balance your networks.

 

Performance-

Modern wireless routers can handle many simultaneous connections and lots of bandwidth, a major difference from less expensive SOHO routers. Plan ahead and know how much bandwidth and how many connections you'll need, though, because high-bandwidth applications and reliable connections are more vital as laptops and netbooks become more popular than desktops, even in enterprise settings.

An important consideration for wireless performance is range, but unfortunately your building, not your router, is probably going to be the biggest factor in range. It's probably not feasible to change your building's layout and construction materials for the sake of a wireless network, so plan to install repeaters for your wireless signal.

 

What Are Your Needs-

Wireless technology has advanced quickly in the last few years, so if you need a wireless network to perform certain task, chances are the equipment you need is available. The prices for wireless equipment vary by huge amounts, however, so take a thorough inventory of what you want to connect to your wireless network now and what you'll want to connect in the future.

What is your companies Network Security Policy? If you don't have one I suggest your perform Network Security Assessments and make sure that your putting the best effort you can into maintaing your data's safety.

Remember that you'll probably be connecting much more than laptops to your wireless network. Wi-Fi enabled smart phones are the norm now, and even devices such as media players and video game consoles have wireless access. There's no telling how people will want to use your wireless network in the next few years. SkyByte Consulting can assist with any of your companies network security projects from Cisco ASA firewalls, to Checkpoint support, VPN installations, and even performing network security assessments. 


Problems with Infopath forms in Sharepoint deployment using host headers & TMG 2010

Thursday, December 9, 2010 by Mario McGuire

Recently I had the chance to migrate a Forefront Threat Management Gateway 2010 RC environment over to the TMG 2010 RTM SP1. The RC had been developing some issues and it was time to install with the full produciton release. The server was only needed for reverse proxy for a SharePoint implementation.

Our users access SharePoint sites and our InfoPath form in 1 of 3 different ways:

Via the Intranet: http://sharepoint.mycompany.com
Via the Extranet: http://sharepoint.mycompany.com
Via the TMG 2010 Server: https://sharepoint.mycompany.com

The form is set to domain trust, published from InfoPath as a site content type and associated with a SharePoint document library (browser compatible) at https://sharepoint.mycompany.com


After setting up TMG and verifying that people could access the sites externally and internally I turned to testing the functionality of the site and the forms located within.

When accessing externally I noticed that approving published documents tied to the workflow would generate an InfoPath error stating "The form cannot be submitted to the Web server either because your computer is offline or because the host server is currently unavailable. If this problem persists, contact your network administrator." Internally the forms would work flawlessly, but that was due to TMG only handling the external traffic.

This was perplexing because it worked in the previous RC version of TMG. Now it was time for troubleshooting SharePoint and how the TMG communicated the host headers when accessing the forms.

After some looking and testing I noticed on closing the form users were then redirected to https://sharepoint.intranet (the URL that the form is published to in InfoPath) which of course they could not access. I looked around on the Internet and found some articles on this exact problem but they were relating to ISA Server 2004 and 2006.

I tracked it down via View Source on the InfoPath web form. There's a javascript array variable in there called "g_objCurrentFormData", which contains some URL strings. I guess InfoPath is using these as part of the submit process.

If these domain strings in "g_objCurrentFormData" don't exactly match the domain in which the form is being viewed, **including the https!** then the submit will be blocked (....browser-level prevention of cross-domain shennanigans, I suppose.)

Oddly enough the forward slashes are encoded by InfoPath as u002f.... in case you didn't guess.

In our case, the form was hosted at our SharePoint site https://sharepoint.mydomain.com, but the javascript strings showed "http:u002fu002fmydomain.com", i.e. missing the "s". The Link Translation Rule converted these into "https:u002fu002fmydomain.com", which did the trick.

Running Fiddler before and after the Link Translation Rule was defined showed....
Before:
No Fiddler traffic on submit.
After
A POST to the SharePoint domain on submit!

The Solution:

Create a link translation in your Rule for your published SharePoint site with the InfoPath form.

From: http:u002fu002fsharepoint.mydomain.com
To: https:u002fu002fsharepoint.mydomain.com

Also leaving the

From: http://sharepoint.mydomain.com
To: https://sharepoint.mydomain.com

So you should show both entries in your link translation.

Skybyte Consulting is Chicago's premiere IT consulting firm. We provide local area network design, disaster recovery solutions, Cisco IP Phone Support, Cisco ASA Firewall support, Checkpoint support, VPN installation, (SAN) storage area network support and much more!