Seconadary IP Address on multiple firewalls

[bgl-group]

Our ISP has given us a secondary IP range on their internet routers. However I need to have both sets of firewalls as in the attached diagram able to use the new IP range.

I have seen some documentation which suggests adding a static route onto the router pointing at the firewalls, However I have two separate firewalls which do not talk to each other (we keep them isolated as failover protection).

Can I have some advise on how I would set this up to work properly.

(I have already asked the ISP about using Sub-Interfaces which is a non-starter as far as they are concerned)

Thanks

[Julio Carvajal]

Hello,

You could use Proxy-ARP,

Regards,

Julio

[johnlloyd_13]

hi julio/jouni,

i recently ran into a situation wherein we would need to add a new public IP range on a single ASA FW.

is there any progress on 9.x code to support the secondary IP address feature on ASA just like in IOS router?

could you give an example/explain between arp permit-nonconnected vs proxy-arp that was mentioned here on this thread?

[Jouni Forss]

Hi,

If you want to use the Secondary IP Range at the edge of the firewalls and the firewalls are ASAs then there are some things related to ARP that have to be considered.

• On ASA software 8.4(2) and below you should be able to just start configuring the Static NATs using the Secondary IP Range on the ASA firewalls as usual. The Secondary IP Range doesnt have to be a part of any directly connected network (interface)
• On ASA software 8.4(3) you would hit a limitation in ARP behaviour which would usually mean that you would have to ask the ISP to route the network towards the ASA interface IP address. In your case this would probably mean that they would have to split up the /27 subnet and route smaller parts of that subnet towards the chosen firewall based on your addressing needs. (This could be a consideration for type of implementation in itself)
• On ASA software 8.4(4.5) / 8.4(5) and above the ARP problem has been corrected and you can issue the command  "arp permit-nonconnected" to enable the ASA to populate its ARP table with IP/MAC pairs from networks that are not directly connected to the ASA. By default this setting is disabled as its considered a security risk.

I have a small section written of the above in a NAT 8.3+ document I created on the forums if you want to have a look

https://supportforums.cisco.com/docs/DOC-31116

Hope this helps

- Jouni

[bgl-group]

It happens that the firewalls are running 8.3(2.33) so in that case I should just be able to configure the static nats without any issue? So I would guess that I just need to use:

Original IP (DMZ address), Translated IP (external address on new subnet) and the firewall will just work as with the main ip range.

However we are looking to move the firewalls to a newer version of code - most probably V9 - I assume that we would need to the "arp permit-nonconnected" command adding in. Are they any other caveats for migrating from 8.3 to 9 code that could catch me out. I need to look into this before I start changing firewall rules.

Thanks

Giles

[Jouni Forss]

Hi,

It would seem to me that you could simply start using the new public IP address range in NAT statement right away.

On the newer versions you would need the "arp permit-nonconnected" command to be able to use a nonconnect network range as NAT addresses on the ASA.

It is really hard to say what risk there are in moving from 8.3 to 9.x software. I depends so much on how your firewall is configured and what functionalities you are using on them.

Most of our firewalls are in 8.4(x) software and will probably keep them that way until we get some new releases from the 9.x software. There seems to be different problems related to NAT so I am not too keen on updating several ASAs which hold 100+ Security Contexts in them. With these 8.4(x) software realeases I havent run into any major bugs yet atleast. (Though again this depends on the setup and configuration)

Then again our risk of running into a bug might be mitigated due to the fact that we have spread different functionalities to totally different ASA hardware so they are not all crammed into the same box.

I would probably read through the release notes of different software levels and look for any caveats that might apply to that you are using on the ASAs.

I guess opening a TAC case might be one solution also.

- Jouni

[Julio Carvajal]

Hello Bgl,

As I said before you could use proxy arp for this,

As Jouni mention the behavior of the ASA changes with  the newest version of the ASA.

Now on versions 8.6.1 y 8.4.3 the arp permit-nonconnected is not available so if you are going to a higher version where you will need to use proxy arp just avoid those versions,

Besides that you should go to the latest one