cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1553
Views
0
Helpful
7
Replies

Unable to Ping internet site using source IP of DMZ interface

mahesh18
Level 6
Level 6

Hi everyone,

From ASA while using the IPs which are behind the DMZ  i can ping the internet sites while using DMZ as interface and source IP of switch which is behind the DMZ fine.

But when i try to  ping using packet tracer using DMZ  interface as source and also IP of DMZ interface as source IP ping fails.

where 192.168.69.2 is IP of DMZ interface

ciscoasa#   packet-tracer input DMZ icmp 192.168.69.2 8 8 4.2.2.2

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: DMZ

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

Need to know how can i allow ping using DMZ interface as source IP?

Thanks

MAhesh

4 Accepted Solutions

Accepted Solutions

Jouni Forss
VIP Alumni
VIP Alumni

Hi Mahesh,

To my understanding this is not possible.

I dont think it hasnt been possible at any point when the "packet-tracer" command has been available.

Why would you even want to use the IP address as the source?

- Jouni

View solution in original post

In general the ASA when communicating to the different networks it uses the interface connected to that network or the interface behind which that network is located.

Also the ASA doesn't really allow traffic across the box to the other side to an ASA interface (other than in very specific cases like VPN + Device management connections)

I am not sure if this is documented anywhere. It certainly isnt mentioned in the Command Reference which would be a logical place. Then again it wouldnt be the first time that very specific and potentially important informatin was left out of public documentation.

I personally just avoid using any ASA interface IP with the "packet-tracer" and to be honest you are usually testing user traffic that is naturally coming from a different source IP address anyway.

If you would like to look which ports the ASA uses to listen to services you can use the command (minimum software 8.0(2) needed)

show asp table socket

If you want to see the connections formed by the ASA and to the ASA use the command

show conn all | inc Identity

- Jouni

View solution in original post

Hi,

Lets look at the first output

ciscoasa# show conn all | inc Identity

UDP outside 192.168.11.1:123 NP Identity Ifc 192.168.11.2:65535, idle 0:01:50, bytes 96, flags -

TCP outside 192.168.98.10:65323 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 531, flags UfrOB

TCP outside 192.168.98.10:65322 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 521, flags UfrOB

TCP outside 192.168.98.10:65321 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 406, flags UfrOB

TCP outside 192.168.98.10:65319 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 536, flags UfrOB

TCP outside 192.168.98.10:65313 NP Identity Ifc 192.168.11.2:443, idle 0:00:00, bytes 50003, flags UOB

TCP outside 192.168.98.10:65310 NP Identity Ifc 192.168.11.2:443, idle 0:00:04, bytes 34278, flags UOB

TCP outside 192.168.5.2:25844 NP Identity Ifc 192.168.11.2:22, idle 0:00:00, bytes 157719, flags UOB

UDP outside 192.168.11.1:123 NP Identity Ifc 192.168.11.2:65535, idle 0:01:50, bytes 96, flags -

The first seems to be a NTP connection. Its an UDP connection so the default timeout for UDP connection is 2min. As you can see its already been idle 1min 50 seconds so its really closed to being removed from the firewall connection table.

TCP outside 192.168.98.10:65323 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 531, flags UfrOB

TCP outside 192.168.98.10:65322 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 521, flags UfrOB

TCP outside 192.168.98.10:65321 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 406, flags UfrOB

TCP outside 192.168.98.10:65319 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 536, flags UfrOB

With the above connections it seems to me that they are TCP connections (possibly part of some TCP connections related to ASDM) Notice the end section with the TCP "flags". From these we can see that the TCP connections are already in the process of being teardown. In other words they are not in use anymore but in the process of being closed and removed from the connection table of the ASA.

The flags to look out for are

r - inside acknowledged FIN

f - inside FIN

TCP outside 192.168.98.10:65313 NP Identity Ifc 192.168.11.2:443, idle 0:00:00, bytes 50003, flags UOB

TCP outside 192.168.98.10:65310 NP Identity Ifc 192.168.11.2:443, idle 0:00:04, bytes 34278, flags UOB

TCP outside 192.168.5.2:25844 NP Identity Ifc 192.168.11.2:22, idle 0:00:00, bytes 157719, flags UOB

And as you can see with the last 3 connections, they are the same TCP connections that are left in the second output. This is because they seem to be in use still and there is no TCP flags that would indicate they are in the process of being teardown.

You can see explanation of all the different connection "flags" while  issuing the command "show conn all" and checking out the top most  portion (example output from my ASA)

ASA(config)# sh conn detail

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

       B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,

       D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,

       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,

       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response

       k - Skinny media, M - SMTP data, m - SIP media, n - GUP

       O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,

       q - SQL*Net data, R - outside acknowledged FIN,

       R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,

       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,

       V - VPN orphan, W - WAAS,

       X - inspected by service module

Here is also a good page telling the different most common connection flags you see on the ASA.

http://ccnpsecurity.blogspot.fi/2011/11/asa-flags-associated-with-tcp.html

Hope this helps

- Jouni

View solution in original post

Also to add,

One other great command related to connections is to use the

show conn long

show conn long all

It shows a lot more information about the connections

Like

  • How long the connections has been on the ASA "uptime"
  • What the applied timeout value for the connection is "timeout"
  • Source and Destination NAT. If IP address and the one following in "()" are the same then no nat has been done, or atleast the address hasnt been changed.

- Jouni

View solution in original post

7 Replies 7

Jouni Forss
VIP Alumni
VIP Alumni

Hi Mahesh,

To my understanding this is not possible.

I dont think it hasnt been possible at any point when the "packet-tracer" command has been available.

Why would you even want to use the IP address as the source?

- Jouni

Hi Jouni,

I was just trying all options to know if this is allowed or not.

So it seems it is not allowed by default or thats how ASA is designed.

Regards

MAhesh

In general the ASA when communicating to the different networks it uses the interface connected to that network or the interface behind which that network is located.

Also the ASA doesn't really allow traffic across the box to the other side to an ASA interface (other than in very specific cases like VPN + Device management connections)

I am not sure if this is documented anywhere. It certainly isnt mentioned in the Command Reference which would be a logical place. Then again it wouldnt be the first time that very specific and potentially important informatin was left out of public documentation.

I personally just avoid using any ASA interface IP with the "packet-tracer" and to be honest you are usually testing user traffic that is naturally coming from a different source IP address anyway.

If you would like to look which ports the ASA uses to listen to services you can use the command (minimum software 8.0(2) needed)

show asp table socket

If you want to see the connections formed by the ASA and to the ASA use the command

show conn all | inc Identity

- Jouni

Hi Jouni,

I agree somethings which you only learn through experience that not are in cisco documentation.

It also applies to Routing and switching.

When i access the ASA throguh ASDM and did

---

ciscoasa# show conn all | inc Identity

UDP outside 192.168.11.1:123 NP Identity Ifc 192.168.11.2:65535, idle 0:01:50, bytes 96, flags -

TCP outside 192.168.98.10:65323 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 531, flags UfrOB

TCP outside 192.168.98.10:65322 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 521, flags UfrOB

TCP outside 192.168.98.10:65321 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 406, flags UfrOB

TCP outside 192.168.98.10:65319 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 536, flags UfrOB

TCP outside 192.168.98.10:65313 NP Identity Ifc 192.168.11.2:443, idle 0:00:00, bytes 50003, flags UOB

TCP outside 192.168.98.10:65310 NP Identity Ifc 192.168.11.2:443, idle 0:00:04, bytes 34278, flags UOB

TCP outside 192.168.5.2:25844 NP Identity Ifc 192.168.11.2:22, idle 0:00:00, bytes 157719, flags UOB

After few mins when i did

ciscoasa# show conn all | inc Identity

ciscoasa#

It does not show anything

but when i do sh conn all

ciscoasa# show conn all

3 in use, 201 most used

TCP outside 192.168.98.10:65313 NP Identity Ifc 192.168.11.2:443, idle 0:00:00, bytes 335675, flags UOB

TCP outside 192.168.98.10:65310 NP Identity Ifc 192.168.11.2:443, idle 0:00:02, bytes 61900, flags UOB

