cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
561
Views
0
Helpful
4
Replies

cannot access LAN from DMZ and vice versa

pixnewb11
Level 1
Level 1

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

2 Accepted Solutions

Accepted Solutions

srue
Level 7
Level 7

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.

View solution in original post

acomiskey
Level 10
Level 10

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.

View solution in original post

4 Replies 4

srue
Level 7
Level 7

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.

acomiskey
Level 10
Level 10

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
Level 1
Level 1

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!

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card