ASA design/best practice (2 links to the same ISP)

[Rob M]

Hi,

I have 2xASA 5510 in a Active/Standby setup. The outside interface is connected through a switch to the ISP router. We are sharing a /27 subnet. We were given a new network but our ISP is not willing to statically route the new network to the next hop (our ASA's outside interface) due to an internal routing policy. One of the suggested solution is to use VLANS between our ASA (with sub-interfaces) and the ISP's router.

I wanted help/recommendation/ASA best practice on what is the best set up to tackle this issue other than using the VLAN solution. And if this is the only available solution in our case, will having outside sub-interfaces cause any issues when it comes to ASA? I know it can be really picky for traffic sourced out from one interface (sub-interface) while the return traffic is coming from another one.

Please let me know what you guys think. I am trying to limit the impact that this would cause on our live production environment.

Thanks,

[Jouni Forss]

Hi,

Are you saying that the ISP suggested that you configure 2 separate Vlans from their router all the way to your ASA for both of the public subnet assigned to you? If so I am not really sure what the ISP is thinking and what could possibly be the reason for NOT simply routing the second subnet towards the ASA.

Is there an option that the ISP would simply configure the second subnet on the current ISP Routers interface that is facing your ASA? I mean configure as a "secondary" subnet on the interface.

For example in Cisco routers

interface GigabitEthernet0/0
 description Customer ASA
 ip address 1.1.1.1 255.255.255.224
 ip address 2.2.2.0 255.255.255.224 secondary

This way you would be able to utilize both of the public subnets on your ASA. Depending on your ASAs software level it might react to the situation a bit differently. Up to 8.4(2) software you should not need any special configurations on the ASA. On software 8.4(3) there was a change related to ARP that would prevent this from working and the only option was the ISP to route the network towards the ASA. I think up from 8.4(4) or 8.4(5) you are able to use the command "arp permit-nonconnected"  which will permit the ASA to populate its ARP table with nonconnected subnet just like in this case.

If the ISP is willing to do this then you should be able to start using the new subnet as NAT IP address on the ASA as soon as the ISP has configured its side.

I don't really see the point in using 2 different WAN interface on the ASA since the ASA can only have a single active default route and it doesnt officially support Policy Based Routing (even though some NAT configurations can achieve similiar results).

Hope this helps :)

- Jouni

[Rob M]

Jouni,

Thank you for your quick and detailed answer.

Our simple request for additional public ip addresses turned out to be a possible complete network redesign or some quirky solution on the ASA,  simply not because a technical restriction, but rather a business policy on the ISP's end that they won't statically route any network to another network that is larger than /29 (we have a /27 directly connected to them).

The VLAN solution was one of 3 suggested to us by the ISP, which we refused. We don't necessarily have to go with the VLAN option. I'm trying to avoid having 2 interfaces on the ASA unless there is absolutely no other options here.

The ISP's router  that is facing our ASA is configured with secondary IP addresses (it has a /30 that is not currently in use) but I know the ASA does not support secondary IP addresses, nor PBR. I was thinking of having a default route pointing to one hop, and a more specific route (for the new network) to point to the other hop (from the new network).

At this point, I'm really just brainstorming, someone suggested adding a router between our ASA and the ISP router so we have more flexibility to manipulate traffic...but not sure how efficient this either.

The code we are using is 9.0(3).

Thanks,

[Jouni Forss]

Hi,

While the ASA does not support configuring "secondary" IP address on any interface this still does not prevent using multiple different subnet/addresses on the external interface for example.

If the solution of having multiple subnets configured on the ISP gateway interface is possible (like the /30 is now) then you could go with that.

As I said configuring the "arp permit-nonconnected" globally on the ASA and just configuring NATs using the new public subnet and having that subnet configured on the ISP gateway is enough for you to be able to utilize those 2 subnets for outbound NAT.

Or was there something preventing doing it this way?

- Jouni

[Rob M]

Thanks again.

