11-23-2013 08:09 PM - edited 03-11-2019 08:08 PM
Dear All,
i currently have a big problem with inter-interface routing within ASA. If you could please take a look at my topology.
My big problem is i can't ping from .82 which is R1 to 172.20.0.161 (ASA outside interface), i created a scenario when the traffic goes in to R2 reaching the 172.20.0.161 then the ASA will forward it to Inside interface (next hop ip address 172.20.0.177). Below is the show ip route from each device.
R1#sh ip route
172.20.0.0/28 is subnetted, 3 subnets
S 172.20.0.176 [1/0] via 172.20.0.81
S 172.20.0.160 [1/0] via 172.20.0.81
C 172.20.0.80 is directly connected, FastEthernet1/0
R2#sh ip route
172.20.0.0/28 is subnetted, 3 subnets
C 172.20.0.176 is directly connected, FastEthernet0/0
C 172.20.0.160 is directly connected, FastEthernet0/1
C 172.20.0.80 is directly connected, FastEthernet1/0
ASA# sh route
C 172.20.0.176 255.255.255.240 is directly connected, inside
C 172.20.0.160 255.255.255.240 is directly connected, outside
S 172.20.0.80 255.255.255.240 [1/0] via 172.20.0.178, inside
If someone can help me, i'm really appreciate it. Thanks
Cheers
Regards
Alkuin Melvin
11-24-2013 01:43 AM
Have you configured hairpinning on the ASA?
same-security-traffic permit intra-interface
Have you configured ACL allowing the inbound traffic on the outside interface?
What ASA version are you running?
Please post a full sanitized configuration of the ASA
--
Please rate all helpful posts
11-24-2013 02:11 AM
Thanks marius, for the ACL that permitting any traffic is permitted on inside and outside interface. Below is the full configuration, i'm using 8.4 version. I have tried this scenario on the real devices and lab simulation but still no solution.
ciscoasa# sh run
: Saved
:
ASA Version 8.4(2)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface GigabitEthernet0
nameif inside
security-level 100
ip address 172.20.0.177 255.255.255.240
!
interface GigabitEthernet1
nameif outside
security-level 100
ip address 172.20.0.161 255.255.255.240
!
interface GigabitEthernet2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet4
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet5
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list ALL extended permit ip any any
pager lines 24
logging enable
logging buffered informational
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
access-group ALL in interface inside
access-group ALL in interface outside
route inside 172.20.0.80 255.255.255.240 172.20.0.178 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
!
!
prompt hostname context
call-home reporting anonymous prompt 2
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
crashinfo save disable
Cryptochecksum:887c3d3d7e73efcbe731bcedbe63b51e
: end
Regards
Alkuin Melvin
11-24-2013 02:39 AM
so you are pinging from 172.80.0.82 ? Which IP are you pinging to?
from the look of your diagram you are trying to source the ping from the .82 address on the outside interface and reach some other address on the inside network which is also located on the R1?
Please explain more on how you are trying to make the traffic flow, and include the source and destination IPs for the ping.
--
Please rate all helpful posts
11-24-2013 03:17 AM
The source ip address is 172.20.0.82 which is R1 and destination ip address is 172.20.0.161 which is outside interface of ASA. On ASA i created a static route for network 172.20.0.82/28 will be forwarded to 172.20.0.162 which is R2 interface that is connected to inside interface of ASA. The objective of this scenario is forwarding any traffic received by outside ASA interface to inside interface.
Cheers :)
Regards
Alkuin Melvin
11-24-2013 03:58 AM
It looks as though you have asymmetric routing going on. Your R2 does the routing and sends the traffic directly to 172.20.0.161. Then your ASA has the only route back to 172.20.0.82 through the inside interface. so traffic enters the outside interface initially and then is dropped as the ASA will view this as a spoof since it did not send the return traffic out the same interface it received it on.
You will need to either put another router into the mix, user VRFs or configure TCP bypass on the ASA.
11-24-2013 05:29 PM
It seems the available option for now is to configure the tcp state bypass on ASA because we do not have any router to put into. I have tried to configure the tcp state bypass but the traffic still do not pass through. Below is the configuration for ASA :
class-map BYPASS_TRAFFIC
match access-list 100 // access-list 100 extended permit ip any any
!
!
policy-map BYPASS_POLICY
class BYPASS_TRAFFIC
set connection advanced-options tcp-state-bypass
!
service-policy BYPASS_POLICY global
Regards
Alkuin Melvin
11-24-2013 09:11 PM
Hello,
On this lab scenario you are dealing with ICMP traffic so TCP state bypass is not the solution:
Disabling ICMP inspection will do it (Ofcourse make sure you allow ICMP through the firewall but do not inspect it )
If this still does not work run some packet-tracer from outside and let us know
Rate all of the helpful posts!!!
Regards,
Jcarvaja
Follow me on http://laguiadelnetworking.com
11-25-2013 02:38 AM
Hello Julio,
I have the GNS3 working for this lab scenario and no inspect ICMP on ASA by default. Below is the result for packet tracer :
* Routing failed to locate next-hop for icmp from outside: 172.20.0.161/0 to outside : 192.168.10.10/0
ASA Configuration :
ASA Version 8.4(2)
!
hostname ciscoasa
enable password 8Ry2YjIyt7RRXU24 encrypted
passwd 2KFQnbNIdI.2KYOU encrypted
names
!
interface GigabitEthernet0
nameif inside
security-level 100
ip address 172.20.0.177 255.255.255.240
!
interface GigabitEthernet1
nameif outside
security-level 100
ip address 172.20.0.161 255.255.255.240
!
interface GigabitEthernet2
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet3
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet4
shutdown
no nameif
no security-level
no ip address
!
interface GigabitEthernet5
shutdown
no nameif
no security-level
no ip address
!
ftp mode passive
same-security-traffic permit inter-interface
same-security-traffic permit intra-interface
access-list ALL extended permit ip any any
access-list 100 extended permit ip any any
pager lines 24
logging enable
logging buffered informational
logging asdm informational
mtu inside 1500
mtu outside 1500
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
access-group ALL in interface inside
access-group ALL in interface outside
route outside 0.0.0.0 0.0.0.0 172.20.0.162 1
route inside 172.20.0.80 255.255.255.240 172.20.0.178 1
route inside 192.168.10.0 255.255.255.0 172.20.0.178 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
timeout tcp-proxy-reassembly 0:01:00
timeout floating-conn 0:00:00
dynamic-access-policy-record DfltAccessPolicy
user-identity default-domain LOCAL
aaa authentication http console LOCAL
http server enable
http 0.0.0.0 0.0.0.0 outside
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
webvpn
username compnet password kpYlEYhumTMG9mNg encrypted privilege 15
!
class-map BYPASS
match access-list 100
!
!
policy-map BYPASS_POLICY
class BYPASS
!
prompt hostname context
no call-home reporting anonymous
call-home
profile CiscoTAC-1
no active
destination address http https://tools.cisco.com/its/service/oddce/services/DDCEService
destination address email callhome@cisco.com
destination transport-method http
subscribe-to-alert-group diagnostic
subscribe-to-alert-group environment
subscribe-to-alert-group inventory periodic monthly
subscribe-to-alert-group configuration periodic monthly
subscribe-to-alert-group telemetry periodic daily
crashinfo save disable
Cryptochecksum:ea227cdde31b133926c8b199c039d619
I'm very confused why this is happening, i have put the router on place instead of ASA and it is going fine, but still we don't have any router right now to be running on production.
Regards
Alkuin Melvin
11-25-2013 09:00 AM
Hello,
The thing is the following:
ASA will receive the ICMP echo from 172.20.0.82 on it's outside interface, it will then need to send the echo-reply via that same interface but based on your routing table it will see the other interface as the listed next-hop.
As traffic goes to the ASA itself I do not think we can change this behavior but just in case provide the following:
packet-tracer input outside icmp 172.20.0.82 8 0 172.20.0.161
Rate all of the helpful posts!!!
Regards,
Jcarvaja
Follow me on http://laguiadelnetworking.com
11-26-2013 10:08 AM
Hi Julio,
Below is the output and from that we can see everything is up and allowed.
ciscoasa# packet-tracer input outside icmp 172.20.0.82 8 0 172.20.0.161
Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list
Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in 172.20.0.161 255.255.255.255 identity
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Phase: 5
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 6
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Phase: 7
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 81, packet dispatched to next module
Result:
input-interface: outside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: allow
I have tried another scenario with ASA using just one interface (one leg scenario) and it works great using the same-security traffic permit intra-interface command.
Is this one of the limitation we have on ASA or i need to enabled/ disabled some options to make this scenario works?
Regards
Alkuin Melvin
11-26-2013 11:54 PM
As mentioned earlier you have Asymmetric routing happening. Dropping the asymmetric routing is a feature of the ASA by default. if you want to get this working I suggest either placing another router in the mix or separate the routing table by using VRFs on R2. Once R2 stops doing the routing and the ASA starts routing you problem will be solved.
Your setup here isn't something you would see in a real life situation unless your network is being attacked.
Also keep in mind that GNS3 is a virtualized environment enabled by performing hacks, and because of this it can be unstable and not perform as expected on occasion.
--
Please rate all helpful posts
11-28-2013 12:44 AM
Dear Marius,
So it is the limitation from ASA all this time. Yes, anyway we have changed the topology into one leg scenario and it works great. And just for information, we have tried the inter interface routing in a real life situation but we still cannot see the packets going through different interface as the ASA received traffic from an interface. For now i will stick to one leg scenario and if anyone have a solution, let me know and i will give it a try. Thanks
Regards
Alkuin Melvin
08-03-2015 11:16 AM
conf t
management-access inside
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide