Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

ONE WAY PROBLEM WITH IPSEC VPN

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

Can you pls share the configuration from both sides.

Do you have any interface access-list applied on the PIX that might be preventing the outbound access to those remote LAN?

Also, on the router, do you have any ACL that might be preventing inbound access as well from the PIX subnet?

Hi Jennifer,

Here are the configs which we have edited a little to reduce the size and removed sensitive information.

We do not have any ACLs blocking the traffic on Pix or 1841 as far as we know. Pings work in both directions, but no other data will flow from Pix to 1841.

Thanks for your help with this one.

PIX CONFIG

==============================================================

Pix# sh run

: Saved

:

PIX Version 8.0(4)

!

hostname Pix

domain-name Pix.net

names

!

interface Ethernet0

nameif Outside

security-level 0

ip address pppoe setroute

!

interface Ethernet1

nameif Inside

security-level 100

ip address 172.16.0.222 255.255.255.0

!

interface Ethernet2

shutdown

no nameif

no security-level

no ip address

!

ftp mode passive

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

dns server-group DefaultDNS

domain-name Pix.net

same-security-traffic permit intra-interface

object-group service support_tcp tcp

port-object eq ssh

access-list Inside_In extended permit ip 172.16.0.0 255.255.255.0 any

access-list XXXXXX_splitTunnelAcl standard permit 172.16.0.0 255.255.255.0

access-list Inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 192.168.27.0 255.255.255.224

access-list Inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 172.16.23.0 255.255.255.0

access-list Inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 192.168.111.0 255.255.255.0

access-list Inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 192.168.12.0 255.255.255.224

access-list Inside_nat0_outbound extended permit ip 172.16.0.0 255.255.255.0 172.16.99.0 255.255.255.0

access-list Outside_1_cryptomap extended permit ip 172.16.0.0 255.255.255.0 172.16.23.0 255.255.255.0

access-list Outside_2_cryptomap extended permit ip 172.16.0.0 255.255.255.0 192.168.111.0 255.255.255.0

access-list Outside_3_cryptomap extended permit ip 172.16.0.0 255.255.255.0 172.16.99.0 255.255.255.0

pager lines 24

logging enable

logging asdm informational

mtu Outside 1492

mtu Inside 1492

ip local pool RVPN_POOL1 192.168.27.10-192.168.27.20 mask 255.255.255.0

ip local pool RVPN_POOL2 192.168.12.10-192.168.12.20 mask 255.255.255.0

icmp unreachable rate-limit 1 burst-size 1

icmp deny any echo Outside

icmp permit any echo-reply Outside

asdm image flash:/asdm-615.bin

no asdm history enable

arp timeout 14400

nat-control

global (Outside) 101 interface

nat (Outside) 101 192.168.12.0 255.255.255.0

nat (Inside) 0 access-list Inside_nat0_outbound

nat (Inside) 101 0.0.0.0 0.0.0.0

access-group Outside_In in interface Outside

access-group Inside_In in interface Inside

dynamic-access-policy-record DfltAccessPolicy

aaa authentication enable console LOCAL

aaa authentication ssh console LOCAL

aaa authentication telnet console LOCAL

http server enable

http 172.16.23.0 255.255.255.0 Inside

http 172.16.0.0 255.255.255.0 Inside

http 192.168.12.0 255.255.255.0 Inside

http 192.168.27.0 255.255.255.0 Inside

http 172.16.99.0 255.255.255.0 Inside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart

crypto ipsec transform-set ESP-AES-256-MD5 esp-aes-256 esp-md5-hmac

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac

crypto ipsec transform-set ESP-DES-MD5 esp-des esp-md5-hmac

crypto ipsec transform-set ESP-AES-192-MD5 esp-aes-192 esp-md5-hmac

crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac

crypto ipsec transform-set ESP-AES-256-SHA esp-aes-256 esp-sha-hmac

crypto ipsec transform-set ESP-AES-128-SHA esp-aes esp-sha-hmac

crypto ipsec transform-set ESP-AES-192-SHA esp-aes-192 esp-sha-hmac

crypto ipsec transform-set ESP-AES-128-MD5 esp-aes esp-md5-hmac

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set pfs group1

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set security-association lifetime seconds 28800

crypto dynamic-map SYSTEM_DEFAULT_CRYPTO_MAP 65535 set security-association lifetime kilobytes 4608000

