Forwarded Calls don’t contain the Called Party’s number in Lync

Forwarded Calls don’t contain the Called Party’s number

When you setup Lync forwarding or simultaneous ring it always passes the original callers number in the FROM field.

In the example shown above +44 123 4567 calls +44 987 6543 the Lync user has setup a call forward to another number +44 765 4321. When you receive the call on +44 765 4321 you see the original caller id +44 123 4567.

SIP Header wise this is what is sent from the Mediation server to the ITSP:

INVITE sip:07654321@20.20.20.20;user=phone SIP/2.0 FROM: <sip:+441234567@contoso.com;user=phone>;epid=81E23DEAF8;tag=ab6896ea7e TO: <sip:07654321@20.20.20.20;user=phone>CSEQ: 2 INVITE CALL-ID: b983d9b2-c75a-48e3-a702-ec9b5ef98eb0 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 10.10.10.10:57672;branch=z9hG4bK693cdab6 CONTACT: <sip:lyncmed01.contoso.com:5060;transport=Tcp;maddr=10.10.10.10;ms-opaque=ed082191311c6e3b> CONTENT-LENGTH: 344 SUPPORTED: 100rel USER-AGENT: RTCC/4.0.0.0 MediationServer CONTENT-TYPE: application/sdp …………

As you can see the FROM is set to the external callers number and the TO is set to the forwarded to number. Although this can be useful to the person receiving the call to see where the call is coming from it does however cause issues for some ITSP’s (Internet Telephony Service Providers)

Introduced in CU2 was a fix to allow a REFFERED-BY header to be added however after applying the patch (or even CU3) the header does not appear. It is alluded to here in the KB article http://support.microsoft.com/kb/2517730

However it mentions that you need to apply 255421 as well which doesn’t exist (I assume this will be corrected). The actual KB article is 2500421  (http://support.microsoft.com/kb/2500421

Here is explains you need to update the Mediation server config file.

For those of you that have never had to update the config file it is in the Mediation server directory which by default can be found here:

C:\Program Files\Microsoft Lync Server 2010\Mediation Server\MediationServerSvc.exe.config

For the SIP trace above you would modify the file to:

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<appSettings>
                <add key=”20.20.20.20.ReferredBySupported” value=”true”/>
    </appSettings>
  <runtime>
    <generatePublisherEvidence enabled=”false”/>
  </runtime>
</configuration>

Once you save this file (don’t forget you need to run notepad as administrator to save it) you restart the Mediation Server service.

The headers now appear as

INVITE sip:07654321@20.20.20.20;user=phone SIP/2.0 FROM: <sip:+441234567@contoso.com;user=phone>;epid=DB23987285;tag=c495f66513 TO: <sip:07654321@20.20.20.20;user=phone>CSEQ: 1 INVITE CALL-ID: a2c887ef-a162-4b11-87a5-daf222734f18 MAX-FORWARDS: 70 VIA: SIP/2.0/TCP 10.10.10.10:57761;branch=z9hG4bK370cbae CONTACT: <sip:lyncmed01.contoso.com:5060;transport=Tcp;maddr=10.10.10.10;ms-opaque=8c6fc24ca0304215> CONTENT-LENGTH: 344 REFERRED-BY: <tel:+449876543>SUPPORTED: 100rel USER-AGENT: RTCC/4.0.0.0 MediationServer CONTENT-TYPE: application/sdp …………

You can see the FROM and TO headers remain the same but you now have a REFFERED-BY header with the called party’s number. The ITSP can then use this value.

https://support.microsoft.com/ru-ru/help/2500421/the-call-history-information-is-incomplete-in-lync-server-2010-mediati

Варианты реализации IPSec VPN туннелей на оборудовании Cisco

Источник: http://kickself.com/variantyi-realizatsii-ipsec-vpn-tuneley-na-oborudovanii-cisco/

В этой статье посмотрим на разные технологии реализации статических site-to-site IPSecтуннелей на оборудовании Cisco с позиции того, как та или иная технология инкапсулирует исходный пакет в новые заголовки и как это сказывается на конечном размере и структуре пакета.

Использовать будем вот эту простую, собранную в GNS3 топологию:

На транзитном роутере будем наблюдать за ICMP-пакетами между лупбеками маршрутизаторов Site A и Site B. Команды, которые нужно ввести на транзитном роутере для того, чтобы иметь возможность наблюдать за проходящим через него интересующим нас трафиком, представлены на рисунке.

Для начала просто выполним ICMP ping с роутера Site A, чтобы посмотреть, как выглядит пакет до начала разного рода извращений над ним:

SiteA# ping 192.168.3.3 source lo0 size 100

В дебаге на транзитном роутере видим:

*Sep 2 12:20:06.715: IP: s=192.168.1.1 (FastEthernet1/0), d=192.168.3.3, len 100, input feature…..

Ну, это, собственно понятно – послали ICMP-пакет размером 100 байт – таким он и дошел до транзитного роутера. Т.е. сейчас он (пакет), если не учитывать заголовок и трейлер канального уровня, выглядит так:

Теперь будем экспериментировать.

1. IPSec с «классическими» crypto-map

Сразу приведу конфигурацию для SiteA и SiteB маршрутизаторов. Выглядеть она будет так (все в самом простом виде, все лишнее успешно удалено, дабы не загружать ненужной в рамках статьи информацией):

Site A

Site B

hostname SiteA ! crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.1.23.3 ! crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel ! crypto map CRYPTOMAP 10 ipsec-isakmp set peer 10.1.23.3 set transform-set TS match address CRYPTOACL ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 ! interface FastEthernet1/0 ip address 10.1.12.1 255.255.255.0 crypto map CRYPTOMAP ! ip route 0.0.0.0 0.0.0.0 10.1.12.2 ! ip access-list extended CRYPTOACL permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

hostname SiteB ! crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.1.12.1 ! crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel ! crypto map CRYPTOMAP 10 ipsec-isakmp set peer 10.1.12.1 set transform-set TS match address CRYPTOACL ! interface Loopback0 ip address 192.168.3.3 255.255.255.0 ! interface FastEthernet1/0 ip address 10.1.23.3 255.255.255.0 crypto map CRYPTOMAP ! ip route 0.0.0.0 0.0.0.0 10.1.23.2 ! ip access-list extended CRYPTOACL permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255

Выполним icmp-ping:

SiteA# ping 192.168.3.3 source lo0 size 100

В дебаге на транзитном роутере теперь видим вот что:

*Sep 2 12:44:15.579: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), len 168….

