[AusNOG] Cisco ASA question

[Joshua Riesenweber]

Proxy ARP is disabled on software version 8.4.5 and above by default.

arp permit-nonconnected




Cheers,Josh

Date: Thu, 3 Apr 2014 15:09:24 +1000
From: colin.stubbs at equatetechnologies.com.au
To: Alex.Samad at yieldbroker.com
CC: ausnog at lists.ausnog.net
Subject: Re: [AusNOG] Cisco ASA question


Ugh. I figured you'd have that kind of topology.
You'll need to use proxy ARP in conjunction with the OSPF route to 1.2.3.129/32.


I believe even in the latest 9.x releases that's still enabled by default on ASA's so it'll probably happen without you even realising it. Make sure you understand how proxy ARP works.

Do NAT exemption for 1.2.3.129/32 and any other public IP's you push further into the network and that should work.
As mentioned in the other email, while using loopbacks for routing protocols is certainly best practice, you don't need to use a public address on them.

I'd only be doing that in your topology if R0 is not a device you control and BGP must be utilised between R0 and R2.
Otherwise, in my opinion, all you're doing by putting a public IP on there is making it easier to accidentally expose the router to the Internet when it doesn't need to be.

-Colin


On 3 April 2014 14:57, Alex Samad - Yieldbroker <Alex.Samad at yieldbroker.com> wrote:

     ++

     |R0|                                      1.2.3.254/24

     ++



   1.2.3.0/24                                    Public



+-------------------+         object nat for

       .1 & .2                                              .10,.11,.12,.13,.14

     ++                                                       etc

     |R1|

     ++



 +---------------+

     10.0.0.0/24







+-----------------+



     ++              1.2.3.129/32

     |R2|              on loopback

     ++





1.2.3.0/24 - is a public routable network

R0 is a router on 1.2.3.0/24 network

R1 is the ASA int internet is on network 1.2.3.0/24 has .1 & .2 assign to it (asa cluster), it also has the DGW via 1.2.3.254

R2 is a router inside my network and advertises 1.2.3.129/32 via OSPF, which R1 picks up on interface internal



10.0.0.0/24 is used on the internal R1 interface



so if R0 tries to send a packet to 1.2.3.129 will the ASA (R1) reply to arp requests and will it then route it internally if I use identity nat or the nat exemption some people have suggest



Thanks to Eric for the link to asci draw. I think though that outlook kills it :(



A











> -----Original Message-----

> From: Alex Samad - Yieldbroker

> Sent: Thursday, 3 April 2014 2:26 PM

> To: ausnog at lists.ausnog.net

> Subject: Cisco ASA question

>

> Hi

>

> I have a Cisco ASA question for the list.

>

> I have a 5520 (cluster)

>

> int Internet

> int internal

>

> on the internet I have my dGW to the internet, I also have my own class c,

> lets say 1.2.3.0/24

>

> I have a few object nat's defined for 1.2.3.x/24

>

> I am going to start moving the NAT function away from the ASA.

>

> I have a router inside my network with 1.2.3.129/32 on a look back interface

> and its advertised internally via OSPF. It can be seen on the ASA

>

> From my reading I believe I can get the ASA to forward and not nat for .129 if

> I use Identity NAT

>

> But I can't find any examples for mixed Object NAT and identity NAT And I

> am not sure the identity NAT will respond to ARP on the internet interface

> And I presume I have to add the right permit.

>

> I asked at the cisco forums, but the only person to respond said I couldn't do

> the /32 trick ...

>

> So I am come to the list

>

> Thanks in advance

>

> Alex

_______________________________________________

AusNOG mailing list

AusNOG at lists.ausnog.net

http://lists.ausnog.net/mailman/listinfo/ausnog




_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net
http://lists.ausnog.net/mailman/listinfo/ausnog 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20140403/d8e03fdc/attachment.html>