03-08-2004 07:49 AM - edited 02-21-2020 01:03 PM
Hello
I have a 1760 router connected to the internet via ADSL. The other route end connects to a pc that runs a server sending packets through the router to the internet. The PC private local ip is 172.16.0.1 the router is 172.16.30.1 and the static public ip address from the ISP is x.x.x.x
I have setup a GRE tunnel to connect to another company, with IPsec as show in the configuration below
The problem i have has to do with the traffic directed through the tunnel to the internet. I want to send all packets with destination 10.20.44.* through the tunnel When i send packets from the server running in the PC behind the router, i can see packets from 172.16.0.1 to 10.20.44.1. The problem comes after i sent 2 such packets, i can no longer receive a correct answer from the sestination (10.20.44.1) i sent them.
So every time i can send just 2 packets out to the net correctly, through the tunnel with destination 10.x.x.1 and source 172.x.x.1. I have found that when i delete the ip route command that directs traffic in the tunnel0 and REAPPLY the same ip route immediatly after deleting it, i can again send just 2 more packets and receive answer, then again stops.
Also if i wait long enough (about 10minutes) after the 2 packets have been sent, i can send one more packet then stops again.
I also receive packets from them correctly, so i suspect it has to do with ipsec, since it is the only thing that gets in the way, and the tunnel works fine for the first 2 packets.
My config.
version 12.3
no aaa new-model
no ip subnet-zero
ip dhcp excluded-address 172.x.x.1
ip dhcp pool 0
network 172.x.x.x x.255.0.0
default-router 172.16.30.1
dns-server 195.x.x.x.170.2.1
ip cef
ip audit notify log
ip audit po max-events 100
ip ssh break-string
no ftp-server write-enable
no scripting tcl init
no scripting tcl encdir
crypto isakmp policy 1
hash md5
authentication pre-share
group 2
crypto isakmp key * address 195.x.x.104
crypto ipsec transform-set cm-transformset-1 esp-des esp-md5-hmac
crypto map cm-cryptomap 1 ipsec-isakmp
set peer 195.167.65.104
set transform-set cm-transformset-1
match address cosmote
interface Tunnel0
description tunnel to cosmote
ip unnumbered FastEthernet0/0
tunnel source 62.103.214.133
tunnel destination 10.x.x.11
interface ATM0/0
no ip address
no ip mroute-cache
no atm ilmi-keepalive
pvc 8/35
encapsulation aal5mux ppp dialer
dialer pool-member 1
dsl operating-mode auto
crypto map cm-cryptomap
interface FastEthernet0/0
ip address 172.16.x.x x.255.0.0
ip nat inside
speed auto
interface Dialer1
ip address negotiated
ip nat outside
encapsulation ppp
dialer pool 1
no cdp enable
ppp authentication pap callin
ppp pap sent-username ** password 0 **
ppp multilink
crypto map cm-cryptomap
!
ip nat pool ourpool 62.103.214.133 62.103.214.133 netmask 255.255.0.0
ip nat inside source route-map nonat pool ourpool overload
ip nat inside source static tcp 172.16.0.1 7393 62.103.214.133 7393 extendable
ip classless
ip route 0.0.0.0 0.0.0.0 Dialer1
ip route 10.20.44.0 255.255.255.0 Tunnel0
ip access-list extended cosmote
permit ip host 62.103.214.133 host 10.20.2.11
access-list 175 deny ip 172.16.0.0 0.0.255.255 10.20.0.0 0.0.255.255
access-list 175 permit ip 172.16.0.0 0.0.255.255 any
access-list 175 deny ip 172.16.0.0 0.0.25.255 195.167.0.0 0.0.255.255
!
route-map nonat permit 10
match ip address 175
end
Thanks a lot
03-15-2004 03:51 AM
Everything looks fine for me. any update on this ?
03-15-2004 07:15 AM
Well the problem is still unresolved.
I have found some more things though. When i shut the tunnel and turn it on i can send 2 packets, and get answer. Then the rest are problematic.
When i CAN send and receive, the debug at the other end i try to communicate sees the IPsec first, then the GRE and then the inside packet from 172.16.0.1 to 10.20.44.1. When i CAN'T send anymore, the debugger on the other end sees packets with IPsec, then GRE and after opening GRE sees AGAIN IPsec packet with source 62.103.214.144 and destination 195.167.65.104 instead of the inside network packets from 172.16.0.1 to 10.20.44.1.
What i want is NOT to encrypt the inside packet of the GRE, but the gre itself only. This is the problem mainly.
I have tryed to put gre instead of ip in the ipsec access-list "extended cosmote" but the connection fails completly either side. I have tryed to DENY the source 172.16.0.1 and destination 10.20.44.1 and does not work.
How can i prevent the packets from FastEthernet0/0 beeing encrypted ??? I suspect the ip route command directing the data through the tunnel tells the router to encrypt that data automatically. But why the access-list does not work?
Thanks again
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: