01-07-2009 04:20 AM - edited 03-11-2019 07:33 AM
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?
Stu
01-07-2009 05:31 AM
Stu - can you post the permit acl and the nat statements for review?
01-07-2009 05:55 AM
IPs and names have been changed:
Permit ACL:
name 10.0.1.0 net_Data-LAN
name 10.0.2.0 net_Voice-LAN
!
object-group network Grp_Internal-networks
network-object net_Data-LAN 255.255.255.0
network-object net_Voice-LAN 255.255.255.0
!
access-list inside_access_in extended permit ip object-group Grp_Internal-networks object-group Grp_Internal-networks log
NAT:
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...
01-07-2009 05:58 AM
Stu,
I am confused - your no-nat is only from the inside to the outside.
Which IP subnet is on the outside? Data or Voice?
01-07-2009 06:28 AM
Eh, neither, actually. Both should be on the inside...
01-07-2009 06:34 AM
There is your potential issue.
Try the below instead:-
static (inside,inside) 10.0.1.0 10.0.1.0 netmask 255.255.255.0
static (inside,inside) 10.0.2.0 10.0.2.0 netmask 255.255.255.0
HTH>
01-08-2009 02:35 AM
Morning...
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.
Stu
01-08-2009 02:53 AM
post your complete config (sanitised) for review.
01-08-2009 08:25 AM
01-08-2009 08:39 AM
I notice from the config:-
1) You are running EIGRP as an internal routing protocol?
2) If you have an internal router that is a neighbour of the ASA - then why is that device not doing the routing?
HTH>
01-08-2009 08:49 AM
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.
Stu
01-08-2009 08:50 AM
Is the voice vlan IP subnet in the ASA routing table?
01-08-2009 08:59 AM
Yes, it is. The enter correctly shows that it has been entered by EIGRP.
01-08-2009 09:01 AM
So I am presuming that the route entry in the ASA knows that the Voice VLAN is reachable via the ISR???
01-09-2009 01:55 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: