|
Written by Alexei Spirin
|
|
Wednesday, 28 October 2009 13:36 |
|
Skype is an excellent VoIP and IM program and many people just love it because of its easiness and quality, but when it comes to a corporate world, a lot of things must be considered. Do we ready to give bandwidth for a non-business traffic? Do we completely trust skype developers? What about data leakage prevention - can we control data exchange inside skype protocol?
Usually, the answer to most of these questions is "no, we don't and we can't". So the next step is finding the right tool for the right job - blocking skype.
|
|
Last Updated on Sunday, 23 May 2010 13:10 |
|
|
Written by Alexei Spirin
|
|
Sunday, 19 October 2008 22:22 |
|
Hi! Sometimes we need to change CSA MC domain name but CSA MC has a SSL certificate which is tied with FQDN. Cisco's documentation isn't particularly clear so I decided to tidy up a bit in this place :)
|
|
Last Updated on Friday, 24 October 2008 22:24 |
|
Written by Alexei Spirin
|
|
Tuesday, 12 February 2008 22:24 |
|
NTP is abbreviation for Network Time Protocol which is used for clock synchronization of various devices on the net. There are three typical implementations of NTP in network infrastructure: a) no implementation b) useful implementation c) vital implementation.
The first option is an indicator that network is in poor condition. It has no real owner or owner isn't a network professional, etc.
The second option is the most common case for serious corporate network. The owner cares about event logging (at least) and event correlation in different parts of network. Complex debugging, security incident investigation requires the "right time" to be set. But still network functioning in general or service availability isn't tied with NTP.
And we have the third option. Vital dependency is when your network can't function without reliable NTP infrastructure. If your devices have wrong time that means no service for end-user. That's bad, isn't it? :)
I can name at least four technologies which comes to mind when we talk about NTP vital dependency:
|
|
Last Updated on Friday, 24 October 2008 22:28 |
|
|
Written by Alexei Spirin
|
|
Wednesday, 06 February 2008 18:36 |
|
I was always curious how the IPSec session looks like after PAT translation. As we discovered in IPSec basics: IPSec through NAT article, IPSec must use some NAT-avoiding mechanism to work through NAT/PAT. I have to say (for those who aren't IPSec fan) that most IPSec connections are made through the NAT (at least most Remote Access VPN connections). So that is a common case when IPSec session encapsulated in udp packets (in case of NAT-T).
Let's see what happens with one (first) IPSec session before and after PAT.
|
|
Last Updated on Friday, 24 October 2008 22:29 |
|
Written by Alexei Spirin
|
|
Wednesday, 06 February 2008 18:11 |
|
There are three NAT-handling algorithms in Cisco IPSEC implementations:
1) NAT-T (travesal, udp:4500). NAT device is unaware of IPSec. NAT-D(iscovery) packets are included in third and fourth IKE-exchange in Main Mode and in second and third messages in Aggressive Mode of IPSec negotiation.
2) NAT over TCP (tcp:10000). NAT device is unaware of IPSec. Proprietary solution (Cisco ASA, VPN Concentrator, IOS have it).
3) NAT support for IPSEC ESP Phase II. Used as a last resort when the Port Address Translation is configured somewhere between IPSec peers and one or both IPSec peer doesn't support NAT-T or NAT over TCP. NAT device must be SPI-aware (Security Policy Index). Configuration needed on both peers and NAT device.
|
|
Last Updated on Sunday, 23 May 2010 12:25 |
|
|
|
|
<< Start < Prev 1 2 Next > End >>
|
|
Page 1 of 2 |
