ASA5510 no ARP entry ?

[KeithN123]

I have a requirement to NAT a spare address on the same subnet range as one of the firewall interface - however, because this is not allocated to a physical interface, there is no mac entry in the arp cache. the other end of the link from the firewall is connected to a router which has no idea how to reach this "virtual address" - again because there is no entry in the arp cache

I have tried to put a static arp entry into the firewall but this doesn't appear to work either. Should I be using a mac address form a physical interface or can I create a dummy mac for this -

If the router can't see the ip address, then users will not be able to target this address - so that the firewall can NAT to the real outside address.

I have tried routes to null0 on the router and static arp entries on both devices but the user just times when trying to connect to 10.2.7.11 (nat to 10.2.32.11)

attached is a very basic visio diagram which I hope explains what I am trying to achieve.

any help would be appreciated.

many thanks

[Marvin Rhoads]

No routing or static arp cache entries should be required. Once you have a NAT rule correctly formed, the ASA will build a translation (xlate table entry) and populate its arp cache accordingly by proxy-arping for the translated address.

Can you provide your nat statement that you are using and let us know the ASA software version? (syntax is version-specific). Given that, we can hopefully then set you aright.

[KeithN123]

Hi Marvin, thanks for taking the time to look at this problem for me. I have used simple static natting for outside to inside

OSFW01# sh run static

static (inside,outside) 10.2.32.11 10.2.7.11 netmask 255.255.255.255

static (inside,outside) 10.2.32.12 10.2.7.12 netmask 255.255.255.255

operating system version is asa821-k8.bin

regards

Keith

[Marvin Rhoads · Accepted solution]

Assuming your communications are always initiated from the inside, the first static statement above should suffice. When a session is built (initial syn in the TCP 3-way handshake) the xlate table will take care of the NAT on return path. I'm not sure of the effect of the second static, but I'd try temporaily removing it.

If you ever initiate from the outside (10.2.32.11/12), you would also need an access-list to allow moving from a lower security to higher security level.

Hope this helps.

[KeithN123]

thanks again Marvin - yes we always initiate from the inside. we will test this morning -

[KeithN123]

many thanks for your help Marvin - problem now sorted.

[Marvin Rhoads]

You're welcome - that's great. Thanks for the follow-up and the rating.