One internal two external interfaces ASA5512

[Rhys Davies]

Hi

I have an ASA5512 and need to spilt traffic off a voice vlan to exit via two external interfaces (one traffic is voice and one is voice application). So I have one internal interface and two external interfaces. From the LAN I can ping the next hop after the voice external interface but I can’t ping the next hope after the voice application external interface. All NAT, firewall rules and static routes are identical for both voice and voice application. In the logs however the icmp traffic destined for the voice application network is being denied -

SRC: 10.xxx.xxx.xxx DEST: 46.xxx.xxx.xxx   Deny inbound icmp src VoiceSUB:10.xxx.xxx.xxx dst AppVRF:46.xxx.xxx.xxx (type 8, code 0)

The weird thing I think is that it’s calling the traffic ‘inbound’ when it’s outbound to the external facing interface.

I would I have thought the ASA would work out what is ‘inside’ and what is ‘outside’ from the addresses attached to the interfaces. Is there a way to tell it interface A is inside and interface B is outside? If this is in fact the issue.

Thanks

[Richard Burts]

I find part of your question confusing. When you configure interfaces on the ASA you give each interface a security level (from 0 to 100). Based on comparing the security levels the ASA determines what is inside and what is outside. Are you saying that this is not working? Perhaps posting the interface configurations might help clarify this.

The part about inbound and outbound is easier to answer. Where did the ping originate? It originated from a device outside of the ASA and was sent to the ASA for forwarding. So to the ASA the ping is inbound.

HTH

Rick

[Rhys Davies]

Thanks Rick

I’m new to Cisco and having used other firewalls which use the term ‘incoming’ for traffic coming off the cloud and ‘outgoing’ as traffic leaving the protected network so having to change my thinking. I didn’t know about the security levels so have now set the internal interface to 100.

Some more detail on what is happening: In the logs I’m seeing the ICMP connection being built for the outbound request (from LAN to next hope after ASA for voice application traffic) . Then in the next log entry the returning echo is being torn down. The reason given is: “An ICMP connection is removed from the fast-path when stateful ICMP inspection is enabled using the inspect ICMP command”

However for allowing the ping out and building the connection the reason given is: “An ICMP connection was established in the fast-path when stateful ICMP inspection was enable using the inspect ICMP command”

Bit baffled as to why the same policy is both allowing the outbound and denying the inbound.

[Richard Burts]

I am a bit confused about the terms that you use. In the original post it is clear that the ping is being denied. In this post you describe the returning echo as being torn down. That is not the same as being denied. So is the ping response being denied or is it passed through?

Without some additional information it is difficult to know what is causing this, but here is my first guess at an explanation. First is a bit of background. The ASA operates as a stateful firewall and when a host from a more trusted (higher security level interface) sends a request to a less trusted (lower security level interface) then the response should be permitted. The ASA uses inspection of ICMP as a way to create the state table entries that allow the response. So it looks to me like the second message is saying that it saw a request and is creating an entry in the state table. And my guess is that the first message is that it saw the response and tore down the entry in the state table.

If that does not match up with what you are experiencing then we will need more detail about what is happening and some parts of the configuration to help us figure out what is the issue.

HTH

Rick

[Rhys Davies]

Thanks Richard

Sorry for the lack of detail on this problem. What I had done was place the static routes on the internal network adapter. My thinking being that it would need to know to which external facing interface it had to use to route traffic it received off the internal network, when in fact the static routes needed to be placed on the external adapters. Seems backwards to me as how does the internal interface know which external interface to use to route the traffic?? But it works...

Thanks

[Richard Burts]

I am glad that you got it worked out and that the problem is solved. It seems that much of the issue has been about terminology and conceptually how Cisco does things. In terms of how Cisco forwards things the way that I remember it is that the incoming interface does not make any decision about how to forward traffic. The incoming interface just receives the packet and gives the packet to a forwarding engine which will make the decision about how to forward. The forwarding engine evaluates the entries in the routing table and selects the most appropriate route. In that perspective it makes sense that the route entry is more associated with the outbound interface than with the incoming interface.

HTH

Rick