1. Home
  2. Cisco Systems
  3. Weired problem with site-to-site vpn: only one side of the vpn works !?

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

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->Inetvigor2200 - 192.168.253.251192.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
Reply to
Dirk Westfal
Loading thread data ...

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

Reply to
Dirk Westfal

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

Reply to
Merv

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.
Reply to
Vincent C Jones

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

Reply to
Merv

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

Reply to
Dirk Westfal

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.