cannot access LAN from DMZ and vice versa

Answered Question
Apr 11th, 2008
User Badges:

Hello,


I have PIX 515E, version 6.1(4) and I'd like to allow all traffic from DMZ to LAN and vice versa but can't get it to work.

I do have nat, global, and acls configured but I must be doing something wrong.

And also for some reason, the machines inside the inside interface cannot go out to the internet (can't even ping anything outside) but the machines behind the DMZ can.


Any suggestions would be appricated!



Full running config:

PIX Version 6.1(4)

nameif ethernet0 outside security0

nameif ethernet1 inside security100

nameif ethernet2 dmz security40

enable password encrypted

passwd encrypted

hostname pix

domain-name pix.loc

fixup protocol ftp 21

fixup protocol http 80

fixup protocol h323 1720

fixup protocol rsh 514

fixup protocol rtsp 554

fixup protocol smtp 25

fixup protocol sqlnet 1521

fixup protocol sip 5060

fixup protocol skinny 2000

names

access-list 102 permit ip 10.10.31.0 255.255.255.0 10.10.16.0 255.255.255.0

access-list 103 permit ip 10.10.16.0 255.255.255.0 10.10.61.0 255.255.255.0

pager lines 24

interface ethernet0 auto

interface ethernet1 auto

interface ethernet2 auto

mtu outside 1500

mtu inside 1500

mtu dmz 1500

ip address outside x.x.x.x 255.255.255.0

ip address inside 10.10.16.1 255.255.255.0

ip address dmz 10.10.31.1 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (inside) 1 10.10.16.0 255.255.255.0 0 0

nat (dmz) 1 10.10.31.0 255.255.255.0 0 0

static (inside,dmz) 10.10.16.0 10.10.16.0 netmask 255.255.255.0 0 0

access-group 102 in interface inside

access-group 103 in interface dmz

route outside 0.0.0.0 0.0.0.0 x.x.x.x 1

timeout xlate 3:00:00

timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00

timeout uauth 0:05:00 absolute

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

no snmp-server location

no snmp-server contact

snmp-server community public

no snmp-server enable traps

floodguard enable

no sysopt route dnat

telnet timeout 5

Correct Answer by acomiskey about 9 years 3 months ago

Remember, there is an explicit deny statement at the end of your acl's. So they really look like this...


access-list 102 permit ip 10.10.31.0 255.255.255.0 10.10.16.0 255.255.255.0

access-list 102 deny ip any any

access-list 103 permit ip 10.10.16.0 255.255.255.0 10.10.61.0 255.255.255.0

access-list 103 deny ip any any


Therefore I don't see how even the dmz would be getting to the internet. This statement should take care of communication between the two interfaces.


static (inside,dmz) 10.10.16.0 10.10.16.0 netmask 255.255.255.0 0 0


edit: Good catch srue.


Correct Answer by srue about 9 years 3 months ago

no access-group 102 in interface inside

no access-group 103 in interface dmz


access-group 103 in interface inside

access-group 102 in interface dmz


------

btw, doing this negates any security provided by your dmz.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
srue Fri, 04/11/2008 - 09:28
User Badges:
  • Blue, 1500 points or more

no access-group 102 in interface inside

no access-group 103 in interface dmz


access-group 103 in interface inside

access-group 102 in interface dmz


------

btw, doing this negates any security provided by your dmz.

Correct Answer
acomiskey Fri, 04/11/2008 - 09:30
User Badges:
  • Green, 3000 points or more

Remember, there is an explicit deny statement at the end of your acl's. So they really look like this...


access-list 102 permit ip 10.10.31.0 255.255.255.0 10.10.16.0 255.255.255.0

access-list 102 deny ip any any

access-list 103 permit ip 10.10.16.0 255.255.255.0 10.10.61.0 255.255.255.0

access-list 103 deny ip any any


Therefore I don't see how even the dmz would be getting to the internet. This statement should take care of communication between the two interfaces.


static (inside,dmz) 10.10.16.0 10.10.16.0 netmask 255.255.255.0 0 0


edit: Good catch srue.


pixnewb11 Wed, 04/16/2008 - 16:18
User Badges:

Thanks guys, I finally got around to looking at this again.

So I've made the changes that both of you suggested and it's working now.


ACLS:

access-list 102 permit ip 10.10.31.0 255.255.255.0 10.10.16.0 255.255.255.0 (hit

access-list 102 permit ip 10.10.31.0 255.255.255.0 any


ACCESS-GROUPS

access-group 102 in interface dmz


STATIC:

static (inside,dmz) 10.10.16.0 10.10.16.0 netmask 255.255.255.0 0 0


I've taken out the access-list 103 since the inside interface has access to dmz by default.


What does "static (inside,dmz) 10.10.16.0 10.10.16.0 netmask 255.255.255.0 0 0

" do?


Is it saying that the traffic (actual subnet is 10.10.31.0) from dmz entering the inside interface will be mapped to 10.10.16.0?

Then do the nodes from dmz appear as they're from 10.10.16.0 IP wise?


And how come I don't need to do one for static (dmz,inside)? I'm assuming it has to do with the interface's security level?


Thanks!

acomiskey Wed, 04/16/2008 - 16:56
User Badges:
  • Green, 3000 points or more

You actually want to be more specific with your acl, otherwise you've defeated the purpose of a dmz.


access-list 102 permit tcp/udp 10.10.31.0 255.255.255.0 10.10.16.0 eq xxx

access-list 102 deny ip 10.10.31.0 255.255.255.0 10.10.16.0 255.255.255.0

access-list 102 permit ip 10.10.31.0 255.255.255.0 any


"static (inside,dmz) 10.10.16.0 10.10.16.0 netmask 255.255.255.0" will exempt your inside subnet from nat so they will appear on the dmz as their real address.

Actions

This Discussion