Пакет теперь «весит» аж на 68 байт больше. Из чего состоит этот дополнительный overhead? Посмотрим на следующий рисунок:

Во-первых, добавился новый IP заголовок, самый обычный, размером 20 байт. Это обусловлено тем, что в данном случае используется туннельный режим ESP (tunnel mode), благодаря чему и становится возможным передача IPSec –трафика через публичные сети. Src IP и Dst IP в новом заголовке — это уже не адреса источника и получателя пакета, а адреса внешних интерфейсов VPN-шлюзов.

Во вторых, добавились поля протокола ESP — заголовок, трейлер и поле аутентификации. Длина полей, имеющих отношение к ESP зависит от выбранных алгоритмов шифрования/хеширования. В нашем случае был взят IPSec transform set с алгоритмами aes и sha соответственно (этот выбор мы и оставим для последующих экспериментов). Если бы, например, вместо aes использовался des – размер полей пакета, имеющих отношение к ESP был бы меньше. В нашем случае он равен 168(общая длина пакета) – 100(размер оригинального пакета) – 20 (размер нового IP заголовка) = 48 байт.

2. GRE over IPSec

GRE over IPSec предполагает создание GRE-туннеля между VPN-шлюзами и последующее шифрование GRE-трафика.

Для начала, давайте сначала просто настроим GRE-тунель между SiteA и SiteB без навешивания на него IPSec:

Site A

Site B

hostname SiteA ! crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.1.23.3 ! crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel ! crypto map CRYPTOMAP 10 ipsec-isakmp     set peer 10.1.23.3     set transform-set TS     match address CRYPTOACL ! interface Loopback0 ip address 192.168.1.1 255.255.255.0 !   interface Tunnel0     ip unnumbered FastEthernet1/0     tunnel source FastEthernet1/0     tunnel destination 10.1.23.3 ! interface FastEthernet1/0 ip address 10.1.12.1 255.255.255.0 crypto map CRYPTOMAP ! ip route 0.0.0.0 0.0.0.0 10.1.12.2   ip route 192.168.3.0 255.255.255.0 Tunnel0 ! ip access-list extended CRYPTOACL     permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

hostname SiteB ! crypto isakmp policy 10 encr aes authentication pre-share group 2 crypto isakmp key cisco address 10.1.12.1 ! crypto ipsec transform-set TS esp-aes esp-sha-hmac mode tunnel ! crypto map CRYPTOMAP 10 ipsec-isakmp     set peer 10.1.12.1     set transform-set TS     match address CRYPTOACL ! interface Loopback0 ip address 192.168.3.3 255.255.255.0 ! interface Tunnel0     ip unnumbered FastEthernet1/0     tunnel source FastEthernet1/0     tunnel destination 10.1.23.3 ! interface FastEthernet1/0 ip address 10.1.23.3 255.255.255.0 crypto map CRYPTOMAP ! ip route 0.0.0.0 0.0.0.0 10.1.23.2 ip route 192.168.3.0 255.255.255.0 Tunnel0 ! ip access-list extended CRYPTOACL     permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255

В приведенной таблице, добавленные строки выделены, а удаленные – зачеркнуты.

Что мы ожидаем увидеть? По логике, исходный пакет, размером 100 байт, инкапсулируется в GRE, заголовок которого равен 4 байта и ко всему этому добавится новый 20-байтовый IPзаголовок , содержащий IP-адреса маршрутизаторов SiteAи SiteB. Таким образом общий размер пакета должен составить 124 байта а выглядеть он должен так:

Подтвердим, что вышесказанное соответствует действительности, выполнив традиционный ICMP ping:

SiteA# ping 192.168.3.3 source lo0 size 100

Посмотрим, что показывает debug на транзитном роутере:

*Sep 2 14:54:32.183: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), len 124, sending full packet

Все действительно так, как и предполагалось.

Теперь добавим IPSec «поверх» GRE. Для этого создадим IPSec profile и повесим его на туннельный интерфейс каждого VPN-шлюза:

Site A	Site B
crypto ipsec profile IPSECPROFILE set transform-set TS ! interface Tunnel0 tunnel protection ipsec profile IPSECPROFILE	crypto ipsec profile IPSECPROFILE set transform-set TS ! interface Tunnel0 tunnel protection ipsec profile IPSECPROFILE

Снова выполним ping с маршрутизатора Site A и посмотрим дебаг на транзитном роутере:

*Sep 2 15:17:24.958: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), g=10.1.23.3, len 184, forward

Теперь, размер пакета составил целых 184 байта! Почти в два раза больше исходного. Представим  визуально что из себя представляет GRE over IPSec пакет:

На приведенной диаграмме явно бросается в глаза, что один и тот же внешний заголовок присутствует в пакете дважды. Первый раз роутер прицепил его к пакету, когда инкапсулировал в GRE, второй – когда уже GRE инкапсулировал в IPSec (в частности в ESP). Очевидно, что в данном случае целесообразно использовать транспортный режим IPSec, когда новый IP заголовок не добавляется. В этом случае можно сэкономить лишние несколько байт. Внесем соответствующие изменения в конфигурацию каждого из VPN-шлюзов:

Site A	Site B
crypto ipsec transform-set TS esp-aes esp-sha-hmac mode transport	crypto ipsec transform-set TS esp-aes esp-sha-hmac mode transport

После очередного ping с роутера Site A на транзитном роутере видим следующее:

*Sep 2 15:49:00.802: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), len 168, sending full packet

Теперь длина пакета – 168 байт. На 16 меньше чем в туннельном режиме. Почему не на 20, ведь размер IP заголовка от которого мы избавились равен 20 байтам? Потому, что этот заголовок был также зашифрован ESP, а длина зашифрованного, как правило, не равна длине оригинального. В данном случае это не столь важно. Важно, что мы избавились от лишнего заголовка и тем самым уменьшили overhead хотя бы на какую-то часть. Выглядит GRE over IPSec в транспортном режиме так:

Посмотрим два момента, которые отражают все, о чем говорилось выше, и будут полезны дальше:

SiteA#sh int tunnel 0 | i transport|protection

  Tunnel protocol/transport GRE/IP
  Tunnel transport MTU 1434 bytes
  Tunnel protection via IPSec (profile «IPSECPROFILE»)

SiteA#sh crypto ipsec sa | i inbound|outbound|setting

     current outbound spi: 0xD761501C(3613478940)
     inbound esp sas:
        in use settings ={Transport, }
          outbound esp sas:
        in use settings ={Transport, }

Тут более наглядно видно, что туннельный интерфейс работает в режиме GRE/IPи для его защиты используется IPSec в транспортном режиме.

 3. Virtual Tunnel Interface (VTI)

Что такое VTI и чем он отличается от обычного GRE over IPSec? Чтобы не вдаваться в детали, скажу следующее: это тот же GRE over IPSec, т.е. конструкция, построенная с использованием туннельных интерфейсов (через которые с успехом могут функционировать протоколы маршрутизации и другой мультикаст-трафик) со всеми их плюсами, но исключен сам GRE заголовок. Т.е., если взять последнюю схему, где представлен GRE over IPSec с IPSec в транспортном режиме и превратить ее в Static VTI, получим вот что:

Если сравнить с самой первой картинкой, где для создания туннелей использовались crypto-map, очень сложно увидеть какие-либо отличия. А сложно потому, что их нет. На выходе пакет выглядит одинаково, независимо от технологии настройки туннеля. Длина также составляет 168 байт и является минимально возможной для выбранных алгоритмов шифрования/хеширования и размера исходного пакета. Отсюда вывод: технология VTI в маршрутизаторах Cisco призвана обеспечить возможность построения VPN-тунелей, имеющих все преимущества технологии GRE over IPSec (как, например, поддержка динамической маршрутизации), и при этом сохранить overhead минимальным (таким же, как и при использовании технологии crypto-map).

Для того, чтобы превратить туннели GRE over IPsec из предыдущего примера в VTI, нужно внести серьезные изменения в конфигурацию VPN-шлюзов:

Site A	Site B
Interface tunnel 0 mode ipsec ipv4	Interface tunnel 0 mode ipsec ipv4

После этого, посмотрим, как обычно на debug транзитного маршрутизатора:

*Sep 2 17:07:18.930: IP: s=10.1.12.1 (FastEthernet1/0), d=10.1.23.3 (FastEthernet1/1), g=10.1.23.3, len 168, forward

Тут никаких изменений нет. Длина пакета по прежнему 168 байт. Связано, это, видимо с тем, что в предыдущем случае был использован транспортный режим ESP, а здесь, т.к. GRE больше нет, IPSec работает в туннельном режиме, игнорируя тот факт, что в конфиге явно задан транспортный.

Пара show комманд для сравнения с GRE over IPSec:

SiteA#sh int tunnel 0 | i transport|protection

  Tunnel protocol/transport IPSEC/IP
  Tunnel transport MTU 1438 bytes
  Tunnel protection via IPSec (profile «IPSECPROFILE»)

SiteA#sh crypto ipsec sa | i inbound|outbound|setting

     current outbound spi: 0x7183DC1D(1904466973)
     inbound esp sas:
        in use settings ={Tunnel, }
        in use settings ={Tunnel, }
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
        in use settings ={Tunnel, }
        in use settings ={Tunnel, }

Подведем итог

Размер исходного пакета: 100 байт

Размер пакета при использовании ESP в тунельном режиме и криптокартами: 168 байт.
Размер пакета при использовании GRE over IPSec(ESP) в туннельном режиме: 184 байта.
Размер пакета при использовании GRE over IPSec(ESP) в транспортном режиме: 168 байт.
Размер пакета при испольовании Static VTI интерфейсов в туннельном режиме: 168 байт.

При желании можно проделать аналогичные эксперименты с AH, задействовать другие алгоритмы или сделать то же самое с IPv6. Подобные эксприменты полезно проводить для формирования  четкого представления о том, как применение той или иной технологии реализации IPSec сказывается на конечный вид IP пакета, какой вносит overhead и т.д. Целесообразно при этом еще использовать Wireshark (тем более в GNS с этим никаких проблем нет), где наиболее наглядно видно какие заголовки добавлены, их структура и размер.

OSPF: Area range vs Summary address

It seems like an easy one! I mean what could be so hard about area range and summary address command? You will be surprised how many people tend to forget this things or to apply them when not necessary or even worst where is their place to be added. It’s basic knowledge, but sometimes exactly this basic knowledge give us headache.

In the following line, I will try to explain briefly the difference between Area range and Summary address command. First let’s have a look at the following topology:

We have mixed network domain with EIGRP and OSPF. From documentation we know that along other routers in OSPF domain we have 2 important routers:
ASBR (Autonomous System Boundary Router) – One device at the edge of OSPF domain, that receive routes from another non-OSPF domain (e.g. RIP, EIGRP…)
ABR (Area Border Router) – One device inside the OSPF domain that assure Inter-area communication (e.g. area 0 and area 1)

You will find situation when only one physical device will be ASBR and ABR router. The functionality and rules remain the same, just that instead of having 2 device you have only one that connect to another non-OSPF domain and in the same time to multiple OSPF areas.

Why we would use this 2 commands? Well one simple explanation is that we want to summarize advertised subnets to reduce the total number of routes present in the routing table. Less routes means less overhead and load for a router.

Let’s have a look to the routers presented in the above topology. The dynamic IP routing protocols (EIGRP and OSPF) are already configured and functional. For the IP network clouds, I have used Loopback interfaces.

R1:

On R1 the 2 IP subnets (192.168.1.0/24 and 192.168.2.0/24) are present in EIGRP routing protocol.

R2:

On R2, there is already a basic redistribution between OSPF and EIGRP. Also notice that the IP subnet which connect R2 and R3 is routed in OSPF area 0 (zero)

R3:

As well on R3, the IP subnet between R2 and R3 is present in OSPF area 0 (zero) and the other 2 subnets (10.10.1.0 /24 and 10.10.2.0 /24) are in OSPF area 1 (one). Now, if you remember from my older post, if you have a Loopback interface with a IP address (doesn’t matter what netmask) this will be always advertised in OSPF as /32. I did a little trick to be sure that they are still advertised in OSPF as presented under Loopack 1 (10.10.1.1 /24) and Loopback 2 (10.10.2.1 /24). You want to know how, check this post.

Until now, we saw how the routers are configured. Let’s have a look how the routing table appear now on this routers.
R1:

Among other routes, please notice that we receive the 2 networks from R3 each of them with a /24 prefix. Keep this in mind as it’s important for later.

R2:

On R2 we have both the EIGRP and OSPF routes, each with a /24 prefix. In some minutes we will change this. Let’s check the last router.

R3:

Here we have the 2 prefixes from EIGRP domain, again with /24.

After reviewing all the necessary information let’s apply the configuration. I will start with Area range command. For example in our case we want to advertise only one subnet from Area 1 to Area 0 in OSPF. We will combine the 2 x /24 subnets in one /22.
Why /22 and not /23? Because we have 10.10.1.0 /24 and 10.10.2.0 /24 and 10.10.1.0/23 will not be a valid prefix. Keep in mind that you have to stick to the subnetting rules. Indeed with this /22 we will “catch” also 10.10.0.0/24 and 10.10.3.0/24 in our range, but being in a test environment this is  not a problem for now. In the real world you have to take care about discontinuous networks and to apply summarization only when it’s possible.

On  our R3 router we should apply the following configuration:

R3
configure terminal
router ospf 1
area 1 range 10.10.0.0 255.255.252.0

If we check now R2, we should see:

Only one /22 subnet. IP subnet summarization is successfully taking place.

What about Summary address command? Remember that we redistribute from EIGRP into OSPF, so if you have a look about, right now in the OSPF cloud we have 2 /24 subnets imported from EIGRP domain. We want to summarize this 2 addresses in a /22 (the same reason like explained above). For this we will use the Summary address command. In short explanation, this command is only used on ASBR routers, when you want to summarize IP subnets imported from a non-OSPF domain.
On R2, we a apply the following configuration:

configure terminal
router ospf 1
summary-address 192.168.0.0 255.255.252.0

Let’s check what we receive on R1 and R3 after summarization:

We could see clear the advantage. Summary route 192.168.0.0/22 is present on R3 and again 10.10.0.0 /22 is on R1. This is the nice part and we achieved what we wanted.

Very important!
What about the blue line? That a big problem. Maybe your idea was that I did some mistake when using .1. and .2. in the third octet the subnet. It was more easier to use .0. and .1. and then I could summarize easy with /23. But I wanted to show you a hidden danger which lies beyond the summarization. Remember that I said I did just a basic redistribution  between EIGRP and OSPF? Forget that! In test environment is OK, but in real ones not. Always try to reduce the amount of redistributed subnets between 2 domains to only the necessary one using route-maps or route tagging. This should be mandatory, when redistributed summarized networks which are discontinuous.

Back to the blue line. We redistribute from EIGRP to OSPF, where we did the summarization. Due to the fact that we used 192.168.1.0/24 and 192.168.2.0/24 we had to summarize to /22, which include also the non-present subnets 192.168.0.0/24 and 192.168.3/24. Then we redistribute from OSPF to EIGRP. See the loop? EIGRP-OSPF-EIGRP. Since EIGRP see there a /22 prefix which include the 2 additional /24 subnets 192.168.0.0 and 192.168.3.0 of which R1 has no clue about, the router install this route in it’s routing table, thinking that R2 is the gateway for the 2 prefixes above. It sound complicated but I tried to simplify the explanation as much as I could. If we were using route-maps or route tagging this situation could be avoided.