cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
680
Views
0
Helpful
6
Replies

IPSEC VTI and WINDOWS DOMAIN PROBLEM

kwillacey
Level 3
Level 3

I configured IPSEC VTIs between branch locations and a head office but whenever the tunnels are up machines on the domain at the branches are unable to come up and get an IP address they are stuck in preparing network connections once the tunnel is down they work fine. Also if the tunnel is up and the machine is not apart of the domain it will get an IP address and will be able to work as it should.

The routers were using advanced security 12.4 15 T7 but it seems that has some issues, none that I have seen that are specific to VPNS, so I have upgraded all locations to 12.4 22 T but I have not been able to test it yet.

The router config is pretty simple it's just the interfaces the tunnel and routing nothing fancy. Is there anything that you guys can think of that could be the problem? It would really be appreciated.

HO

--

crypto isakmp policy 10

encr 3des

hash sha

authentication pre-share

group 2

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

crypto isakmp keepalive 10

crypto ipsec transform-set RBL-TSET esp-3des esp-sha-hmac

crypto ipsec profile RBL-PROFILE

set transform-set RBL-TSET

interface Tunnel0

ip unnumbered vlan 2

ip ospf cost 40

tunnel source Serial0/2/0.100

tunnel destination 10.161.2.2

tunnel mode ipsec ipv4

tunnel protection ipsec profile RBL-PROFILE

Branch

------

crypto isakmp policy 10

encr 3des

hash sha

authentication pre-share

group 2

crypto isakmp key cisco address 10.161.2.1

crypto isakmp keepalive 10

crypto ipsec transform-set RBL-TSET esp-3des esp-sha-hmac

crypto ipsec profile RBL-PROFILE

set transform-set RBL-TSET

interface Tunnel0

ip unnumbered f0/0.20

ip ospf cost 40

tunnel source s0/0/0.100

tunnel destination 10.161.2.1

tunnel mode ipsec ipv4

tunnel protection ipsec profile RBL-PROFILE

6 Replies 6

Ivan Martinon
Level 7
Level 7

Do these computers have to contact the DC across the tunnel? If you ping from that computer to the DC with a packet size of 2048 bytes, do you get replies?

The DHCP server is at the HO and this problem only occurs with the atm links, the metro links and frame links that other branches use to get to the HO are fine. So I did a little research and it turns out it has to do with the MSS. I adjusted it to 1330 so that we were actually able to get to the machines and log on locallay but whenever they try to come across the link for domain information I suppose they just cant get on.

Any idea what the MSS should be on the tunnels when using shdsl links?

Setting MSS value forces TCP traffic through the interface that has that value to adjust the MSS to what you configure it is known that Domain traffic tends to be large packets so forcing the MSS to be lower than the default (1460) forces the TCP speakers to send traffic with less TCP MSS and fragment when needed.

It's said that if it's too low it affects throughput but I suppose I am going to have to go lower than the 1330 I had set it at. Any recommendations?

I would go with 1400 of ip mtu on the tunnel interface and 1300 on mss on the same tunnel interface, but you can play with the mss to lower values, up to 1100 which is the lowest safe I've used.

Ok thanks very much, I'll give that a try.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: