cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
563
Views
5
Helpful
4
Replies

DMZ Question, though I believe the answer lies in NAT...Please see attached diagram

rickcorriveau
Level 1
Level 1

I have an ISP that has given us a 32 IP Block (30 IPs addressable). I have a switch which the inside interface of the ISP router is connected to. From another port on this switch I have connected to the Outside interface of the ASA. All this works as expected with no issues.

 

We have been asked to setup a second connection using another IP address from this block that needs to be in the DMZ. The router that will be supplied will establish a tunnel. We need to supply them the public IP and gateway as well as the internal IP before they ship the router to us. So I created a DMZ port on this firewall and connected that to a new router that can establish a tunnel. I used a private network and have a /30 IP scheme between this new router and the DMZ interface of the firewall. This too works fine. I can ping the inside and outside interfaces of the firewall wall as well as external web addresses.

 

The goal is to allow remote support connect to this new router via their established VPN tunnel to manage our servers on our internal network. What I cannot get to work currently is a ping from our internal network to the 172.16.6.2 DMZ address. I can see the packets hitting the firewall and a connection setup and teardown in the logs. I am sure I am making this out to be more complicated than it needs to be but the last thing I want to do it mess up the config of an active firewall.

Built inbound ICMP connection for faddr 10.5.9.1/4 gaddr 172.16.6.2/0 laddr 172.16.6.2/0

Teardown ICMP connection for faddr 10.5.9.1/4 gaddr 172.16.6.2/0 laddr 172.16.6.2/0

 

What I am not getting, is any replies. I am thinking this is a NAT issue more than a routing issue. I do have a route in my core stating 172.16.6.0 /30 10.5.100.110 /16 which the inside ip address of our firewall is 10.5.100.110.

 

I have not setup any NAT statements for the DMZ yet as I am not sure if I need to setup a static NAT or a dynamic NAT. I just need traffic that is destined from the 10.5.x.x /16 to the 172.16.6.x /30 to be forwarded to this DMZ. I also need to make sure that any traffic from this DMZ network can access our internal network.  Of course once this is working I plan to lock down the specific ports they require. 

Since this is an active firewall with a separate VPN already established I cannot affect any traffic that is already setup to use the existing outside interface of the firewall.

I have attached a sanitized screen shot of my logical layout for a clearer understanding of my question.  Thank you very much in advance.

1 Accepted Solution

Accepted Solutions

Hi,

As per my understanding your source IP is 10.5.x.x which is internal and the destaintion IP 172.16.6.x which is in DMZ please correct me if I am wrong.

I belive you have set the capture on the DMZ as well with the source as 10.5.x.x and destination as 172.16.6.x. Ideally we should see the outgoing packets destined to 172.16.6.x in the cap0 capture but in your case we are not seeing any packets in outgoing captures. it could be any reason like captures are not set correctly, packet forwarding to different interface, or a NAT becasue of which the IP chnages.

We should see the same packets which are seen in capi in cap0 to confirm the asa is forwarding.

Could you take the packet tracer output from the firewall to see the flow of the packet. 

packet-tracer input <incoming interface name> icmp <source IP> 8 0 <destination IP> detail

Thanks,
Shivapramod M
Please remember to select a correct answer and rate helpful posts

View solution in original post

4 Replies 4

Rishabh Seth
Level 7
Level 7

Hi,

From the logs it looks icmp is working fine as the ASA is creating connection.

Built inbound ICMP connection for faddr 10.5.9.1/4 gaddr 172.16.6.2/0 laddr 172.16.6.2/0

Teardown ICMP connection for faddr 10.5.9.1/4 gaddr 172.16.6.2/0 laddr 172.16.6.2/0

>> Now it is  possible that the reply is not coming back or request is routed to wrong interface.

You can try checking the icmp packets in captures:

commands to take capture:

cap capi interface <name of ingress interface> match icmp host <source-ip> host <destination-ip>

cap capo interface <name of egress interface> match icmp host <source-ip> host <destination-ip>

To view:

show cap capi det

show cap capo det

To delete capture:

no cap capi

no cap capo

These captures will help you analyze how the ICMP is flowing in your network.

>> Also enable icmp inspection: command: fixup protocol icmp

Hope it helps,

Thanks,

RS

Rate if it helps!!!

I'll give that a try, thanks.  Yes, I agree it appears the reply is not getting back to the inside LAN.

Hi,

As per my understanding your source IP is 10.5.x.x which is internal and the destaintion IP 172.16.6.x which is in DMZ please correct me if I am wrong.

I belive you have set the capture on the DMZ as well with the source as 10.5.x.x and destination as 172.16.6.x. Ideally we should see the outgoing packets destined to 172.16.6.x in the cap0 capture but in your case we are not seeing any packets in outgoing captures. it could be any reason like captures are not set correctly, packet forwarding to different interface, or a NAT becasue of which the IP chnages.

We should see the same packets which are seen in capi in cap0 to confirm the asa is forwarding.

Could you take the packet tracer output from the firewall to see the flow of the packet. 

packet-tracer input <incoming interface name> icmp <source IP> 8 0 <destination IP> detail

Thanks,
Shivapramod M
Please remember to select a correct answer and rate helpful posts

Just expected.  It's getting to 172.16.6.2 but it cannot return.

=================================================================================================

show cap capi det

4 packets captured

   1: 22:13:37.133522 0015.63dd.18c0 0023.5ee5.d145 0x0800 74: 10.5.9.0 > 172.16.6.2: icmp: echo request (ttl 127, id 28938)
   2: 22:13:42.021391 0015.63dd.18c0 0023.5ee5.d145 0x0800 74: 10.5.9.0 > 172.16.6.2: icmp: echo request (ttl 127, id 29000)
   3: 22:13:47.023222 0015.63dd.18c0 0023.5ee5.d145 0x0800 74: 10.5.9.0 > 172.16.6.2: icmp: echo request (ttl 127, id 29101)
   4: 22:13:52.029737 0015.63dd.18c0 0023.5ee5.d145 0x0800 74: 10.5.9.0 > 172.16.6.2: icmp: echo request (ttl 127, id 29177)

=================================================================================================

 show cap cap0 det

0 packet captured

0 packet shown

=================================================================================================

Review Cisco Networking products for a $25 gift card