You can download it Here:

 http://www.mrkernel.net/freemwi_1.0.zip

Instalation and Configureation instructions are in the download.

I would love to hear if you have found this usefull and how your are using it. Contact info is in the download.

Normally there is two ways to logon to Active Directory

Domain\username and username@domain.local

I have found that if you log into the phone using

domain.local\username

The phone is able to find the domain and download the certificate.

I found this out while doing a packet trace on the phone one day and found this search behavior

Netbios AD name: test

UPN Suffix: test.local

DNS Suffix: abc.com - this is given to the phone via DHCP

so the DNS queries from the phone was this

test

test.abc.com - e.g. domain + DNS sufix 

I can’t remember the rest of the top of my head, but if you do

test.local\username

the first query is

test.local

R1

interface Loopback0
 ip address 172.30.123.254 255.255.255.255
 ip ospf 1 area 0.0.0.0
 ipv6 address 2001:FFFF::FFFF/128
 ipv6 ospf 1 area 0.0.0.0
!
interface Tunnel2
 description Tunnel to Friend
 ip address 192.168.254.2 255.255.255.252
 ipv6 address 2001:FFFE::2/126
 ipv6 enable
 tunnel source GigabitEthernet0/0
 tunnel destination x.x.x.x
!
router ospf 1
 log-adjacency-changes detail
 area 0.0.0.0 authentication message-digest
 default-information originate always
!
interface GigabitEthernet0/1
 ip address 10.10.0.254 255.255.255.0
 ip nat inside
 no ip virtual-reassembly
 ip ospf message-digest-key 1 md5 ****
 ip ospf 1 area 0.0.0.0
 ipv6 address 2001::FFFF/64
 ipv6 enable
 ipv6 ospf 1 area 0.0.0.0
!
router bgp 65500
 template peer-policy IBGP
  next-hop-self
 exit-peer-policy
 !
 template peer-session IBGP
  remote-as 65500
  update-source Loopback0
  fall-over
 exit-peer-session
 !
 template peer-session friend
  remote-as 65501
  update-source Tunnel2
 exit-peer-session
 !
 bgp router-id 172.30.123.254
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2001:FFFE::1 inherit peer-session joel
 neighbor 2001:FFFF::FFFE inherit peer-session IBGP
 neighbor 172.30.123.252 inherit peer-session IBGP
 neighbor 192.168.254.1 inherit peer-session friend
 !
 address-family ipv4
  redistribute ospf 1
  neighbor 172.30.123.252 activate
  neighbor 172.30.123.252 inherit peer-policy IBGP
  neighbor 192.168.254.1 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv6
  neighbor 2001:FFFE::1 activate
  neighbor 2001:FFFF::FFFE activate
  neighbor 2001:FFFF::FFFE inherit peer-policy IBGP
  redistribute ospf 1
  no synchronization
 exit-address-family
!
ipv6 router ospf 1
 log-adjacency-changes detail
 default-information originate always

R2

interface Loopback0
 ip address 172.30.123.252 255.255.255.255
 ip ospf 1 area 0.0.0.0
 ipv6 address 2001:FFFF::FFFE/128
 ipv6 enable
 ipv6 ospf 1 area 0.0.0.0
!
interface Tunnel2
 description Tunnel to friend
 ip address 192.168.254.6 255.255.255.252
 ipv6 address 2001:4830:165C:FFFE::6/126
 ipv6 enable
 tunnel source ATM0/0/0.33
 tunnel destination x.x.x.x
!
!
interface GigabitEthernet0/1
 ip address 10.10.0.252 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 ip ospf message-digest-key 1 md5 ****
 ip ospf 1 area 0.0.0.0
 ipv6 address 2001::FFFD/64
 ipv6 enable
 ipv6 ospf 1 area 0.0.0.0
!
!
router ospf 1
 log-adjacency-changes detail
 area 0.0.0.0 authentication message-digest
 default-information originate always metric 9000
!
router bgp 65500
 template peer-policy IBGP
  next-hop-self
 exit-peer-policy
 !
 template peer-session IBGP
  remote-as 65500
  update-source Loopback0
  fall-over
 exit-peer-session
 !
 template peer-session friend
  remote-as 65501
  update-source Tunnel2
 exit-peer-session
 !
 bgp router-id 172.30.123.252
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 2001::5 inherit peer-session joel
 neighbor 2001::FFFF inherit peer-session IBGP
 neighbor 172.30.123.254 inherit peer-session IBGP
 neighbor 192.168.254.5 inherit peer-session friend
 !
 address-family ipv4
  redistribute ospf 1
  neighbor 172.30.123.254 activate
  neighbor 172.30.123.254 inherit peer-policy IBGP
  neighbor 192.168.254.5 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family ipv6
  neighbor 2001::5 activate
  neighbor 2001::FFFF activate
  neighbor 2001::FFFF inherit peer-policy IBGP
  redistribute ospf 1
  no synchronization
 exit-address-family
!
ipv6 router ospf 1
 log-adjacency-changes detail

Thats my current setup for MP-BGP and IPv4/IPv6.

�

�

