topic NAT DMZ to an internal address in Network Security

NAT DMZ to an internal address

Turkey Twizzler — Tue, 12 Mar 2019 07:17:55 GMT

Hello,

I've spent hours going round in circles trying to work out what I'm doing wrong here. I have a server in the DMZ on one ASA 5512 interface, and an internal network on a different one. What I want to do is to make the DMZ host accessible on the internal network using an internal IP address.

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

eg:

DMZ ASA interface: 192.168.10.1

DMZ server: 192.168.10.2

Internal ASA interface: 172.16.10.11

DMZ host on internal: 172.16.10.12 (not a real machines IP)

----------

I am able to configure the NAT so that the DMZ server (192.168.10.2) can ping an internal host by adding a NAT rule that changes the source address from 192.168.10.2 to 172.16.10.12.

What I am unable to achieve is the opposite, where an internal machine (172.16.10.x) is able to ping 172.16.10.12, and have NAT change the destination address to 192.168.10.2

I have enabled the intra-interface thing & the log now shows it setting up an ICMP transaction between 172.16.10.xxx and 172.16.10.12, but Wireshark doesn't show any traffic turning up on the DMZ host.

I've tried using the packet tracer, which looks as though it's using the same interface (internal) for ingress & egress, but I'm not sure if I've read that right.

I'm thoroughly confused. Any assistance would be appreciated.

Thank you.

Do you have to use NAT in

Philip D'Ath — Sun, 14 Feb 2016 19:06:16 GMT

Do you have to use NAT in this case? Could you not just let users access the 192.168.10.x address directly? That would make life much easier.

Unfortunately I can't do it

Turkey Twizzler — Sun, 14 Feb 2016 20:19:46 GMT

Unfortunately I can't do it the easy way!

I'm adding the firewall to an existing network VLAN, which previously had a host that required internet connectivity (172.16.10.12) which in turn exposed the entire VLAN.

The host ip (and the other hosts on the network) cannot change because of other complications (legacy system).

To solve the problem I want to put the host in the DMZ, and NAT to it to make it look like its still on the same network.

I guess from your reply it is at least possible!?

Make sure you have access

Philip D'Ath — Sun, 14 Feb 2016 20:28:28 GMT

Make sure you have access rules allowing the ICMP traffic. A basic example using object nat is:

object network server
  host 192.168.10.2
object network server
  nat (dmz,inside) static 172.16.10.12

Access rules allow everything

Turkey Twizzler — Sun, 14 Feb 2016 23:47:41 GMT

Access rules allow everything (from 'all' to 'all' for ip & icmp) on both interfaces. I set this just by adding a rule in ASDM, which defaults to quite open. In my case, TCP didn't work either (the host has a webserver on it, for instance).

I thought I'd tried a NAT entry like that (I 'think' because I've tried so many variations, mainly using ASDM and the public server feature). I'll give it another go though.

If I (do I?) understand your rule correctly; from DMZ to Inside, the source gets changed from 192- to 172-. From inside, the 172... gets the destination set to 192... and chucked on the DMZ interface. This I've definitely tried. The result was that DMZ to Internal was all ok. ICMP & TCP were fine. ICMP/TCP the other way round though didn't work. The syslog showed that the transactions were setup on the firewall for both ICMP & TCP, but wireshark shows no packets get through (and no deny logs either).

The only thing I've spotted with the transaction log is that the IPs were 172.16.10.(any) to 172.16.10.12(host) - I don't know whether the this is what's expected (ie the host address is logged with the un-nat'd address), or whether it indicates it's erroneously hairpinning & the NAT has failed.

Thanks for your help so far.

What appears in the ASDM log

Philip D'Ath — Sun, 14 Feb 2016 23:51:16 GMT

What appears in the ASDM log when you do the ping? It will say if packets are being dropped and why.

%ASA-7-609001: Built local

Turkey Twizzler — Mon, 15 Feb 2016 11:56:58 GMT

%ASA-7-609001: Built local-host INSIDE-VLAN:172.16.10.14
%ASA-7-609001: Built local-host INSIDE-VLAN:172.16.10.12
%ASA-6-302013: Built inbound TCP connection 210706 for INSIDE-VLAN:172.16.10.14/49203 (172.16.10.14/49203) to INSIDE-VLAN:172.16.10.12/)

{wait}

%ASA-7-710005: UDP request discarded from 0.0.0.0/68 to INSIDE-VLAN:255.255.255.255/67
%ASA-6-302014: Teardown TCP connection 210706 for INSIDE-VLAN:172.16.10.14/49203 to INSIDE-VLAN:172.16.10.12/80 duration 0:00:30 bytest
%ASA-7-609002: Teardown local-host INSIDE-VLAN:172.16.10.14 duration 0:00:30
%ASA-7-609002: Teardown local-host INSIDE-VLAN:172.16.10.12 duration 0:00:30

I dont think the discarded UDP request is relevant in this instance (DHCP from somewhere?)
It only denies ICMP & TCP if intra-interface is not set.
ICMP echo-request packets are sent by any 172 clients, the ASA responds to the necessary ARP request for the 172.16.10.12 virtual host, but doesn't forward the traffic.

The "built inbound connection" line says it's created INSIDE-INSIDE. Shouldn't this say INSIDE->DMZ ?

Thanks.

Hi,

Rishabh Seth — Mon, 15 Feb 2016 12:04:08 GMT

Hi,

Could you please run packet tracer for the traffic and verify which NAT rule is evaluated and share the same.

Thanks,

Here's the output. I think

Turkey Twizzler — Mon, 15 Feb 2016 13:18:49 GMT

Here's the output. I think you're on to something. It doesn't look like nat is doing anything...?

# packet-tracer input INTERNAL-VLAN icmp 172.16.10.15 $

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
in 172.16.10.0 255.255.255.0 INTERNAL-VLAN

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group Internal-VLAN_access_in in interface INTERNAL-VLAN
access-list Internal-VLAN_access_in extended permit object-group DM_INLINE_PROTOCOL_3 any any
object-group protocol DM_INLINE_PROTOCOL_3
protocol-object ip
protocol-object icmp
Additional Information:

Phase: 3
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
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: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 9
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 212218, packet dispatched to next module

Result:
input-interface: INTERNAL-VLAN
input-status: up
input-line-status: up
output-interface: INTERNAL-VLAN
output-status: up
output-line-status: up
Action: allow

When I run the trace in the other direction, the NAT rule given above is run OK.

Thanks for your help!

Hi,

Rishabh Seth — Mon, 15 Feb 2016 13:38:53 GMT

Hi,

From the provided packet tracer it looks like there is no NAT happening.

Here is what I would like to know:

>> Is the source and destination belong to same subnet?

>> Are you trying to translate the traffic coming from Internal-vlan and this traffic should be sent to a device on DMZ?

>> If this is the nat rule that you have created, then change it to manual NAT statement for testing purpose and place it on top so as to confirm there is no other conflicting NAT rules present.

object network server
host 192.168.10.2
object network server
nat (dmz,inside) static 172.16.10.12

Change it to :

example:

nat(dmz, Internal-vlan) 1 source static real-IP mapped-IP

Thanks,

That NAT rule you gave me has

Turkey Twizzler — Mon, 15 Feb 2016 14:03:10 GMT

That NAT rule you gave me has worked!!!... but I don't understand why!! Can you please explain the difference between the rule within the object and your manual statement?

The new packet trace has a different first step;

packet-tracer input INTERNAL-VLAN icmp 172.16.10.15 8 0 172.$

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,INTERNAL-VLAN) source static server int-server
Additional Information:
NAT divert to egress interface DMZ
Untranslate 172.16.10.12/0 to 192.168.10.2/0

>> Is the source and destination belong to same subnet?

Different subnets;

DMZ Host: 192.168.10.2 mask 255.255.255.0

Internal-VLAN: 172.16.10.0 mask 255.255.255.0

>> Are you trying to translate the traffic coming from Internal-vlan and this traffic should be sent to a device on DMZ?

Yes, and also the other way round.

Thank you very much!

just the transaction setup

Turkey Twizzler — Mon, 15 Feb 2016 14:05:03 GMT

[ Deleted ]

Reason: Replied to the wrong comment & it's making the thread confusing to follow.