Hi Rick,

I can't reach either loopbacks using an extended ping.

2600#ping

Protocol [ip]:

Target IP address: 192.168.198.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: loopback1

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.198.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

Same result on the 7600.

I didn't think these loopbacks would be reachable unless they traverse the IPSEC tunnel.

Thanks.

Andy

Andy

In looking at the configs again I notice that the 2600 has ip nat outside configured on the dialer interface. Is it possible that the 2600 is translating the traffic going out that should be going through the VPN? Can you supply the detail from the 2600 about how it is doing address translation?

HTH

Rick

Andy,

Rick's correct. If you're not excluding this network from the VPN, it will get translated.

In your nat statement, try denying the traffic sourced from the local router to the remote router on both sides. That should bring your tunnels up and be able to get traffic across them.

So on your 7600:

ip nat insi sour list 105 inter dial1 exten

access-list 105 deny ip 192.168.198.0 0.0.0.255 192.168.199.0 0.0.0.255

access-list 105 permit ip 192.168.198.0 0.0.0.255 any

The 2600 would have the same thing:

access-list 105 deny ip 192.168.199.0 0.0.0.255 192.168.198.0 0.0.0.255

access-list 105 permit ip 192.168.199.0 0.0.0.255 any

I haven't seen your nat config, so I'm just using the above for reference.

*** Edit ***

You'll only need to add the nat exclusion on the 7200 if you're using nat on that device. (I'm assuming that you are.)

HTH,

John

Hi John,

Thanks for your reply.

I have added a 'deny' statement to the access list on the 2600 , but still no go.

There's no nat being done on the 7200.

See above reply to Rick for more details.

Cheers.

Andy

Hi Rick,

The 2600 is actually my home router and I have a few 192.168.x.x networks that I've vlan off. I've natted them through like so.

Eg:

interface Loopback1

description Test loopback for IPSec VPN

ip address 192.168.199.1 255.255.255.0

!

interface Ethernet0/0

no ip address

full-duplex

!

interface Ethernet0/0.9

description Server VLAN

encapsulation dot1Q 9

ip address 192.168.1.1 255.255.255.0

ip helper-address 192.168.1.254

ip nat inside

ip flow ingress

!

interface Ethernet0/0.10

description Management VLAN

encapsulation dot1Q 10

ip address 192.168.10.1 255.255.255.0

ip flow ingress

!

interface Ethernet0/0.11

description Admin VLAN

encapsulation dot1Q 11

ip address 192.168.11.1 255.255.255.0

ip helper-address 192.168.1.254

ip nat inside

ip flow ingress

!

access-list 1 deny 192.168.199.0 0.0.0.255

ip nat inside source list 1 interface Dialer0 overload

!

ip route 0.0.0.0 0.0.0.0 Dialer0

Thinking about what you said, I added a 'deny' statement to access-list 1 to prevent the loopback ip from being translated.

access-list 1 deny 192.168.199.0 0.0.0.255

access-list 1 permit 192.168.0.0 0.0.255.255

I can see matches now when I do an extended ping, but still can't reach the other end.

router1-greenvale#ping

Protocol [ip]:

Target IP address: 192.168.198.1

Repeat count [5]:

Datagram size [100]:

Timeout in seconds [2]:

Extended commands [n]: y

Source address or interface: loopback1

Type of service [0]:

Set DF bit in IP header? [no]:

Validate reply data? [no]:

Data pattern [0xABCD]:

Loose, Strict, Record, Timestamp, Verbose[none]:

Sweep range of sizes [n]:

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.198.1, timeout is 2 seconds:

Packet sent with a source address of 192.168.199.1

.....

Success rate is 0 percent (0/5)

router1-greenvale#sh access

router1-greenvale#sh access-l

router1-greenvale#sh access-lists 1

Standard IP access list 1

10 deny 192.168.199.0, wildcard bits 0.0.0.255 (5 matches)

20 permit 192.168.0.0, wildcard bits 0.0.255.255 (13 matches)

Not sure what I'm missing ??? Do you need a route to get to the other end (from network 192.168.199.0/24 to 192.168.198.0/24) or is it tunneled through the IPSEC tunnel using the public ips (202.134.236.132 to 210.15.210.83)???

2600#sh ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP

D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2

E1 - OSPF external type 1, E2 - OSPF external type 2

i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

ia - IS-IS inter area, * - candidate default, U - per-user static route

o - ODR, P - periodic downloaded static route

Gateway of last resort is 0.0.0.0 to network 0.0.0.0

C 192.168.12.0/24 is directly connected, Ethernet0/0.12

C 192.168.13.0/24 is directly connected, Ethernet0/0.13

C 192.168.14.0/24 is directly connected, Ethernet0/0.14

C 192.168.15.0/24 is directly connected, Ethernet0/0.15

202.10.80.0/32 is subnetted, 1 subnets

C 202.10.80.1 is directly connected, Dialer0

202.134.236.0/32 is subnetted, 1 subnets

C 202.134.236.132 is directly connected, Dialer0

C 192.168.10.0/24 is directly connected, Ethernet0/0.10

C 192.168.11.0/24 is directly connected, Ethernet0/0.11

C 192.168.199.0/24 is directly connected, Loopback1

C 192.168.1.0/24 is directly connected, Ethernet0/0.9

S* 0.0.0.0/0 is directly connected, Dialer0

Thanks.

Andy

Hi Guys,

Thanks for all your help. I haven't been able to work it out but it may have something to do within our internal network. I tried the ipsec config on a different sub-interface on the same 7200 and it's working - but it won't work for the original sub-interface. Not to worry, I'm just happy it's working on another sub-interface and I can do further testing.

Cheers.

Andy

Andy

I am glad that you got it to work. I am not sure why it will work on some subinterface on the 7200 and not work on the original subinterface. Perhaps there is some difference in connectivity between the subinterfaces or some different set of interface parameters that interact differently with VPN.

HTH

Rick