TCP outside 192.168.5.2:25844 NP Identity Ifc 192.168.11.2:22, idle 0:00:00, bytes 201287, flags UOB

Here is shows 2 connections via ASDM.

Do you know after few mins sh conn | inc identity shows no output and sh conn all shows 2 connections to ASDM?

Regards

MAhesh

Hi,

Lets look at the first output

ciscoasa# show conn all | inc Identity

UDP outside 192.168.11.1:123 NP Identity Ifc 192.168.11.2:65535, idle 0:01:50, bytes 96, flags -

TCP outside 192.168.98.10:65323 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 531, flags UfrOB

TCP outside 192.168.98.10:65322 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 521, flags UfrOB

TCP outside 192.168.98.10:65321 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 406, flags UfrOB

TCP outside 192.168.98.10:65319 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 536, flags UfrOB

TCP outside 192.168.98.10:65313 NP Identity Ifc 192.168.11.2:443, idle 0:00:00, bytes 50003, flags UOB

TCP outside 192.168.98.10:65310 NP Identity Ifc 192.168.11.2:443, idle 0:00:04, bytes 34278, flags UOB

TCP outside 192.168.5.2:25844 NP Identity Ifc 192.168.11.2:22, idle 0:00:00, bytes 157719, flags UOB

UDP outside 192.168.11.1:123 NP Identity Ifc 192.168.11.2:65535, idle 0:01:50, bytes 96, flags -

The first seems to be a NTP connection. Its an UDP connection so the default timeout for UDP connection is 2min. As you can see its already been idle 1min 50 seconds so its really closed to being removed from the firewall connection table.

TCP outside 192.168.98.10:65323 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 531, flags UfrOB

TCP outside 192.168.98.10:65322 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 521, flags UfrOB

TCP outside 192.168.98.10:65321 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 406, flags UfrOB

TCP outside 192.168.98.10:65319 NP Identity Ifc 192.168.11.2:443, idle 0:00:58, bytes 536, flags UfrOB

With the above connections it seems to me that they are TCP connections (possibly part of some TCP connections related to ASDM) Notice the end section with the TCP "flags". From these we can see that the TCP connections are already in the process of being teardown. In other words they are not in use anymore but in the process of being closed and removed from the connection table of the ASA.

The flags to look out for are

r - inside acknowledged FIN

f - inside FIN

TCP outside 192.168.98.10:65313 NP Identity Ifc 192.168.11.2:443, idle 0:00:00, bytes 50003, flags UOB

TCP outside 192.168.98.10:65310 NP Identity Ifc 192.168.11.2:443, idle 0:00:04, bytes 34278, flags UOB

TCP outside 192.168.5.2:25844 NP Identity Ifc 192.168.11.2:22, idle 0:00:00, bytes 157719, flags UOB

And as you can see with the last 3 connections, they are the same TCP connections that are left in the second output. This is because they seem to be in use still and there is no TCP flags that would indicate they are in the process of being teardown.

You can see explanation of all the different connection "flags" while  issuing the command "show conn all" and checking out the top most  portion (example output from my ASA)

ASA(config)# sh conn detail

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

       B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,

       D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,

       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,

       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response

       k - Skinny media, M - SMTP data, m - SIP media, n - GUP

       O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,

       q - SQL*Net data, R - outside acknowledged FIN,

       R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,

       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,

       V - VPN orphan, W - WAAS,

       X - inspected by service module

Here is also a good page telling the different most common connection flags you see on the ASA.

http://ccnpsecurity.blogspot.fi/2011/11/asa-flags-associated-with-tcp.html

Hope this helps

- Jouni

Also to add,

One other great command related to connections is to use the

show conn long

show conn long all

It shows a lot more information about the connections

Like

  • How long the connections has been on the ASA "uptime"
  • What the applied timeout value for the connection is "timeout"
  • Source and Destination NAT. If IP address and the one following in "()" are the same then no nat has been done, or atleast the address hasnt been changed.

- Jouni

Hi jouni,

Seems you provided me lot of useful info today.

I will go through all this info before i move further.

Regards

Mahesh

Review Cisco Networking for a $25 gift card