Intra-interface traffic failing

Unanswered Question
Jan 7th, 2009

I'm having a problem with traffic traversing the ASA on the same interface. I'll explain my configuration/setup, and then the symptoms.

I have configured my ASA 5505 with the inside interface having an IP on the internal data VLAN (VLAN 1, security level 100). It is the data VLAN's default gateway. EIGRP has populated the routing table of the ASA with the ISR that routes traffic to and from the Voice VLAN (the ISR has one interface IP on the Data VLAN and another on the Voice VLAN). I've allowed intra-interface routing on the ASA with the "same-security-traffic permit intra-interface" command, exempted NAT between the two networks on the inbound interface and setup an access rule allowing both networks access to one another.

The result is as follows:

Voice VLAN devices are able to access any resource on the data VLAN successfully. However, only ICMP works when devices on the data VLAN try to access a resource on the Voice VLAN: when I try to use telnet or http, the TCP sequence is as follows (according the Wireshark):

1. Data device sends SYN frame to Voice device. This is sent to the ASA (TCP connection built and permitted)

2. ASA forwards frame to the ISR.

3. Voice device receives the SYN and responds with SYN/ACK. This is sent to the ISR.

4. Because the ISR has an interface on the data VLAN, it is forwarded to the Data device.

5. Data device receives an ACK, but is convinced that this is an ACK for a lost segment.

6. RST sent from Data device to Voice device.

7. ASA successfully tears-down the connection due to RESET-O flag.

8. Voice device receives RST and sends SYN/ACK.

9. Data device receives SYN/ACK successfully.

I have ran this through the ASA's Packet Tracer for ICMP, TCP23 and TCP80, and it is successful each time.

What am I missing here?


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
clark-computers Wed, 01/07/2009 - 05:55

IPs and names have been changed:

Permit ACL:

name net_Data-LAN

name net_Voice-LAN


object-group network Grp_Internal-networks

network-object net_Data-LAN

network-object net_Voice-LAN


access-list inside_access_in extended permit ip object-group Grp_Internal-networks object-group Grp_Internal-networks log


access-list inside_nat0_outbound extended permit ip object-group Grp_Internal-networks object-group Grp_Internal-networks


nat (inside) 0 access-list inside_nat0_outbound outside

Hope this helps...

clark-computers Thu, 01/08/2009 - 02:35


I removed my NAT statement and replaced it with the two statements that you specified.

The problem remains and the symptoms are exactly the same.


clark-computers Thu, 01/08/2009 - 08:49

1) Yes.

2) The other router is a ISR voice gateway. It only routers traffic to/from the voice LAN and Unity (as well as running CUCME). The data devices use the ASA as their default gateway.


clark-computers Fri, 01/09/2009 - 01:55

Yes it does, and the proof is that ICMP packets are working correctly: devices on both networks can ping each other and traceroutes are correct.

The problem comes when trying to use some other IP type to access devices on the voice network from the data network.

try adding:-

access-list inside_access_in extended permit ip object-group net_Data-LAN object-group net_Voice-LAN log

access-list inside_access_in extended permit ip object-group net_Voice-LAN object-group net_Data-LAN log

access-list inside_access_in extended deny ip any any log

Then test again - and check the logs.


clark-computers Fri, 01/09/2009 - 03:12

Sorry mate, I'm afraid it's exactly the same!

I tried a telnet from a data device to a voice device and the ASA reports that:

1. The traffic matches a permit access-list (the one in your last post) from Data device to Voice device (both on inside interface).

2. Builds inbound TCP connection from Data to Voice (both on inside).

3. Immediately tears-down the TCP connection with the reason 'Reset-O'.

4. Denies TCP (no connection) from Data to Voice with with RST flag on inside interface.

The Data device tries to connect three times before failing. The source port on each attempt is the same and the TCP connection ID on each attempt is different.


clark-computers Fri, 01/09/2009 - 03:37

The ASA version is asa804-k8.bin with the Security Plus license.

Is your forum username also your email address?


clark-computers Fri, 01/09/2009 - 03:53

From your message above:

2) If you have an internal router that is a neighbour of the ASA - then why is that device not doing the routing?

I have spoken to my infrastructure manager and making the change to do internal routing through the ISR is acceptible to him. I have tested it and it resolves this issue. Would you still like to setup the lab, or are you happy for me to resolve this thread?

crisco_bill Tue, 01/27/2009 - 20:19

Sorry to jump in, but did you ever find a solution? I have the exact same problem with an ASA 5505 in the same type of layout.

Pings work perfectly, but not TCP traffic. TCP fails with the same reset-o.

In my case, unlike Stu, I can't make any changes to the neighbor router (it's locked down by a vendor and they won't make changes).

So if a solution exists, I would be very grateful.

crisco_bill Wed, 01/28/2009 - 07:21

Here you go (sorry for the lack of visio). I've also attached a tcpdump showing successful ping and unsuccessful TCP.

As is, both computers can ping each other without problems. But any TCP connection between computers will fail.

I did some network sniffing from the computers and the ASA 5505:

1. When the computer sends a ping to, the packet gets sent to the ASA. The ASA then forwards it to the router. The router then sends it out the interface to the computer.

The computer replies to the ping, sending its reply to the router at The router then sends it out the interface to the computer.

The ASA does not see the return traffic from to, but that doesn't matter.

2. For TCP connections from the computer to the computer, the same pathway is used, but the SYN/SYN-ACK/ACK isn't established.

The SYN is sent from the computer to the ASA 5505, which then forwards to the router, which then forwards to the computer, which then replies.

But the SYN/SYN-ACK/ACK is getting scrambled (I believe by the ASA).



This Discussion