cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2248
Views
0
Helpful
9
Replies

IPSEC for access-list mismatch

alvin1976
Level 1
Level 1

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

9 Replies 9

mheusinger
Level 10
Level 10

Hello,

did you try

Ra:

permit gre any host

Rc:

permit gre host any

Hope this helps!

Regards, Martin

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

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?

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.

the mnin u put in the permit ip any any, won't the ipsec tunnel just freeze?

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?

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

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!

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