02-14-2006 07:37 AM - edited 02-21-2020 02:15 PM
Here's the scenario: there are 3 routers, RA, RB and RC. RA is connected to RB via a IPLC serial point to point connection. RC is at a remote site with a public address. RA serial port is taking a 10.1.1.1/30 add while RB is 10.1.1.2/30 for ptp connection. RB is connected to the internet via an ATM connection with a public ip add. RB IS not managable by us but we can add in a few lines of configuration to the router. We decide to insert a static NAT within RB which will map a public address (pushed to RB via to ISP) to the serial port address of RA so that we can access RA with the statically nat public ip address (RB's do not have any access-list that will affect the connect between RC and RA). We managed to setup a tunnel between RA and RC with tunnel source and tunnel destination point at each other.
RA:
sh run interface Tunnel 0 >
Interface Tunnel 0
ip address 10.2.2.1 255.255.255.252
tunnel source 10.1.1.1
tunnel destination <public add of RC>
ip route 0.0.0.0 0.0.0.0 10.1.1.2
RC:
show run interface Tunnel 0
interface Tunnel 0
ip address 10.2.2.2 255.255.255.252
tunnel source <public of RC>
tunnel destination <public ip statically NAT at RB for connection to RA serial port>
tunnel was up and running no issue.
We wanted to run gre over ipsec in this scenario to create an encrypted tunnel between RA and RC for eigrp protocol to run. The crypto match access-list -
RA:
permit gre host 10.1.1.1 host <public add of RC>
Rc:
permit gre host <public add of RC> host <public ip statical NAT to RA>
It didn't work with debug message suggesting a mismatch in the source and destination access-list between the 2 routers. How can we solve this problem?
My next attempt, since the reason for failure is due to a mismatch access-list address, was to setup another GRE tunnel within the 1st GRE tunnel.
RA:
interface tu 10
ip address 5.5.5.1 255.255.255.252
tunnel source 10.2.2.1
tunnel destination 10.2.2.2
RC:
interface tu 10
ip address 5.5.5.2 255.255.255.252
tunnel source 10.2.2.2
tunnel destination 10.2.2.1
in doing so, my crypto match access-list will be :
RA:
permit gre host 10.2.2.1 host 10.2.2.2
RB:
permit gre host 10.2.2.2 host 10.2.2.1
Somehow, this worked for a while before the second tunnel goes down and it wun go up again. Is there anyone who can help me in this. I can take any suggestion. this tunnel over tunnel setup was a real desperate attempt. Thanks
02-14-2006 04:35 PM
Hello,
did you try
Ra:
permit gre any host
Rc:
permit gre host
Hope this helps!
Regards, Martin
02-14-2006 07:45 PM
I will give it a go this evening. Also is there any links on Cisco which i can go in to check for the debug crypto ipsec and isakmp message interpretation? This stuff that is pumped out during debug is so plentiful but I have no reference to what they mean. I happened to chance upon a third party site on the internet that have an interpretation of the crypto debug message that exactly matches mine which led me to the thinking that the it was an access-list mismatch problem. Thank you very much
02-16-2006 01:41 AM
tried the ip access-list format you have suggested, but it did not work. The message from the ipsec/isakmp debug suggest that phase 2 failed because of an invalid source ip address which is the local serial port address of RA.ANy rectification to it?
02-16-2006 08:51 AM
Maybe if you try:
access-list 101 permit ip any any
access-list 101 permit esp 10.1.1.0 0.0.0.3 10.1.1.0 0.0.0.3
access-list 101 permit ahp 10.1.1.0 0.0.0.3 10.1.1.0 0.0.0.3
access-list 101 permit udp any eq isakmp any eq isakmp
You might have to add a line for gre any any statement, unless you want to be more specific with a any host statement.
02-16-2006 10:54 AM
the mnin u put in the permit ip any any, won't the ipsec tunnel just freeze?
02-16-2006 06:08 PM
OK guys..I'm desperate..Let's strip the configuration I was trying to achieve. In the same context, what approach should I take to link up RA and RC, knowing the fact that RB is untouchable, but with a public address statically NAT to RA serial interface from RB?
02-16-2006 08:30 PM
Just an Idea why dont you look at Virtual Tunnel Interfaces both sides ?
ALso check this link discusses the scenario you are looking for
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080094bff.shtml
02-16-2006 11:01 PM
yes, did look at VTI and viewed it as the solution for it..but problem with that is, RA is a C1720 while RC is C1751-V. RA s already with the right IOS version and software to implement VTI but I couldn't find any software upgrade for the C1751-V to support VTI, unless someone points out to me which IOS version and software package. ANy other solutions i can try?thank you all!
02-17-2006 01:20 AM
Can you force the NAT transperancy in both spi mismatch and UDP Encap mode (Either of them). This is always turned on but worth a shot i would say.
crypto ipsec nat-transparency udp-encapsulation
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide