From: Farrukh Haroon (farrukhharoon@gmail.com)
Date: Thu Nov 15 2007 - 19:05:58 ART
Umm nevermind all, the bug is in me and not the ASA :)
I misonfigured the subnet mask on the ASA inside interface...which was
causing all this.. anyway back to the VPN :)
On Nov 16, 2007 12:28 AM, Farrukh Haroon <farrukhharoon@gmail.com> wrote:
> Dear All
>
> I am facing an issue with a task on the Internetwork Expert Security
> Workbook V3. The scenario is like this:
>
> DMZ
> ||
> Loopback0 >> R1 ----(inside)--------- ASA ----(outside)--------- R2 >>
> Loopback0
>
> R1 Loopback0: 150.1.1.1 /24
> R1 FE 0/0: 136.1.121.1 /24
> ASA Ethernet1 (inside) 136.1.121.12 /24
> ASA Ethernet0 (outside) 136.1.122.12 /24
> R2 E 0/0: 136.1.122.2 /24
> R2 Loopback0: 160.1.1.1 /24 (I changed this to troubleshoot from the
> orignal 150.1.2.0/24)
>
> The task is actually VPN related, but I'm having issues with the RIP
> (routing) part.
>
> All interfaces on all devices are participating in RIP (including the
> loopbacks on both R1 and R2). All devices are configured with RIP Version 2
> and 'no auto-summary'
>
> ASA: Version 7.2(3)
> R1 IOS: 12.4(7) ADV-ENT (same problem with 12.3(7) ADV ENT)
>
> The problem is that R2's loopback subnet is not being installed in R1.
> Whereas the loopback for R1 is properly installed on R2.
>
> I checked with a packet sniffer on both ASA interfaces (inside and
> outside), the ASA, when sending RIP updates to R2 on the outside interface
> (which would include its directly connected interfaces,and the loopback on
> R1), sets the next-hop to 0.0.0.0 in the RIP updates as seen below, which
> seems the normal way to go :
>
> ! DEBUG ON ROUTER R2
>
> **Nov 16 07:06:48.859: 150.1.1.0/24 via 0.0.0.0 in 2 hops
> ***Nov 16** 07:06:48.859: RIP-DB: network_update with 150.1.1.0/24succeeds
> ***Nov 16** 07:06:48.859: RIP-DB: adding 150.1.1.0/24 (metric 2) via
> 136.1.122.12 on
> Ethernet0/0 to RIP database*
>
> But the ASA, when sending RIP updates to R1 on its inside interfaces
> (which would include its directly connected interfaces,and the loopback on
> R2) sets the next-hop of the RIP update to the IP address of R2's ethernet
> interface ( 136.1.122.2). Is this normal behavior or a bug in the ASA
> code? As a result the update for R2's Loopback0 simply vanishes on R1. Below
> output shows ASA is sending everything to R1 as seen below ( also verified
> this with WireShark):
>
> ! DEBUG ON THE ASA
>
> RIP: sending v2 update to 224.0.0.9 via inside (136.1.121.12)
> RIP: build update entries
> 10.0.0.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 (ASA
> DMZ)
> * 136.1.122.0 255.255.255.0 via 0.0.0.0, metric 1, tag 0 (ASA
> OUTSIDE)
> 160.1.2.0 255.255.255.0 via 136.1.122.2, metric 2, tag 0 (R2
> LOOPBACK0)*
> *RIP: Update contains 3 routes*
>
> But the output on R1 reads:
>
> ! DEBUG ON R1
> RIP: received v2 update from 136.1.121.12 on FastEthernet0/0
> 10.0.0.0/24 via 0.0.0.0 in 1 hops
> 136.1.122.0/24 via 0.0.0.0 in 1 hops
> *RIP: Update contains 2 routes (Two?)*
>
> So it seems R1 simply ignores the 160.1.2.0/24 transmission from the ASA
> (even the its receiving it as verified by the packet capture)..Is this
> because of the strange next-hop set by the ASA..can someone help me with
> this please? *
>
> *Surprisingly if I do 'auto-summary' on the ASA rip process, the route for
> R2's Loopback starts showing on R1. It seems this happens because now the
> ASA starts sending 0.0.0.0 as the next-hop in its RIP updates (for R2s
> Loopback).
>
> Thanks for the help in advance :).
>
> Regards
>
> Farrukh
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:30 ART