Outside_Internet_Ping_Inside

[Stephen Sisson]

Hello,

I need your help to resolve this issue we have for users outside not able to ping inside server.

We have one server 98.101.206.51 with internal address 172.16.5.2 and anyone from the Outside or internet can ping the public address

The problem is we have another server 98.101.206.52 with internal address 172.16.5.5 and no one can ping this public address from the outside or internet

We need your help to resolve this issue, allowing anyone from the outside / internet to ping the public address that's translated to the internal address 172.16.5.5

We have under Policy-Map Global_Policy inspect icmp

We have ACL allow Any to 98.101.206.52 for icmp/echo

Please summit all commands for allowing this from the outside

Thank you

[Jouni Forss]

Hi,

Think you just wrote on the forums on another subject where I answered

I guess this is the same Static NAT / Server and you are using 8.4 software.

Remember that in the new software you have to open the traffic to the Real IP address of the server.

Use either of the following to allow ICMP

access-list permit icmp any host 172.16.5.5 echo

OR

access-list permit icmp any object echo

Try these and let us know if it worked

Hope this helps

- Jouni

[Stephen Sisson]

Yes Sir, me again

to add the access-list the name should be Outside-IN ? is this correct

Thank you

[Jouni Forss]

Hi,

Yes, you use the excisting ACL name that you have attached to your ASAs "outside" interface which controls the traffic entering your network from the Internet

- Jouni

[Stephen Sisson]

Hello Jouni,

I type in from command line

access-list outside-in permit icmp any host 172.16.5.5 echo

still not able to ping from the outside /internet

[Jouni Forss]

Hi,

Is there "hitcount" in the rule you created increasing?

If it is, is ICMP allowed on your server firewall settings?

If the ACL "hitcount" counter is not increasing is there any rule in the same ACL that might "deny" the ICMP traffic?

- Jouni

[Stephen Sisson]

Hello Jouni,

From command line show access-list showing

access-list OUTSIDE-IN line 15 remark Allow outside to ping PCSFTP server

access-list OUTSIDE-IN line 16 extended permit icmp any object obj-172.16.5.2 echo (hitcnt=0) 0x9eb249cb

  access-list OUTSIDE-IN line 16 extended permit icmp any host 172.16.5.2 echo (hitcnt=0) 0x9eb249cb

access-list OUTSIDE-IN line 17 remark Allow outside to ping VPN2 server

access-list OUTSIDE-IN line 18 extended permit icmp any object SERVER (hitcnt=0) 0x196cdde7

  access-list OUTSIDE-IN line 18 extended permit icmp any host 172.16.5.5 (hitcnt=4) 0x196cdde7

access-list OUTSIDE-IN line 19 remark Allow outside to ping VPN2 server

access-list OUTSIDE-IN line 20 extended permit icmp any object SERVER echo (hitcnt=0) 0x7e6536e1

  access-list OUTSIDE-IN line 20 extended permit icmp any host 172.16.5.5 echo (hitcnt=0) 0x7e6536e1

The 172.16.5.2 we can ping from the outside but not able to ping 172.16.5.5 from outside, also the 172.16.5.5 is the same server we worked on yesterday for the L2TP/PPTP and would this stop us from allowing icmp to this same server? - Just a thought

Thank you

[Jouni Forss]

Hi,

The rules you copy pasted from the OUTSIDE-IN ACL do have the rule for the host 172.16.5.2 that is supposedly working but it doesnt have any hitcount so far?

Can you use the "packet-tracer" command for this new server and copy/paste the output here

packet-tracer input outside icmp 1.2.3.4 0 8 98.101.206.52

- Jouni

[Stephen Sisson]

Yes Sir

PCSASAFW(config)# packet-tracer input outside icmp 1.2.3.4 0 8 98.101.206.52

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network SERVER

nat (inside,outside) static 98.101.206.52

Additional Information:

NAT divert to egress interface inside

Untranslate 98.101.206.52/0 to 172.16.5.5/0

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group OUTSIDE-IN in interface outside

access-list OUTSIDE-IN extended permit icmp any object SERVER

access-list OUTSIDE-IN remark Allow outside to ping VPN2 server

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

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: 6

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside,outside) source dynamic any interface description PAT_Inside_Outside_on_MPLS_Circuit

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 3895, 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

[Jouni Forss]

Hi,

Test seems to go through without drop BUT

I dont think this should be shown in the NAT/rpf-check

Phase: 7

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

nat (inside,outside) source dynamic any interface description PAT_Inside_Outside_on_MPLS_Circuit

Additional Information:

Can you share your NAT configuration.

If the above is your Default PAT rule for Internet traffic I would consider removing it and changing it to the following

nat (inside,outside) after-auto source dynamic any interface description PAT_Inside_Outside_on_MPLS_Circuit

The keyword/parameter "after-auto" would move the NAT rule to the bottom section of the NAT rules. It would be therefore be one of the last NAT rules to be matched (As a default PAT rule should be)

Better to first check all the NAT rules though.

- Jouni

[Stephen Sisson]

Yes Sir

show nat

Manual NAT Policies (Section 1)

1 (inside) to (outside) source dynamic any interface   description PAT_Inside_Outside_on_MPLS_Circuit

    translate_hits = 0, untranslate_hits = 0

Auto NAT Policies (Section 2)

1 (PCSFTP) to (outside) source static obj-172.16.5.2 98.101.206.51

    translate_hits = 42, untranslate_hits = 1616

2 (inside) to (outside) source static SERVER 98.101.206.52

    translate_hits = 0, untranslate_hits = 499

3 (PCSFTP) to (outside) source dynamic obj_any interface

    translate_hits = 145, untranslate_hits = 6

Everything is working except the ping from the outside to this one server

Thank you

[Jouni Forss]

Hi,

Is the NAT perhaps configured with the wrong source interface?

The working NAT is configured for interface "PCSFTP"

The NAT that is not working is configured for interface "inside"

Yet both NATs source address is from the same subnet.

I think you probably have the wrong interface as the source interface in the NAT configuration for the new server. (And I might have given you that configuration presuming you were using "inside" interface )

So can you check the NAT configuration and change the source interface for it.

I would still perhaps also suggest changing the NAT configuration like I mentioned in the earlier reply. DO NOTICE that first removing the NAT configuration will close the current "inside" connections through the firewall BUT configuring the new suggested configuration will make new connections again possible.

- Jouni

[Stephen Sisson]

After changing the NAT to PAT rule we have this

PCSASAFW(config)# packet-tracer input outside icmp 1.2.3.4 0 8 98.101.206.52

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network SERVER

nat (inside,outside) static 98.101.206.52

Additional Information:

NAT divert to egress interface inside

Untranslate 98.101.206.52/0 to 172.16.5.5/0

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group OUTSIDE-IN in interface outside

access-list OUTSIDE-IN extended permit icmp any object SERVER

access-list OUTSIDE-IN remark Allow outside to ping VPN2 server

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

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: 5

Type: INSPECT

Subtype: np-inspect

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network SERVER

nat (inside,outside) static 98.101.206.52

Additional Information:

Phase: 7

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 3953, 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

Yes Sir I will change this - can you help with the commands

[Jouni Forss]

Hi,

What I meant with the previous post is

That notice that you have these 2 servers

• 172.16.5.2
• 172.16.5.5

As we can see they are from the same network (I would assume)

Yet when we look at your above "show nat" command ouput

1 (PCSFTP) to (outside) source static obj-172.16.5.2 98.101.206.51

    translate_hits = 42, untranslate_hits = 1616

2 (inside) to (outside) source static SERVER 98.101.206.52

    translate_hits = 0, untranslate_hits = 499

Notice the bolded sections

As you can see the working Static NAT for server 172.16.5.2 is from "PCSFTP" to "outside"

Yet the Static NAT for server 172.16.5.5 that is NOT working  is fromt "inside" to "outside"

So you probably have this NAT configuration for the new server

object network SERVER

host 172.16.5.5

nat (inside,outside) static 98.101.206.52

When its supposed to be

object network SERVER

host 172.16.5.5

nat (PCSFTP,outside) static 98.101.206.52

By the way, you can also use the command "show run nat" to list all your NAT configuration. It wont show the IP addresses inside the "objects" though which is a shame.

- Jouni

[Stephen Sisson]

Hello Jouni,

Wow - you really are the best, I can't thank you enough for helping me with this ping issue, and for your help yesterday with the L2TP/PPTP.

You are amazing with a GOD given talent, thank you my friend.