crypto dynamic-map RVPN02_CRYPTO_MAP 65535 set pfs group1

crypto dynamic-map RVPN02_CRYPTO_MAP 65535 set transform-set ESP-AES-128-SHA ESP-AES-128-MD5 ESP-AES-192-SHA ESP-AES-192-MD5 ESP-AES-256-SHA ESP-AES-256-MD5 ESP-3DES-SHA ESP-3DES-MD5 ESP-DES-SHA ESP-DES-MD5

crypto dynamic-map RVPN02_CRYPTO_MAP 65535 set security-association lifetime seconds 28800

crypto dynamic-map RVPN02_CRYPTO_MAP 65535 set security-association lifetime kilobytes 4608000

crypto map Outside_map 1 match address Outside_1_cryptomap

crypto map Outside_map 1 set pfs

crypto map Outside_map 1 set peer XX.XX.XX.XX

crypto map Outside_map 1 set transform-set ESP-3DES-SHA

crypto map Outside_map 1 set security-association lifetime seconds 28800

crypto map Outside_map 1 set security-association lifetime kilobytes 4608000

crypto map Outside_map 2 match address Outside_2_cryptomap

crypto map Outside_map 2 set pfs

crypto map Outside_map 2 set peer XX.XX.XX.XX

crypto map Outside_map 2 set transform-set ESP-3DES-SHA

crypto map Outside_map 2 set security-association lifetime seconds 28800

crypto map Outside_map 2 set security-association lifetime kilobytes 4608000

crypto map Outside_map 3 match address Outside_3_cryptomap

crypto map Outside_map 3 set pfs

crypto map Outside_map 3 set peer <<IP ADDRESS OF 1841 AT REMOTE SITE>>

crypto map Outside_map 3 set transform-set ESP-3DES-SHA

crypto map Outside_map 3 set security-association lifetime seconds 28800

crypto map Outside_map 3 set security-association lifetime kilobytes 4608000

crypto map Outside_map 65535 ipsec-isakmp dynamic RVPN02_CRYPTO_MAP

crypto map Outside_map interface Outside

crypto isakmp enable Outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

telnet 172.16.0.0 255.255.255.0 Inside

telnet timeout 20

ssh 0.0.0.0 0.0.0.0 Outside

ssh 172.16.0.0 255.255.255.0 Inside

ssh 192.168.27.0 255.255.255.224 Inside

ssh 172.16.23.0 255.255.255.0 Inside

ssh 192.168.12.0 255.255.255.0 Inside

ssh timeout 20

console timeout 0

management-access Inside

vpdn group XXXXXXX request dialout pppoe

vpdn group XXXXXXX localname XXXXXXXXXX

vpdn group XXXXXXX ppp authentication chap

vpdn username XXXXXXXXX password XXXXXXXX store-local

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

ntp server 192.53.103.104

tftp-server Inside 172.16.0.152 C:\TFTP-Root

group-policy XXXXXXX internal

group-policy XXXXXXX attributes

wins-server value 172.16.0.1

dns-server value 172.16.0.1

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelall

default-domain value XXXXXXX

group-policy XXXXXX internal

group-policy XXXXXX attributes

wins-server value 172.16.0.1

dns-server value 172.16.0.1

vpn-tunnel-protocol IPSec

split-tunnel-policy tunnelspecified

split-tunnel-network-list value XXXXX_splitTunnelAcl

default-domain value XXXXXXX

username XXXXX password XXXXXX encrypted privilege 15

username XXXXX password XXXXXX encrypted privilege 15

tunnel-group XXXXXX type remote-access

tunnel-group XXXXXX general-attributes

address-pool RVPN_POOL1

default-group-policy XXXXXX

tunnel-group XXXXXX ipsec-attributes

pre-shared-key

tunnel-group XX.XX.XX.XX type ipsec-l2l

tunnel-group XX.XX.XX.XX ipsec-attributes

pre-shared-key

tunnel-group <<IP ADDRESS OF 1841>> type ipsec-l2l

tunnel-group  <<IP ADDRESS OF 1841>> ipsec-attributes

pre-shared-key

tunnel-group XXXXXXXX type remote-access

tunnel-group XXXXXXXX general-attributes

address-pool RVPN_POOL2

default-group-policy XXXXXXX

tunnel-group XXXXXXX ipsec-attributes

pre-shared-key

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect esmtp

  inspect sqlnet

  inspect skinny

  inspect sunrpc

  inspect xdmcp

  inspect sip

  inspect netbios

  inspect tftp

  inspect dns preset_dns_map

  inspect http

  inspect ctiqbe

  inspect icmp

!

service-policy global_policy global

prompt hostname context

Cryptochecksum:

: end

=========================================================================

CONFIG OF 1841

1841#sh run

Building configuration...

Current configuration : 8662 bytes

!

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

!

logging message-counter syslog

no logging buffered

!

aaa new-model

!

!

aaa authentication login default local

aaa authentication login ciscocp_vpn_xauth_ml_1 local

aaa authentication login ciscocp_vpn_xauth_ml_2 local

aaa authorization exec default local

aaa authorization network ciscocp_vpn_group_ml_1 local

aaa authorization network ciscocp_vpn_group_ml_2 local

!

!

aaa session-id common

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

dot11 syslog

ip source-route

!

!

!

!

ip cef

no ip domain lookup

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 ipv6 cef

!

multilink bundle-name authenticated

!

vpdn enable

!

!

!

archive

log config

  hidekeys

!

!

crypto isakmp policy 1

encr 3des

authentication pre-share

group 2

crypto isakmp key XXXXXXX address <<PUBLIC IP ADDRESS OF PIX>>

!

crypto isakmp client configuration group XXXXXXX

key XXXXXXXXXXX

dns 208.67.220.220 208.67.222.222

pool SDM_POOL_1

max-users 3

netmask 255.255.255.0

crypto isakmp profile ciscocp-ike-profile-1

   match identity group XXXXXXXX

   client authentication list ciscocp_vpn_xauth_ml_2

   isakmp authorization list ciscocp_vpn_group_ml_2

   client configuration address respond

   virtual-template 2

!

!

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec transform-set ESP-3DES-SHA1 esp-3des esp-sha-hmac

!

crypto ipsec profile CiscoCP_Profile1

set transform-set ESP-3DES-SHA

set isakmp-profile ciscocp-ike-profile-1

!

!

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to <<PIX>>

set peer <<PUBLIC IP ADDRESS OF PIX>>

set transform-set ESP-3DES-SHA1

set pfs group2

match address 100

!

crypto ctcp

!

!

interface FastEthernet0/0

description ISP

ip address dhcp

ip access-group Internet-In in

ip nat outside

ip inspect myfw out

ip virtual-reassembly

duplex auto

speed auto

crypto map SDM_CMAP_1

!

interface FastEthernet0/1

ip address 172.16.99.1 255.255.255.0

ip nat inside

ip virtual-reassembly

duplex auto

speed auto

!

interface Virtual-Template2 type tunnel

ip unnumbered FastEthernet0/0

tunnel mode ipsec ipv4

tunnel protection ipsec profile CiscoCP_Profile1

!

ip local pool SDM_POOL_1 192.168.27.10 192.168.27.20

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

ip http server

ip http authentication local

ip http secure-server

!

!

ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0/0 overload

ip nat inside source route-map SDM_RMAP_2 interface FastEthernet0/0 overload

!

ip access-list extended Internet-In

permit tcp host <<PUBLIC IP ADDRESS OF PIX>> any

permit udp host <<PUBLIC IP ADDRESS OF PIX>> any

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 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 icmp any any echo-reply

permit icmp any any time-exceeded

!

access-list 1 remark CCP_ACL Category=16

access-list 1 permit 172.16.0.0 0.0.0.255

access-list 10 remark CCP_ACL Category=16

access-list 10 permit 172.16.99.0 0.0.0.255

access-list 100 remark CCP_ACL Category=4

access-list 100 remark IPSec Rule

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

access-list 101 remark CCP_ACL Category=2

access-list 101 deny   ip 172.16.0.0 0.0.0.255 172.16.99.0 0.0.0.255

access-list 101 remark IPSec Rule

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.0.0 0.0.0.255 any

access-list 102 remark CCP_ACL Category=2

access-list 102 deny   ip 172.16.0.0 0.0.0.255 172.16.99.0 0.0.0.255

access-list 102 remark IPSec Rule

access-list 102 deny   ip 172.16.99.0 0.0.0.255 172.16.0.0 0.0.0.255

access-list 102 permit ip 172.16.99.0 0.0.0.255 any

!

!

!

!

route-map SDM_RMAP_1 permit 1

match ip address 101

!

route-map SDM_RMAP_2 permit 1

match ip address 102

!

!

!

!

control-plane

!

!

transport input all

!

scheduler allocate 20000 1000

ntp server 192.53.103.104

end

Any chance to make below changes and give a try. Also try by removing "ip inspect myfw out"

and "ip access-group Internet-In in" from the fastethernet0/0 of router.Dont forget to put back the commands after testing.

no ip nat inside source route-map SDM_RMAP_2 interface FastEthernet0/0 overload

no access-list 101

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

With Regards,

Safwan

Don't forget to rate helpful posts

The PIX inside_in ACL that you listed above only have the permit statement. Just double checking that there is no "deny" statement above that permit statement that might be blocking the traffic, right?

Also, the inside host that you are testing from, just confirming again that the subnet mask is 255.255.255.0 not 255.255.0.0.

Where is the traffic failing? Are you able to test telnet on a specific port, and run packet capture on the PIX and see if there is anything hitting the PIX.

Hi All,

Thank you for the input again, here are our answers to the various questions raised.

We tried removing the ip inspect myfw and the access group, no luck.

There are no deny statements on either the Pix or the 1841. The subnet mask in both networks is 255.255.255.0

The traffic is failing inbound to the 1841. Traffic flowing into the Pix is all fine. For example we can not run an RDP session inbound to 172.16.99.0/24 network on the 1841 or get a SIP client to register from a remote network over the VPN. As we have said all traffic flows fine inbound to the Pix.

Telnet and SSH will work over the VPN to the 1841 on the 172.16.99.0/24 network, which shows some traffic is getting accross the VPN, as are the pings we are sending. We have opened up the ports for RDP and SIP on the 1841 so dont think the issue is with the ACLs.

Any further thoughts?

Regards,


I'd recommend following safus advice and removing the int acl in. The acl identifies that potentially sysopt is not enabled and will also help to debug the underlying connection.

Best Regards

Ju
Sent from Cisco Technical Support iPad App

Have you enabled logging on both devices?

Enable logging to a debugging level locally or to a remote syslog server and check the output when you ping successfully and when you try an RDP session.

The logs might give an indication of why the flow is failing.

Just to go back to your MTU settings

I can't see from your 1841 config where you have set the MTU to 1400?

To be sure i'd configure ip tcp-adjust mss 1360 on Fa0/1 and ip mtu 1400 on Fa0/0

Can you also check your default system options on your Pix

sh run all | i sysopt

Make sure it's set to the default MSS of 1380

Hi Scott,

We have run a number of debug sessions and found nothing. We also set MTUs to the lower values on both the 1841 and the Pix. Just to clarify it is traffic in the direction of the 1841 that is causing the issue. All traffic to the Pix is fine.

Anymore suggestions???

Thanks,

Looks like you have a tough problem.

There is one more thing to try.

Some applications use the DF bit on the packet what means, "Don't Fragment"

It tells whatever device is routing the traffic that this packet can't be fragmented. So If the router, (ASA, etc) get's the packet, it has the DF bit=1 and the packet can't "fit" on the next network segment the device drops the packet.

The solution for that on vpn is using:

crypto ipsec df-bit clear-df [interface]

So if the DF bit = 1, the device will clear it and fragment it regardless the application claim.

Please rate if it help you.

Ps. I didn't look at any of the other configuration, I'm just assuming with all the ppl that already looked it must be something tricky, not trivial.

PIX:

show crypto ipsec sa peer x.x.x.x

     watch the encrypt and decrypt counters

show conn detail long | i 172.16.99.

1841:

show crypto ipsec sa peer x.x.x.x

     watch the encrypt and decrypt counters

this way you can determine whether the packets enter the tunnel and whether they are received from the tunnel on 1841

Hi All,

Thank you all for your input we have tried the various suggestions but still have the issue.

I thought it might be helpful to include the results of the "sh crypto ipsec sa" which we ran on the 1841 whilst trying to run an RDP session over the VPN into the 1841. The Pix is absolutely fine, but the enclosed script taken from the 1841 does show some odd things that might point to an issue, the question is what's the issue..... For example the results seem to show two blocks of test results with the first set showing no packets encap or de encap. I can't remember if that is correct on an ISR but the Pix shows only one set of results which are normal. We have tried a whole range of MTU configs taking into account the IPSEC overhead in the tunnel, but none of these configs solved the problem.