If the ISP uses a secondary ip address for the new subnet, what should we have our end configured to? I assume vlans/sub-interfaces. But will this work without extending the vlans to their router?

But regardless on how the ISP will end up configuring their end, it looks like we will have to "break" our outside to multiple sub interfaces and then reapply all associated ACLs/NAT/Policies....etc. which is something we are trying to avoid as it may have impact on our business.

I guess the main issue here is I couldn't find any Cisco documentation (I really appreciate it if you have any) that discusses this kind of configuration (sub-interfaces/vlans) on the outside interface. I'm not sure if this is because it is not recommended/supported or for any other reason.

Do you have a link for arp permit-nonconnected command so I can read up more on it?

Thank you for your help again,

[Jouni Forss]

Hi,

As long as the ISP is willing to configure any additional public subnets allocated to you as a "secondary" network to their gateway interface (leading to your ASA) then you have to change absolutely nothing in your interface configuration.

You can leave the current subnet that is configured on the external interface there and you can simply start configuring NAT configurations using the new public subnets IP address as long as you remember to enable the "arp permit-nonconnected" command (if not enabled already).

You can check the description from the ASA Command Reference

http://www.cisco.com/c/en/us/td/docs/security/asa/asa-command-reference/A-H/cmdref1/a3.html#pgfId-1837762

The description is not really big but it essentially enabled the ASA to populate its ARP table with ARP information of subnets/addresses that are not directly connected. And normally the ASA only populates its ARP table for directly connected subnet as would any router for example.

You have no need to configure subinterfaces at all if the ISP will simply configure the second subnet to the same gateway interface that is in use at the moment.

I for example have at home an ASA5505 for testing purposes and I have 2x /29 subnets use at the same time and using this same method.

- Jouni

[Rob M]

Hi,

Thanks again for your input.

The ISP has no problem adding a secondary subnet/ip address but they won't point it to the existing one. Meaning they will need an IP address on our end from the new subnet to point the traffic to. I guess its better to put this in an example:

Existing connected network: 10.1.1.0/27 (ISP: .1 / our ASA: .2). They are currently advertising this subnet with a next hop of .2 to push the traffic destined to us to our ASA. 

Let's assume they configure a secondary range of:

New subnet 192.168.1.0/26. (ISP: .1) 

Now here is the issue, to advertise this new subnet, they will not advertise it with a next hop of 10.1.1.2 (this is against their policy). What they want is a next hop from the same subnet (for example 192.168.1.2) so they can push the traffic to.

One other solution was to replace the directly connected network (/27) with a (/30) and then they can route anything to it, no problem with that from their end. However, this of course will mean changing our public interface ip address which is something we are trying to avoid at the moment.

From ASA/Security perspective, what's your design/best practice recommendation?

Thanks,

[Jouni Forss · Accepted solution]

Hi,

I am still a bit confused about this. And I mean that there should be no problems with this setup and there ISP will not need to configure any static routes whatsoever to achieve this.

Lets take the situation where you have one subnet configured on the ISP gateway and it has the .1 IP address and you have the .2 IP address from the same subnet. In addition to the above interface configurations the ISP has ABSOLUTELY no need to configure any routes or anything pointing towards your IP address of .2. Since the ISP already has the subnet configured on its gateway interface then any traffic that needs to be forwarded to ANY other IP address belonging to that subnet (whether it was .2 or .3) will be performed by the ISP by simply sending an ARP request and the device holding that IP address (whether its configured on its interface or as a NAT IP address only) will reply to that ARP request with its MAC address. The ISP does not forward the traffic to any next hop router when its directly connected to that network.

Now lets take the example when an additional subnet is configured on the ISP gateway interface as a "secondary" subnet. The only difference in this case is that your ASA wont have any IP address configured from this subnet on its interface as ASA doesnt not support "secondary" IP addresses in its interfaces. However, if you configure a NAT using an IP address from the second subnet then the ASA will start replying to the ARP request that the ISP gateway makes for the MAC address of that NAT IP address. And when the ISP gets that ARP reply it will add the information to its ARP table and will know where to forward the traffic destined to that NAT IP. Again, it will not forward the packets to any next hop IP address but will forward the traffic according to its ARP table since the "secondary" subnet is also directly connected.

Even with the "secondary" subnet there is no additional static route configurations involved. Only thing that is done on the ISP side is that they configure the second subnet to their gateway interface with whatever IP address they want from that subnet (so that ARP requests are possible).

- Jouni

[Rob M]

I think somehow myself and our ISP managed to cause this confusion. I take the blame on this oversight on my part. You are absolutely correct here, these subnets will be advertised via the ISP as directly connected to them and since we are sharing the same interface, so its going to be a matter of an ARP rather than a route lookup. I guess I focused so much on the security/ASA part of this issue and missed the basic routing concepts.

Now that I'm done with feeling embarrassed :) I was reading up on the arp permit command and it actually might introduce some security concerns since it will basically has an ARP entry for almost anything making it very vulnerable to attacks. Any recommendation for this command? I think its going to be very hard to implement it in our environment.

Thanks

[Jouni Forss]

Hi,

I guess the risk of this command depends on how you have setup the ASA in your network.

Now considering the external interface of the ASA I would imagine that you should not have to worry about the ISP gateway device generating bogus ARP replys towards your ASA filling its ARP table. So the question is how has your ASA been setup towards your internal and possible DMZ interfaces? Is any user network directly connected to the ASA so that there is really only L2 between them? If all your internal networks are behind different routers then I would imagine the risk should be minimal/non existant.

Though there is also one other thing to consider. Before the software level 8.4(3) ASAs default behaviour was identical to the situation if you now enabled the "arp permit-nonconnected" while it might not be enough reason to enable this command now it does tell us that the ARP behaviour was like this for many many years before it was changed.

Here is a document here on CSC related to this change

https://supportforums.cisco.com/document/100896/asa-843-arp-response-behavior-change

I kinda wonder why they made this setting global rather than letting you specify the interface. For example setting this under each interface if you wanted. Would have made a lot more sense.

Naturally if the ISP was not being stubborn in your case you would not need to even enable this configuration.

But I would imagine that there probably is not that high of a risk of this causing problem unless you have LAN/DMZ networks with users/hosts directly connected to the ASA. If there is routers in between you should be safe (as the ARP messages from users would not reach the ASA at any point).

We do have multiple ASAs enabled with this with also multiple user networks connected to them and I have not faced any problems so far.

Hope this helps :)

- Jouni

[Rob M]

our inside interface is facing another internal firewall. However we do have 4 dmz (sub-interfaces, each with a /24 network) directly connected to the AZA.

So I guess your point is that if any of these hosts on the DMZs get compromised, this could potentially cause and DoS (on arp) attack?

Thanks for the above links, very interesting to read.

UPDATE:

I just noticed that we actually do have this command in our config:

no arp permit-nonconnected

[Rob M]

I also have a quick question. Is it possible that rather than enabling the permit-nonconnected command, is it possible/recommended that we can add static arp entries for these non-connected ip addresses? 

Wouldn't be more secure to hardcode the arp entries rather than letting the ASA dynamically learn then if, of course, this is even possible.

Thanks!

[Jouni Forss]

Hi,

I have not tried this myself.

If you manage the ASA and can only configure these static ARP entries on the ASA then it seems to me that without "arp permit-nonconnected" the setup simply does not work. It seems that the ASA wont reply to ARP requests for nonconnected networks without this command and the ISP gateway will never get the required ARP information to pass traffic to the ASA. Tested this in my home ASA just now.

I am not sure what the situation is if you leave the "no arp permit-nonconnected" and configure a static ARP entries on the gateway router (ISP) for all the "secondary" IP addresses pointing to the ASAs external interfaces MAC address. I guess at that point the gateway should have the required information to pass traffic to the ASA. I am not sure if there would be any problems on the ASA. Should maybe lab it at home at some point.

- Jouni