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

    Hi,
    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.

    Setup:
    (local network)
    (remote network)
    192.168.0.0/16 <-> c1841-192.168.3.253/24->Inet<->vigor2200 -
    192.168.253.251<->192.168.253.0/24

    I`d be glad for help !
    tia,
    Dirk


    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
    !
    hostname ipsec-gw-100.xxx.yyy
    !
    boot-start-marker
    boot-end-marker
    !
    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 yourdomain.com
    ip name-server 194.109.6.66
    ip ddns update method sdm_ddns1
    HTTP
    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 0.0.0.0 0.0.0.0
    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
    reverse-route
    !
    !
    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 192.168.3.253 255.255.255.0
    ip nat inside
    ip virtual-reassembly
    ip tcp adjust-mss 1452
    speed auto
    half-duplex
    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
    network 192.168.3.0
    !
    ip classless
    ip default-network 192.168.3.0
    ip route 0.0.0.0 0.0.0.0 Dialer0
    ip route 192.168.1.0 255.255.255.0 192.168.3.5 permanent
    ip route 192.168.3.0 255.255.255.0 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 192.168.253.0 0.0.0.255 192.168.0.0
    0.0.255.255 log-input
    access-list 122 permit ip 192.168.0.0 0.0.255.255 192.168.253.0
    0.0.0.255 log-input
    access-list 133 deny ip 192.168.3.0 0.0.0.255 192.168.253.0 0.0.0.255
    log
    access-list 133 permit ip 192.168.3.0 0.0.0.255 any
    access-list 155 deny ip 192.168.253.0 0.0.0.255 any
    access-list 155 deny ip 192.168.0.0 0.0.255.255 192.168.253.0
    0.0.0.255 log
    access-list 155 permit ip any any
    dialer-list 1 protocol ip permit
    snmp-server community xxxxx RO
    control-plane
    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
    !
    end
     
    Dirk Westfal, Mar 13, 2006
    #1
    1. Advertising

  2. Dirk Westfal

    Dirk Westfal Guest

    Addendum:

    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
     
    Dirk Westfal, Mar 13, 2006
    #2
    1. Advertising

  3. Dirk Westfal

    Merv Guest

    Re: Addendum:

    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
    #3
  4. Re: Addendum:

    On Mon, 13 Mar 2006 11:15:14 -0800, Merv wrote:

    > 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


    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, Consultant Expert advice and a helping hand
    Networking Unlimited, Inc. for those who want to manage and
    Tenafly, NJ Phone: 201 568-7810 control their networking destiny
    http://www.networkingunlimited.com
     
    Vincent C Jones, Mar 14, 2006
    #4
  5. Dirk Westfal

    Merv Guest

    Re: Addendum:

    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 - 192.168.3.253
     
    Merv, Mar 14, 2006
    #5
  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 192.168.3.251 works fine, however
    traceroute still does not. But this may also be a problem of the peer.

    Dirk
     
    Dirk Westfal, Mar 14, 2006
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Brian Ipsen
    Replies:
    10
    Views:
    8,925
    Brian Ipsen
    Feb 25, 2004
  2. Walter Roberson
    Replies:
    0
    Views:
    562
    Walter Roberson
    Apr 1, 2004
  3. Brian H¹©

    HELP! weired problem

    Brian H¹©, Jan 2, 2004, in forum: Computer Support
    Replies:
    6
    Views:
    587
    David A. Seiver
    Jan 3, 2004
  4. Adriano
    Replies:
    1
    Views:
    963
    mark mandel
    Dec 15, 2003
  5. Fogar
    Replies:
    1
    Views:
    808
    Erick
    Jan 17, 2006
Loading...

Share This Page