I got a hold of a few OCPE devices. Both the Polycom CX700 http://www.polycom.com/usa/en/products/voice/desktop/cx/communicator_cx700.html and the LG-Nortel 8540 http://www.nortel.com/8540. As anyone who has tried to connect them to Office Communication Server (OCS) 2007 knows, the first thing you must do is get the CA certificate on the phones. Being that they are RTM firmware the official ways of doing this are http://blogs.technet.com/jenstr/archive/2007/11/17/how-to-make-the-root-ca-certificate-available-for-office-communicator-2007-phone-edition.aspx. This works fairly slick except, in my experience, when the phone is not on the same subnet of a domain controller. When the OCPE is factory defaults and on different subnet from a domain controller it is unable to download the certificate. The error I get is “Cannot download certificate because domain is not accessible.”

Doing a packet trace I see that the OCPE does a broadcast for the domain in attempt to find it, it does not use DNS to find the domain. If I put the OCPE on the same subnet as a Domain Controller it downloads the certificate, and once that is done I am able to move it to another subnet. Great I thought it sucks that I can’t figure out how to deploy a phone on a non Domain Controller subnet but at least I have a workaround. I have since then deployed an OCPE Update Server. Guess what, when a phone gets upgraded it loses its CA Certificate. The login and PIN/Fingerprint are retained put not the Certificate. So the phone is no longer able to register. So what could I do to get this to work? Well, back in Windows NT4.0 when you needed to access a Domain Controller on a different subnet what did you use? Well WINS of course. But surely a newly engineered device in 2008 would not be able to utilize WINS. Guess what it does, I fired up a WINS service on one of my boxes, added the ip address to the DHCP scope of the OCPE and vola, certificate downloaded. So this really bugs me, I haven’t used WINS since before 2000, does Microsoft honestly expect its customers to deploy a WINS infrastructure just for an OCPE  deployment? If anyone else has had different or similar experience with the OCPE and different subnets please let me know. I will post a solution if I find one.

�

The example will be a site to site tunnel between OpenBSD 3.9 and Linux with OpenSWAN using a PSK. This is for simpliscity sake only.

10.10.100.x/24 –[OpenBSD]4.4.4.1—–{Internet}—–3.3.3.1[Linux]–192.168.1.0/24

We will start with a fresh installation of OpenSWAN [http://www.openswan.org/] on Centos [http://www.centos.org/]. Very simple configureation

/etc/ipsec.conf

—Start—

version 2.0
config setup

conn ahfmr-to-test
pfs=no
left=4.4.4.1
leftsubnet=10.10.100.0/24
leftid=@openbsd.domain.local
leftnexthop=%defaultroute
right=3.3.3.1
rightsubnet=192.168.1.0/24
rightid=@linux.domain.local
rightnexthop=%defaultroute
authby=secret
auto=start

—End—

/etc/ipsec.secrets

—Start—

@openbsd.domain.local @linux.domain.local : PSK “testing123″

—End—

For the OpenBSD configuration we will start with a stock 3.9 install.

/etc/isakmpd/isakmpd.conf

—Start—

# A configuration sample for the isakmpd ISAKMP/Oakley (aka IKE) daemon.

[General]
Listen-on= 4.4.4.1

# Incoming phase 1 negotiations are multiplexed on the source IP address
[Phase 1]
3.3.3.1= ISAKMP-peer-west

# These connections are walked over after config file parsing and told
# to the application layer so that it will inform us when traffic wants to
# pass over them. This means we can do on-demand keying.
[Phase 2]
connections= IPsec-east-west
passive-connections= IPsec-east-west
[my-fqdn]
ID-type= FQDN
Name= openbsd.domain.local

[my-ipv4-addr]
ID-type= IPV4_ADDR
Address= 4.4.4.1

# Default values are commented out.
[ISAKMP-peer-west]
Phase= 1
Address= 3.3.3.1
authentication= testing123
Configuration= main-mode
ID= my-fqdn
Remote-ID= freeswan-fqdn

[freeswan-fqdn]
ID-type= FQDN
Name= linux.domain.local
[IPsec-east-west]
Phase= 2
ISAKMP-peer= ISAKMP-peer-west
Configuration= quick-mode
Local-ID= Net-east
Remote-ID= Net-west

[Net-west]
ID-type= IPV4_ADDR_SUBNET
Network= 10.10.100.0
Netmask= 255.255.255.0

[Net-east]
ID-type= IPV4_ADDR_SUBNET
Network= 192.168.1.0
netmask= 255.255.255.0

[main-mode]
DOI= IPSEC
EXCHANGE_TYPE= ID_PROT
Transforms= 3DES-SHA-RSA_SIG, 3DES-SHA

[quick-mode]
DOI= IPSEC
EXCHANGE_TYPE= QUICK_MODE
Suites= QM-ESP-AES-SHA-SUITE, QM-ESP-3DES-SHA-SUITE
—End—

/etc/isakmpd/isakmpd.policy

—Start—

Authorizer: “POLICY”
Comment: This bare-bones assertion accepts everything

—End—

Then to start the tunnel “service ipsec start” on the linux box and “isakmpd” on the OpenBSD box. two usefull debuging commands are “ipsec whack –status” on linux and on OpenBSD run isakmpd in the forground with “isakmpd -d”.
This solution is by no means the as secure as it could be. It is just a starting point. Hope this is of some interest.