cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3118
Views
15
Helpful
12
Replies

Outside to Inside NOT work - Please Help (Cisco ASA 5505)

rottads
Level 1
Level 1

I am very new to Cisco ASA and I am trying many days to implement the design below but still cannot get it done. The situation I am facing is

- a host (e.g. 192.168.5.10) under Inside interface can contact to outside without any problem.

- however a host outside (e.g. in VLAN1 or outside this network) cannot contact host under Inside interface. I am using PING test and always get Request Time Out.

Capture.JPG

Here is the configuration. Please advise how I can fix the problem.

Cryptochecksum: c45adab2 68cdf3f0 fbdfecfa 26341c1c

: Saved

: Written by sgtssea at 08:31:12.390 UTC Thu May 9 2013

!

ASA Version 8.4(4)1

!

hostname XXXXXXX

enable password CDA/4jRbBWA59Trl encrypted

passwd 0e53SZdxezxawxDG encrypted

names

!

interface Ethernet0/0

description "Link to XXXXXXX OFFICE Vlan"

!

interface Ethernet0/1

description "Link to XXXXXXX INDUSTRIAL Vlan"

switchport access vlan 30

!

interface Ethernet0/2

!

interface Ethernet0/3

!

interface Ethernet0/4

!

interface Ethernet0/5

!

interface Ethernet0/6

!

interface Ethernet0/7

!

interface Vlan1

nameif outside

security-level 0

ip address 10.73.5.6 255.255.255.128

!

interface Vlan30

nameif inside

security-level 100

ip address 192.168.5.1 255.255.255.0

!

ftp mode passive

same-security-traffic permit intra-interface

object network obj_any

subnet 0.0.0.0 0.0.0.0

object network Benteler

host 192.168.5.10

access-list OUTSIDE_IN_ACL extended permit icmp any any

access-list OUTSIDE_IN_ACL extended permit tcp any object Benteler eq 5900

access-list INSIDE_IN_ACL extended permit icmp any any

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

icmp unreachable rate-limit 1 burst-size 1

no asdm history enable

arp timeout 14400

!

object network Benteler

nat (inside,outside) static 10.73.5.130

access-group INSIDE_IN_ACL in interface inside

access-group OUTSIDE_IN_ACL in interface outside

route outside 0.0.0.0 0.0.0.0 10.73.5.1 1

timeout xlate 3:00:00

timeout pat-xlate 0:00:30

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 ssh console LOCAL

http server enable

http 10.73.5.0 255.255.255.128 outside

http 10.90.147.0 255.255.255.0 outside

no snmp-server location

no snmp-server contact

snmp-server enable traps snmp authentication linkup linkdown coldstart warmstart

telnet timeout 5

ssh 10.90.147.0 255.255.255.0 outside

ssh timeout 30

ssh key-exchange group dh-group1-sha1

console timeout 0

dhcpd auto_config outside

!

threat-detection basic-threat

threat-detection statistics access-list

no threat-detection statistics tcp-intercept

ntp server 10.91.127.146 source outside

webvpn

username sgtssea password MvCn9NnVvYbQDnDz encrypted

!

class-map inspection_default

match default-inspection-traffic

!

!

policy-map type inspect dns preset_dns_map

parameters

  message-length maximum client auto

  message-length maximum 512

policy-map global_policy

class inspection_default

  inspect dns preset_dns_map

  inspect ftp

  inspect h323 h225

  inspect h323 ras

  inspect rsh

  inspect rtsp

  inspect esmtp

  inspect sqlnet

  inspect skinny 

  inspect sunrpc

  inspect xdmcp

  inspect sip 

  inspect netbios

  inspect tftp

  inspect ip-options

  inspect icmp

!

service-policy global_policy global

prompt hostname context

no call-home reporting anonymous

Cryptochecksum:c45adab268cdf3f0fbdfecfa26341c1c

: end

1 Accepted Solution

Accepted Solutions

Hi,

What is the operating system on the host? Is it perhaps Windows 7?

I am not really an IT guy but to me it seems also possible that the actual OS firewall might still cause this.

For example consider this situation

When you first connect the Windows 7 device to a new network it asks you to define which network location it is. Depending on what you have defined as the location when you first connected the device to that network the OS might have different firewall rules for it.

So when the device is connected outside the ASA it might have totally different rules compared to the settings it has when it has been connected to the network behind the ASA.

The network connected might for example be listed as a Home or Public network. And the Home network might allow ICMP while if the new network connection (ASA) was chosen as Public network it might block the ICMP and any other connections.

If the problem is related to the ASA, I cant really see what the problem is. The "packet-tracer" already tells that the correct rules are hit and there doesnt seem to be anything wrong with the actual configurations. As the ASA allows the traffic FROM the host it seems to be working normally, though it seems you have only allowed ICMP.

- Jouni

View solution in original post

12 Replies 12

julomban
Level 3
Level 3

Hello Rott,

To be new at this you have done a good job as the configuration of the ASA looks good, you have the NAT and ACL's configured properly:

object network Benteler

nat (inside,outside) static 10.73.5.130

!

access-list OUTSIDE_IN_ACL extended permit icmp any any

access-list OUTSIDE_IN_ACL extended permit tcp any object Benteler eq 5900

You need to know that not always the problem is on the ASA appliance so you need to create captures so you can check/verify if the packet its first at all getting to the ASA and second if that same packet is leaving the ASA with no problem.

Capture:

capture outside interface outside match icmp any host 10.73.5.130

capture inside interface inside match icmp any host 192.168.5.10

I am capturing traffic from anyone on the outside/inside going to your server, once you have those captures in place you can try a ping from the outside to 10.73.5.130 and issue the following command to see the captures:

show capture outside

show capture inside

You are more than welcome to share the results so we can see what is happening with the packet.

Regards,

Juan Lombana

Please rate helpful posts.

Hello Juan,

Thanks for your advice. I have captured the package like you suggest but the result is quite strange because there is no single package at inside interface.

#show capture OUTSIDE

4 packets captured

   1: 12:33:59.497532 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

   2: 12:34:04.081462 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

   3: 12:34:09.028883 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

   4: 12:34:14.055508 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

4 packets shown

#show capture INSIDE

0 packet captured

0 packet shown

Hello Rott,

Please share the following packet tracer:

packet-tracer input outside icmp 10.90.147.250 8 0 10.73.5.130

Also, if you can share the "show capture" command.

Regards,

Juan Lombana

Please rate helpful posts.

I think I will have to post the result of packet-tracer tomorrow because I just notice now that the test computer which is directly connected to Inside interface is off and now no one at the site to turn it on.

Here is the result for both packet capture and packet tracer. Please advise

# show capture OUTSIDE

4 packets captured

   1: 02:38:36.537829 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

   2: 02:38:41.348767 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

   3: 02:38:46.437874 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

   4: 02:38:51.348446 802.1Q vlan#1 P4 10.90.147.250 > 10.73.5.130: icmp: echo request

4 packets shown

------------------------------------------------------------------------------------------

# show capture INSIDE

4 packets captured

   1: 02:38:36.538088 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

   2: 02:38:41.349026 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

   3: 02:38:46.438133 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

   4: 02:38:51.348721 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

4 packets shown

------------------------------------------------------------------------------------------

# packet-tracer input outside icmp 10.90.147.250 8 0 10.73.5.130

Phase: 1

Type: CAPTURE

Subtype:

Result: ALLOW

Config:

Additional Information:

MAC Access list

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 3

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network Benteler

nat (inside,outside) static 10.73.5.130

Additional Information:

NAT divert to egress interface inside

Untranslate 10.73.5.130/0 to 192.168.5.10/0

Phase: 4

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group OUTSIDE_IN_ACL in interface outside

access-list OUTSIDE_IN_ACL extended permit icmp any any

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

class-map inspection_default

match default-inspection-traffic

policy-map global_policy

class inspection_default

  inspect icmp

service-policy global_policy global

Additional Information:

Phase: 7

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: HOST-LIMIT

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network Benteler

nat (inside,outside) static 10.73.5.130

Additional Information:

Phase: 10

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 11

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 4270, packet dispatched to next module

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

------------------------------------------------------------------------------------------

# show capture

capture OUTSIDE type raw-data interface outside [Capturing - 438 bytes]

  match icmp any host 10.73.5.130

capture INSIDE type raw-data interface inside [Capturing - 376 bytes]

  match icmp any host 192.168.5.10

Hi,

Incase you want to configure a capture that both shows if Echo reply is leaving the inside interface towards the actual host and if the host is replying to the ICMP echo then try this

access-list ICMP-CAP permit icmp host 10.90.147.250 host 192.168.5.10

access-list ICMP-CAP permit icmp host 192.168.5.10 host 10.90.147.250

capture ICMP-CAP type raw-data access-list ICMP-CAP interface inside buffer 1000000

Then test the ICMP traffic and use the following command to confirm what is capture

show capture ICMP-CAP

You should see the echo reply messages if the host is replying to the ICMP. There is always a change that some local firewall prevents the host from replying to the ICMP from remote networks.

- Jouni

Hello Jouni,

Thanks for your advice, but I still cannot see the echo reply. What could be the reason?

access-list INSIDE_IN_ACL extended permit icmp any any

access-list ICMP-CAP extended permit icmp host 10.90.147.250 host 192.168.5.10

access-list ICMP-CAP extended permit icmp host 192.168.5.10 host 10.90.147.250

pager lines 24

logging enable

logging asdm informational

mtu inside 1500

mtu outside 1500

icmp unreachable rate-limit 1 burst-size 1

XXXXXXXX(config)# show capture ICMP-CAP

4 packets captured

   1: 03:30:32.622755 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

   2: 03:30:37.388194 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

   3: 03:30:42.398798 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

   4: 03:30:47.440925 802.1Q vlan#30 P4 10.90.147.250 > 192.168.5.10: icmp: echo request

4 packets shown

Hi,

I think earlier in this discussion you said the host behind the ASA can connect to networks outside the ASA?

If not, doublecheck the network settings of the host.

I would also recomend checking if there is some firewall software or windows related settings that is stopping it from replying to ICMP Echos.

If you have some additional device/computer to connect to the ASA Vlan30 I would suggest testing the ICMP with that device. Though in that case if you use the same internal IP remember to disconnect the actual host and after that do a "clear arp" on the ASA before testing.

There are occasion where I just cant get ICMP working on some computers even though it should be allowed on the actual host. So in those cases I tend to test with some TCP connection.

I cant see any problems with the ASA configurations and even the earlier "packet-tracer" confirms that everything is working and hitting the correct configurations/rules on the ASA.

So on that basis it seems that the problem is on the actual host.

- Jouni

Hi all,

1. I thought the problem might be related to the network settings on the host like default gateway but I have tested by pinging from the host to outside (e.g. 10.90.147.250) and ping is working perfectly. It seems that outgoing traffic from host to outside is working but incoming traffic is not working. This is not only happen to ICMP PING but also TCP 5900 (it is VNC - remote software).

2. I thought the problem might be related to the actual host like Windows Firewall or any other software;however after I disconnected the host from ASA and connected it to normal LAN, I can ping it without any problem. Also I even change the host connecting to ASA to a new PC but the the problem is still persisted. I think this can prove that it is not related to the host itself.

Regarding the current configuration, the host is connected directly to ASA interface.

Now I have no idea what should be the solution. Please help

Hi,

What is the operating system on the host? Is it perhaps Windows 7?

I am not really an IT guy but to me it seems also possible that the actual OS firewall might still cause this.

For example consider this situation

When you first connect the Windows 7 device to a new network it asks you to define which network location it is. Depending on what you have defined as the location when you first connected the device to that network the OS might have different firewall rules for it.

So when the device is connected outside the ASA it might have totally different rules compared to the settings it has when it has been connected to the network behind the ASA.

The network connected might for example be listed as a Home or Public network. And the Home network might allow ICMP while if the new network connection (ASA) was chosen as Public network it might block the ICMP and any other connections.

If the problem is related to the ASA, I cant really see what the problem is. The "packet-tracer" already tells that the correct rules are hit and there doesnt seem to be anything wrong with the actual configurations. As the ASA allows the traffic FROM the host it seems to be working normally, though it seems you have only allowed ICMP.

- Jouni

Hi Jouni,

Yes, you are right. It is Windows 7 but I have disabled Windows Firewall for active network, Home and Public.

Rott

Hi Jouni,

Thanks a lot for your investigation. I have found the root cause. It is the IPS software on the host and after I disable it. Everything is working.

Rott

Review Cisco Networking for a $25 gift card