Re: ASA 5520, fw8.3 routing between 2 inside interfaces

sorin.dab · ‎12-02-2010

Hello,

I am having some issues with some routing between 2 inside ASA interfaces.

The setup is as follows : 2 internal networks and 1 outside, same security level on the inside networks and lower on the outside . I need full access from inside to inside_2 network and vice-verse, the "same-security-traffic permit inter-interface" command was added but still no connectivity, what am i missing ?

interface GigabitEthernet0/0

description outside

duplex full

nameif outside

security-level 0

ip address 172.1.1.1 255.255.255.128

!

interface GigabitEthernet0/1

description inside

duplex full

nameif inside

security-level 100

ip address 1.1.1.0 255.255.255.0

!

interface GigabitEthernet0/2

description inside_2

duplex full

nameif inside_2

security-level 100

ip address 2.2.2..0 255.255.255.0

mirober2 · ‎12-02-2010

Hello,

The best way to track this down will be to use the packet-tracer. Take a look at the output of the following commands and it see what they lists for the packet flow:

packet-tracer in inside tcp 1.1.1.1 12345 2.2.2.2 80

packet-tracer in inside_2 tcp 2.2.2.2 12345 1.1.1.1 80

-Mike

sorin.dab · ‎01-05-2011

I tried the packet tracer but it says that traffic is allowed and when I try to pass traffic between those 2 ip's it does not work and gives and error .

6 Jan 06 2011 05:30:53 10.7.0.106 44632 10.5.0.103 22 Deny TCP (no connection) from 10.7.0.106/44632 to 10.5.0.103/22 flags RST on interface inside
6 Jan 06 2011 05:30:53 10.7.0.106 44632 10.5.0.103 22 Teardown TCP connection 3894 for inside:10.7.0.106/44632 to inside_2:10.5.0.103/22 duration 0:00:00 bytes 0 TCP Reset-O

6 Jan 06 2011 05:30:53 10.7.0.106 44632 10.5.0.103 22 Built inbound TCP connection 3894 for inside:10.7.0.106/44632 (10.7.0.106/44632) to inside_2:10.5.0.103/22 (10.5.0.103/22)

ASA/act# packet-tracer in inside tcp 10.7.0.106 12345 10.5.0.103 22

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.5.0.0 255.255.255.0 inside_2

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 3862, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: inside_2
output-status: up
output-line-status: up
Action: allow

ASA/act# packet-tracer in inside_2 tcp 10.5.0.103 12345 10.7.0.104 22

Phase: 1
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 10.7.0.0 255.255.255.0 inside

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:

Phase: 3
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: FOVER
Subtype: standby-update
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 3889, packet dispatched to next module

Result:
input-interface: inside_2
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: allow

Kureli Sankar · ‎01-05-2011

It seems to be logging 106015 messages.The connection is torndown due to Reset-O and then subsequent reset packet is dropped with this 106015 messages which is expected. Why we see Reset-O is the question.

Is the reset coming from the server? Does this ssh work from a computer on the same subnet as the server?

Have you tried a packet capture on the server? or on the client?

cap capin int inside match tcp any host 10.5.0.103 eq 22

cap capout int inside_2 match tcp any host 10.5.0.103 eq 22

sh cap capin det | i R

sh cap capout det | i R

Look for the source MAC address on the reset packet to determin where the reset is coming from.

-KS

sorin.dab · ‎01-06-2011

Hello,

It does not happen just with the SSH , any traffic including http, only ICMP is passed tot he other IP, any other traffic ends up with the same error .

I sort of fixed it by using a NAT :

object network inside
subnet 10.7.0.0 255.255.255.0

object network inside
nat (inside,inside_2) dynamic interface

Whith the following nat works from 10.7.0.0 to 10.5.0.0 the other way around is not working, trying to connect from 10.5.x.x to 10.7.x.x i get the following error message :

5 Jan 06 2011 15:54:06 10.7.0.106 Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src inside_2:10.5.0.103 dst inside:10.7.0.106 (type 8, code 0) denied due to NAT reverse path failure

Should the connection between the 2 interfaces work without NAT, just by using the "same-security-traffic permit inter-interface" ? And if this is not the case how can i fix it to work also from 10.5.x.x to 10.7.x.x ?

Dan-Ciprian Cicioiu · ‎01-06-2011

Sorin ,

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00807fc191.shtml#Same

Note: Even though the "same-security traffic permit inter-interface" has been configured for the same security level interfaces ("DMZ" and "DMZ-2-testing"), it still needs a translation rule (static/dynamic) to access the resources placed in those interfaces.

I would try configure identity nat for the traffic between these two interfaces.

Dan

sorin.dab · ‎01-06-2011

I understand that NAT is needed for traffic to pass from one interface to another, but how can i translate that into a nat configuration that will work since the current config only works one-way ...

object network inside
subnet 10.7.0.0 255.255.255.0

object network inside
nat (inside,inside_2) dynamic interface

Bastien Migette · ‎01-06-2011

Since you are using asa 8.3, nat control is not used anymore, see:

http://www.cisco.com/en/US/docs/security/asa/asa83/upgrading/migrating.html#wp60212

So I think it should work without any kind of nat between your 2 insides interfaces.