This test was run with an RDP session originated on the Pix network to the 1841 network over the VPN. As can be seen we can see the packets increasing over the VPN suggesting that the RDP packets are making it over the VPN but something strange is happening thereafter.

Any help greatly appreciated.

=========================================================================================

1841#sh crypto ipsec sa

     PFS (Y/N): N, DH group: none

     PFS (Y/N): Y, DH group: group2

interface: FastEthernet0/0

    Crypto map tag: SDM_CMAP_1, local addr <<PUBLIC IP ADDRESS OF 1841>>

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (172.16.99.0/255.255.255.0/0/0)

   current_peer <<IP ADDRESS OF PIX>> port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0

    #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 0, #recv errors 0

     local crypto endpt.: <<PUBLIC IP ADDRESS OF 1841>>, remote crypto endpt.: <<PUBLIC IP ADDRESS OF PIX>>

     path mtu 1200, ip mtu 1200, ip mtu idb FastEthernet0/0

     current outbound spi: 0x0(0)

     inbound esp sas:

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

     outbound ah sas:

     outbound pcp sas:

   protected vrf: (none)

   local  ident (addr/mask/prot/port): (172.16.99.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/0/0)

   current_peer <<PUBLIC IP ADDRESS OF PIX>> port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 32, #pkts encrypt: 32, #pkts digest: 32

    #pkts decaps: 35, #pkts decrypt: 35, #pkts verify: 35

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 1, #recv errors 0

     local crypto endpt.: <<PUBLIC IP ADDRESS OF 1841>>, remote crypto endpt.: <<PUBLIC IP ADDRESS OF PIX>>

     path mtu 1200, ip mtu 1200, ip mtu idb FastEthernet0/0

     current outbound spi: 0x3A3881C5(976781765)

     inbound esp sas:

      spi: 0x12C8B13C(315142460)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 2009, flow_id: FPGA:9, sibling_flags 80000046, crypto map: SDM_CMAP_1

        sa timing: remaining key lifetime (k/sec): (4523236/3563)

        IV size: 8 bytes

        replay detection support: Y

        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:

      spi: 0x3A3881C5(976781765)

        transform: esp-3des esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 2010, flow_id: FPGA:10, sibling_flags 80000046, crypto map: SDM_CMAP_1

        sa timing: remaining key lifetime (k/sec): (4523236/3563)

        IV size: 8 bytes

        replay detection support: Y

        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:

Hi,

Looking at your logg above on the same device gets a little confusing as the proxy addresses are normal and then reversed. In review of your PIX I also was not sure what purpose the split-tunneling was defined for.

Output from log:

  local  ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (172.16.99.0/255.255.255.0/0/0)


  local  ident (addr/mask/prot/port): (172.16.99.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (172.16.0.0/255.255.255.0/0/0)

I'd look at your split tunnel and NAT at both ends..

Best Regards

Ju

Hi,

The split tunnel is set up on the Pix for a remote VPN used by remote users on mainly iphones. The Pix has two remote VPNs one with hairpining set up. The 1841 logg is confusing and we are also not sure why we are seeing two entries and the addresses as you say are reversed. We also feel this could be a NAT issue but the config for NAT is fairly straight forward and we can't see anything obvious in the config on the 1841.

The 1841 VPN was configured through CCP and this often puts extra config that can make trouble shooting a little harder. We are considering erasing the entire config on the 1841 and starting from the ground up using CLI, but first we will look at the NAT.

regards,

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

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

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,

Can you post your current 1841 configuration ?

Best Regards

Ju

http://helpamunky.wordpress.com/

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 <<PIX PUBLIC ADDRESS>>

crypto isakmp nat keepalive 15

!

!

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

!

crypto map MYMAP 10 ipsec-isakmp

set peer <<PIX PUBLIC ADDRESS>>

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 <<PIX PUBLIC ADDRESS>>

!

!

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 <<PIX PUBLIC ADDRESS>> host <<1841 PUBLIC ADDRESS>> eq isakmp

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

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

permit udp host <<PIX PUBLIC ADDRESS>> 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

three minor recommendations:

Can you remove the route "ip route 172.16.0.0 255.255.255.0 <<PIX PUBLIC ADDRESS>>" 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

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.

I would also test it with

  no ip cef

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,

This document was generated from the following discussion: ONE WAY PROBLEM WITH IPSEC VPN

Version history
Revision #:
1 of 1
Last update:
‎02-03-2013 06:13 AM
Updated by:
 
Labels (1)