Re: ONE WAY PROBLEM WITH IPSEC VPN - Page 2

veltech · ‎12-11-2012

Hi All,

We posted this problem on this forum previously but still do not have a resolution to the problem despite all the excellent suggestions, so hopefully we will find the solution this time around.

We are currently experiencing a problem on an IP SEC VPN tunnel that has all of us here completely stumped. We are hoping that one of you experts out there will be able to assist. Here are some basic details:

NETWORKS

An IPSEC site to site tunnel has been built between the two sites on different networks.

PIX 515E - MAIN SITE

Network 172.16.0.0/24

CISCO 1841 - REMOTE SITE

Network 172.16.99.0/24

ISSUE

All traffic flows over the VPN from the 172.16.99.0 network in the direction of the Pix without problem, such as RDP, SIP etc. Pings will go in both directions across the tunnel. Other than the pings most traffic will NOT flow over the tunnel from the 172.16.0.0 network on the Pix to the 172.16.99.0 network on the 1841. It would appear that something on the 1841 is blocking traffic coming in over the tunnel from the 172.16.0.0 network as we can not get a wireshark capture on a PC on the 172.16.99.0 network, other than the ICMP traces. Usually this is an access list problem but we have checked and double checked the configuration and can't see anything.

TROUBLESHOOTING SO FAR

1. Have tried inserting various access list changes to the tunnel on the 1841 to make specific reference to the 172.16.0.0 network.

2. Have tried various NAT entries.

3. Have removed and then recreated the VPN tunnel from a fresh start.

4. Have made the MTU 1400 on the inside interfaces on the Pix and the 1841.

The tunnel is fully up at all times and as we say can ping in both directions.

Any help would be great.

Regards

ju_mobile · ‎12-16-2012

Hi,

If your happy to go that far then I would recommend ditching the PIX as they are EOL and upgrading to an ASA. The baby 5505 have some grunt and a recent test that I carried out proved 100Mbps on AES256 with 96Mbps throughput.

However,

Everything happens for a reason and it may be the configuration added by SDM or not. One of the earlier questions I rased was if the remote end could generate the tunnel into the Pix Do you know if this was achieveable ?

In review of your configuration on the 1841 the tunnel is matched against ACL 100

access-list 100 permit ip 172.16.99.0 0.0.0.255 172.16.0.0 0.0.0.255

access-list 100 permit ip 172.16.0.0 0.0.0.255 172.16.99.0 0.0.0.255

You may wish to remove one of those lines..

Kind Regards

Ju

Peter Koltl · ‎12-16-2012

yes, remove that line and switch to another IOS if it does not help

veltech · ‎12-28-2012

Hi Everyone,

I have spent some time in our Lab over the holiday season and would like to provide an update to this problem in the hope that someone can offer further assistance.

UPDATE

Our troubleshooting has seen us try all sorts of combination of fragmentation settings, access lists, NAT rules, and all the suggestions within this post have been tried in the Lab. We have set up two 1841 routers with the same config, or perhaps I should say mirrored configs, and we have been able to replicate the problem in both directions between router A and router B. So, it is fair to say that the Pix is working as it should and our problem is with the ISR Router configuration. Just to recap; we can ping in both directions, and all Sh Crypto outputs are normal. However, the original problem of not being able to RDP into the ISR routers still exists. Now that we have two 1841s hooked up the problem is in both directions.

Anyone have any further thoughts ???

Regards,

ju_mobile · ‎12-29-2012

Can you post your current 1841 configuration ?

Best Regards

Ju

http://helpamunky.wordpress.com/

veltech · ‎12-30-2012

Hi,

As requested here is the 1841 latest config, edited for security purposes. This has changed from the original and still pings in both directions over the tunnel, but no RDP..

1841#sh run

Building configuration...

Current configuration : 7175 bytes

!

! No configuration change since last restart

!

version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

no service password-encryption

!

hostname 1841

!

boot-start-marker

boot-end-marker

!

no logging buffered

enable secret XXXXXXXXXXXXXXXX

!

aaa new-model

!

aaa authentication login default local

aaa authorization exec default local

!

aaa session-id common

clock summer-time BST recurring last Sun Mar 2:00 last Sun Oct 2:00

ip cef

!

ip inspect name myfw cuseeme timeout 3600

ip inspect name myfw ftp timeout 3600

ip inspect name myfw rcmd timeout 3600

ip inspect name myfw realaudio timeout 3600

ip inspect name myfw smtp timeout 3600

ip inspect name myfw tftp timeout 3600

ip inspect name myfw udp timeout 15

ip inspect name myfw h323 timeout 3600

ip inspect name myfw sip

ip inspect name myfw icmp

ip inspect name myfw tcp timeout 3600

ip inspect name myfw http timeout 3600

no ip domain lookup

!

multilink bundle-name authenticated

vpdn enable

!

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

crypto isakmp key XXXXXXXXXX address <>

crypto isakmp nat keepalive 15

!

crypto ipsec transform-set MYSET esp-3des esp-sha-hmac

!

crypto map MYMAP 10 ipsec-isakmp

set peer <>

set transform-set MYSET

set pfs group2

match address 100

!

interface FastEthernet0/0

description ISP

ip address dhcp

ip access-group Internet-In in

ip inspect myfw out

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

crypto map MYMAP

!

interface FastEthernet0/1

ip address 172.16.99.1 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

!

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

ip route 172.16.0.0 255.255.255.0 <>

!

ip http server

ip http authentication local

ip http secure-server

ip nat inside source list 101 interface FastEthernet0/0 overload

!

ip access-list extended Internet-In

permit ip 172.16.0.0 0.0.0.255 any

permit udp host <> host <<1841 PUBLIC ADDRESS>> eq isakmp

permit ahp host <> host <<1841 PUBLIC ADDRESS>>

permit esp host <> host <<1841 PUBLIC ADDRESS>>

permit udp host <> host <<1841 PUBLIC ADDRESS>> eq non500-isakmp

permit tcp any any established

permit udp any any eq bootps

permit udp any any eq bootpc

permit udp any eq domain any

permit esp any any

permit udp any any eq isakmp

permit tcp any any eq 600

permit gre any any

permit udp any any eq domain

permit tcp any any eq domain

permit udp host 192.53.103.104 eq ntp any eq ntp

permit tcp any any eq 22

permit tcp any any eq 5900

permit tcp any any range 9001 9009

permit icmp any any echo-reply

permit icmp any any time-exceeded

!

access-list 100 permit ip 172.16.99.0 0.0.0.255 172.16.0.0 0.0.0.255 log

access-list 101 deny ip 172.16.99.0 0.0.0.255 172.16.0.0 0.0.0.255

access-list 101 permit ip 172.16.99.0 0.0.0.255 any

!

control-plane

!

banner login ^C

!

line con 0

XXXXXXXXXXX

logging synchronous

line aux 0

line vty 0 4

XXXXXXXXXXXXX

transport input all

!

scheduler allocate 20000 1000

ntp clock-period 17179485

ntp server 192.53.103.104

!

webvpn cef

end

ju_mobile · ‎12-30-2012

three minor recommendations:

Can you remove the route "ip route 172.16.0.0 255.255.255.0 <>" as this should not be required

Run a telnet test on 3389 to a server eg: telnet "ip address" 3389 and see if you get a response. This could indicate an MTU based issue.

Carry out a ping test with the DF bit set and see at what size it gets through..

Regards

Ju

veltech · ‎01-13-2013

Hi All,

We have now found the cause of the RDP issue over the VPN and I would like to share our results with you to try and help anyone else who finds themself with the same problem.

On the 1841 (remote site) we had set up the following NAT entry to allow RDP access over the Internet to the internal host at 172.16.99.254, which as you will recall from this thread worked OK.

ip nat inside source static tcp 172.16.99.254 9004 interface FastEthernet0/0 9004

This NAT statement seem to conflict with traffic coming into the 172.16.99.0 network over the VPN. 172.16.99.254 is the IP address of the PC we were trying to RDP into over the VPN. As soon as I removed this NAT statement I was able to RDP over the VPN using the 172.16.99.254 address. Still not exactly sure why this would have stopped the VPN traffic but that is now on my to-do-list.

Now we will figure out how to set up the remote access over the WAN.

Thank you to all who assisted.

Peter Koltl · ‎01-17-2013

I would also test it with

no ip cef

veltech · ‎02-03-2013

Hi All,

We have now concluded our Lab work with this problem and fixed all the issues.

RDP was made accessible over the VPN by removing the static NAT entry. RDP was made available over the WAN through the use of a route map configuration. We also found during testing that SIP clients trying to register to a SIP server may also have the issue with the static NAT statement if they are registering over a VPN to main site for example. A combination of static NAT and route maps will fix these issues.

Hope this is usefull and we will now upload this as a document for all to see.

Regards,

Jennifer Halim · ‎02-03-2013

Thanks for sharing the information. This will definitely be useful for others.