- Posts: 68
- Thank you received: 0
Allow Traffic from host on DMZ to host on inside
16 years 1 month ago #27600
by sys-halt
Allow Traffic from host on DMZ to host on inside was created by sys-halt
I am trying to allow traffic from a Front-Edge Exhange Server Setting in the dmz to the Back-End Exchange Server setting in the inside.
the Front-Edge Server has IP: 192.168.2.4
the Back-End Server has IP: 172.16.1.7
the type of traffic I am interested in from both sides is:
1. RDP connection
2. SMTP Traffic
3. telnet Traffic
4. Ping traffic
If I am on the DMZ on the Front-End Server at 192.168.2.4 can I simply RDP or telnet my Back-End Server at 172.16.1.7 through the ASA 5505 without creating mapped IP. just by simply typing 172.16.1.7 in the RDP program to make the connection present?
ASA Version 7.2(3)
!
hostname ciscoasa
domain-name ciscoasa.com
names
!
interface Vlan1
no nameif
no security-level
no ip address
!
interface Vlan3
nameif inside
security-level 100
ip address 172.16.1.1 255.255.255.0
!
interface Vlan4
nameif dmz
security-level 20
ip address 192.168.2.1 255.255.255.0
!
passwd Ug8g0VU3lmtgMXoJ encrypted
ftp mode passive
dns domain-lookup inside
dns domain-lookup dmz
dns domain-lookup outside
dns server-group DefaultDNS
name-server my-ISP-DNS
domain-name ciscoasa.com
pager lines 24
mtu inside 1500
mtu dmz1 1500
mtu outside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
global (outside) 1 my-public-ip-range netmask my-public-ip-mask
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz1) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 perimter-router-ip 1
timeout xlate 3:00:00
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 uauth 0:05:00 absolute
aaa authentication ssh console LOCAL
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 inside
ssh timeout 60
console timeout 0
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
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 netbios
inspect rsh
inspect rtsp
inspect skinny
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:bddb41e49f09eee5b6411a002631664f
: end
the Front-Edge Server has IP: 192.168.2.4
the Back-End Server has IP: 172.16.1.7
the type of traffic I am interested in from both sides is:
1. RDP connection
2. SMTP Traffic
3. telnet Traffic
4. Ping traffic
If I am on the DMZ on the Front-End Server at 192.168.2.4 can I simply RDP or telnet my Back-End Server at 172.16.1.7 through the ASA 5505 without creating mapped IP. just by simply typing 172.16.1.7 in the RDP program to make the connection present?
ASA Version 7.2(3)
!
hostname ciscoasa
domain-name ciscoasa.com
names
!
interface Vlan1
no nameif
no security-level
no ip address
!
interface Vlan3
nameif inside
security-level 100
ip address 172.16.1.1 255.255.255.0
!
interface Vlan4
nameif dmz
security-level 20
ip address 192.168.2.1 255.255.255.0
!
passwd Ug8g0VU3lmtgMXoJ encrypted
ftp mode passive
dns domain-lookup inside
dns domain-lookup dmz
dns domain-lookup outside
dns server-group DefaultDNS
name-server my-ISP-DNS
domain-name ciscoasa.com
pager lines 24
mtu inside 1500
mtu dmz1 1500
mtu outside 1500
no failover
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
global (outside) 1 my-public-ip-range netmask my-public-ip-mask
nat (inside) 1 0.0.0.0 0.0.0.0
nat (dmz1) 1 0.0.0.0 0.0.0.0
route outside 0.0.0.0 0.0.0.0 perimter-router-ip 1
timeout xlate 3:00:00
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 uauth 0:05:00 absolute
aaa authentication ssh console LOCAL
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
telnet timeout 5
ssh 0.0.0.0 0.0.0.0 inside
ssh timeout 60
console timeout 0
!
class-map inspection_default
match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
parameters
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 netbios
inspect rsh
inspect rtsp
inspect skinny
inspect sqlnet
inspect sunrpc
inspect tftp
inspect sip
inspect xdmcp
!
service-policy global_policy global
prompt hostname context
Cryptochecksum:bddb41e49f09eee5b6411a002631664f
: end
16 years 1 month ago #27601
by sys-halt
Replied by sys-halt on topic Re: Allow Traffic from host on DMZ to host on inside
I was reading some Internet posts and saw the idea of "No Natting" which will allow by passing traffic from dmz to inside without a nat usage and ip mapping procedure.
here is what I got, I hope if someone could confirm the idea and spot which rule will work properly in my scenario:
First Scenario:
create a static:
static (inside,dmz) 172.16.1.0 172.16.1.0 255.255.255.0
but I am not sure if this is correct by putting the source and destination IP as my inside interface to allow "no-nat" traffic flow from dmz to inside.
Second Scenario:
Creating a nat 0 with access-list:
nat (dmz) 0 access-list no-nat
access-list no-nat permit ip 192.168.2.4 255.255.255.255 172.16.1.7 255.255.255.255
nat (inside) 0 access-list no-nat-dmz
access-list no-nat-dmz permit ip 172.16.1.7 255.255.255.255 192.168.2.4 255.255.255.255
thanks.
here is what I got, I hope if someone could confirm the idea and spot which rule will work properly in my scenario:
First Scenario:
create a static:
static (inside,dmz) 172.16.1.0 172.16.1.0 255.255.255.0
but I am not sure if this is correct by putting the source and destination IP as my inside interface to allow "no-nat" traffic flow from dmz to inside.
Second Scenario:
Creating a nat 0 with access-list:
nat (dmz) 0 access-list no-nat
access-list no-nat permit ip 192.168.2.4 255.255.255.255 172.16.1.7 255.255.255.255
nat (inside) 0 access-list no-nat-dmz
access-list no-nat-dmz permit ip 172.16.1.7 255.255.255.255 192.168.2.4 255.255.255.255
thanks.
16 years 1 month ago #27633
by S0lo
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
Replied by S0lo on topic Re: Allow Traffic from host on DMZ to host on inside
Hello sys-halt,
You need an access list to allow traffic to flow from a lower security level interface (dmz) to a higher security interface (inside). For your requirements, try this:
[code:1]access-list dmz_access_in extended permit tcp host 192.168.2.4 host 172.16.1.7 eq 3389
access-list dmz_access_in extended permit tcp host 192.168.2.4 host 172.16.1.7 eq smtp
access-list dmz_access_in extended permit tcp host 192.168.2.4 host 172.16.1.7 eq telnet
access-list dmz_access_in extended permit icmp host 192.168.2.4 host 172.16.1.7 echo
access-list dmz_access_in extended permit icmp host 192.168.2.4 host 172.16.1.7 echo-reply
access-group dmz_access_in in interface dmz[/code:1]
Double check the syntax please.
As far as I know, you don't need any IP translation using nat/global nor static forwarding in this case because your not accessing from/to a public IP range (outside). You typically do translation when going to or from the outside interface because the outside (internet) cannot route your private IP ranges (192.168.x.x and 172.16.x.x).
You can do the "nat (inside) 0" (no translation) as in your 2nd scenario but you will still need the access list to make it work. Because "nat (inside) 0" lets it work ONLY if the initiator of the connection was in the inside, not your case.
Any comments or corrections are welcome.
You need an access list to allow traffic to flow from a lower security level interface (dmz) to a higher security interface (inside). For your requirements, try this:
[code:1]access-list dmz_access_in extended permit tcp host 192.168.2.4 host 172.16.1.7 eq 3389
access-list dmz_access_in extended permit tcp host 192.168.2.4 host 172.16.1.7 eq smtp
access-list dmz_access_in extended permit tcp host 192.168.2.4 host 172.16.1.7 eq telnet
access-list dmz_access_in extended permit icmp host 192.168.2.4 host 172.16.1.7 echo
access-list dmz_access_in extended permit icmp host 192.168.2.4 host 172.16.1.7 echo-reply
access-group dmz_access_in in interface dmz[/code:1]
Double check the syntax please.
As far as I know, you don't need any IP translation using nat/global nor static forwarding in this case because your not accessing from/to a public IP range (outside). You typically do translation when going to or from the outside interface because the outside (internet) cannot route your private IP ranges (192.168.x.x and 172.16.x.x).
You can do the "nat (inside) 0" (no translation) as in your 2nd scenario but you will still need the access list to make it work. Because "nat (inside) 0" lets it work ONLY if the initiator of the connection was in the inside, not your case.
Any comments or corrections are welcome.
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
16 years 1 month ago #27636
by sys-halt
Replied by sys-halt on topic Re: Allow Traffic from host on DMZ to host on inside
thanks for the help s0lo. Tomorrow I will give it a try and test it. I will get back to you with the results. thanks again.
16 years 1 month ago #27665
by sys-halt
Replied by sys-halt on topic Re: Allow Traffic from host on DMZ to host on inside
I did try the code syntax you provided today and it worked just fine s0lo. thanks for the help. everything is now working as it should be.
thanks everyone.
thanks everyone.
16 years 1 month ago #27677
by S0lo
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
Replied by S0lo on topic Re: Allow Traffic from host on DMZ to host on inside
Glad to help
Studying CCNP...
Ammar Muqaddas
Forum Moderator
www.firewall.cx
Time to create page: 0.132 seconds