Weired problem with site-to-site vpn: only one side of the vpn works !?

Discussion in 'Cisco' started by Dirk Westfal, Mar 13, 2006.

  1. Dirk Westfal

    Dirk Westfal Guest

    i have a weired problem with a site to site setup consisting of a c1841
    with IOS 12.4(3c) on one site (local) and a cheap draytek vigor
    2200eplus on the other site (remote).

    The vpn connection is established fine, but traffic only flows from the
    remote to the local site.
    Since a traceroute from the local site to the lan address on the remote
    gets nated and routed to the internet instead the vpn tunnel, i guess
    it has something to do with the accesslists defining ipsec traffic
    (maybe i`m deadly wrong there. ...).

    I can also see some "IPSEC(epa_des_crypt): decrypted packet failed SA
    identity check" messages, when trying to conncect to something on the
    remote site, but a continous ping from remote to the local site runs
    fine, same with telnet.
    According to CCO this can result from asymetric accesslists - but i
    can`t seem to see this.

    (local network)
    (remote network) <-> c1841->Inet<->vigor2200 -<->

    I`d be glad for help !

    This is the current config on the cisco:

    #sho conf
    Using 4005 out of 196600 bytes
    version 12.4
    service timestamps debug datetime msec
    service timestamps log datetime msec
    no service password-encryption
    logging buffered 51200 warnings
    enable secret 5 $xxxxx
    enable password zzzzz

    aaa new-model
    aaa authentication login default local
    aaa authorization console
    aaa authorization exec default local
    aaa authorization network sdm_vpn_group_ml_1 local
    aaa session-id common
    resource policy
    mmi polling-interval 60
    no mmi auto-configure
    no mmi pvc
    mmi snmp-timeout 180
    ip subnet-zero
    ip cef
    ip domain name
    ip name-server
    ip ddns update method sdm_ddns1
    add http://xxxx....

    crypto pki trustpoint TP-self-signed-155xxxxx
    enrollment selfsigned
    subject-name cn=IOS-Self-Signed-Certificate-155xxxxx
    revocation-check none
    rsakeypair TP-self-signed-155xxxxx
    crypto pki certificate chain TP-self-signed-155xxxxxx
    certificate self-signed 01 nvram:IOS-Self-Sig#3901.cer
    username cisco privilege 15 secret 5 $xxxxxxxxx
    crypto logging session
    crypto isakmp policy 1
    encr 3des
    authentication pre-share
    group 2
    crypto isakmp policy 2
    encr 3des
    hash md5
    authentication pre-share
    group 2
    crypto isakmp key ZXYXZZXZ address
    crypto isakmp xauth timeout 15

    crypto ipsec transform-set fvipsec esp-3des esp-md5-hmac
    crypto ipsec df-bit clear
    crypto ipsec nat-transparency spi-matching
    crypto dynamic-map SDM_DYNMAP_1 1
    set transform-set fvipsec
    match address 122
    crypto map SDM_CMAP_1 local-address Dialer0
    crypto map SDM_CMAP_1 65535 ipsec-isakmp dynamic SDM_DYNMAP_1
    interface FastEthernet0/0
    description lan0
    ip address
    ip nat inside
    ip virtual-reassembly
    ip tcp adjust-mss 1452
    speed auto
    no mop enabled
    interface FastEthernet0/1
    description wan0
    no ip address
    duplex auto
    speed auto
    pppoe enable
    pppoe-client dial-pool-number 1
    interface Dialer0
    ip ddns update hostname ipsec-gw-100.rrr.ttt
    ip ddns update sdm_ddns1
    ip address negotiated
    ip mtu 1452
    ip nat outside
    ip nat enable
    ip virtual-reassembly
    encapsulation ppp
    dialer pool 1
    dialer-group 1
    ppp authentication chap pap callin
    ppp chap hostname xxx_deleted
    ppp chap password 0 4 xxx_deleted
    ppp pap sent-username xxx_deleted
    crypto map SDM_CMAP_1
    router rip
    redistribute static
    ip classless
    ip default-network
    ip route Dialer0
    ip route permanent
    ip route FastEthernet0/0 permanent
    ip http server
    ip http authentication local
    ip http secure-server
    ip http timeout-policy idle 5 life 86400 requests 10000
    ip nat log translations syslog
    ip nat inside source list 133 interface Dialer0 overload
    access-list 122 permit ip log-input
    access-list 122 permit ip log-input
    access-list 133 deny ip
    access-list 133 permit ip any
    access-list 155 deny ip any
    access-list 155 deny ip log
    access-list 155 permit ip any any
    dialer-list 1 protocol ip permit
    snmp-server community xxxxx RO
    banner login ^C fv gw 100 ^C
    banner motd ^C fv gw 100 ^C
    line con 0
    line aux 0
    line vty 0 4
    password zzzz
    transport input telnet ssh
    line vty 5 15
    password zzzz
    transport input telnet ssh
    Dirk Westfal, Mar 13, 2006
    1. Advertisements

  2. Dirk Westfal

    Dirk Westfal Guest

    Ok, all the time i tried from the c1841 itself.
    Now i`ve set a route to the remote router from a host connected to the
    'local' network via the c1841.
    And lo - it works :)

    Is it possible that packets generated on the cisco itself get the ip of
    the dialer interface as source address ? That would explain why the
    "interesting traffic" acls for ipsec traffic never matched ... and the
    packets never entered the tunnel.

    Now the only thing not working yet is traceroute ...

    I`m still getting some 'decrypted packet failed sa identity check'
    messages, so something`s still not quite right.

    Dirk Westfal, Mar 13, 2006
    1. Advertisements

  3. Dirk Westfal

    Merv Guest

    Packets generated on a router usually use the IP address oof the
    interface "closest" to the destination (i.e the interface out of which
    the packet will be routed
    Merv, Mar 13, 2006
  4. Generally speaking, unless explicitly overridden, packets originating from
    a Cisco router will use as a source address the primary address of the
    interface expected to be the interface used to reach the destination. This
    results in some interesting source addresses at times...two specific cases
    which I've seen in the wild:

    1 - The primary IP on an interface with secondary IP's defined will be
    used to send packets to a destination on a secondary subnetwork. If the
    destination does not have an appropriate default gateway, you can ping the
    router's secondary IP from the destination system, but can't ping the
    destination system from the router.

    2 - The interface actually used to send the packet is not the interface
    assumed when assigning the source IP address. Fairly common for syslog
    messages about links going up and down. The source IP may be down by
    the time the packet is sent.
    Vincent C Jones, Mar 14, 2006
  5. Dirk Westfal

    Merv Guest

    anytime ping or traceroute fails, try testing with extended ping and
    extended traceroute where you specify the interface or IP address to be
    used for the source IP address.
    in your case try using your 1841's FE 0/0 interface -
    Merv, Mar 14, 2006
  6. Dirk Westfal

    Dirk Westfal Guest

    Thx a lot for the responds clarifying the 'interface that is used as
    source' issue.

    Extended ping with e0 as source from works fine, however
    traceroute still does not. But this may also be a problem of the peer.

    Dirk Westfal, Mar 14, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.