pix 515e DMZ

This is a well worn problem, but I am not picking up the tricks which allow traffic to the dmz. I want to allow

primary allow

1) www/https from anything outside to the dmz 2) ssh from the inside to the webserver 3) 53/udp from webserver to known external dns hosts 4) 123/udp from webserver to known external ntp hosts

secondary allow

1) ssh from a defined source to the webserver 2) ssh from a defined source to a specific internal host, 192.168.0.21

here's my current config : Saved PIX Version 6.3(3) interface ethernet0 auto interface ethernet1 100full interface ethernet2 auto nameif ethernet0 outside security0 nameif ethernet1 inside security100 nameif ethernet2 dmz security30 enable password 7HdMXPMNkRbJ1zyt encrypted passwd XOqQSgghqw/XrF5S encrypted hostname ***name*** domain-name r3g.net fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 fixup protocol http 80 fixup protocol pptp 1723 fixup protocol rsh 514 fixup protocol rtsp 554 fixup protocol sip 5060 fixup protocol sip udp 5060 fixup protocol skinny 2000 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol tftp 69 names name 192.168.0.15 **insidehost** name xx.xx.239.23 firewall name 192.168.10.1 service name 192.168.10.3 webserver access-list service permit tcp any host firewall eq www access-list service permit tcp any host firewall eq https access-list service permit icmp any interface dmz access-list outside permit udp host 10.100.192.1 host firewall eq bootpc access-list outside permit tcp any host webserver eq www access-list outside permit tcp any host webserver eq https access-list outside permit icmp any any echo-reply access-list outside permit icmp any any unreachable access-list outside permit icmp any any time-exceeded pager lines 24 logging on logging timestamp logging standby logging buffered debugging logging trap notifications logging facility 19 logging host inside **iinsidehost** icmp permit any echo-reply outside icmp permit any time-exceeded outside icmp permit any unreachable outside icmp permit any inside mtu outside 1500 mtu inside 1500 mtu dmz 1500 ip address outside firewall 255.255.255.192 ip address inside network 255.255.255.0 ip address dmz service 255.255.255.0 ip audit info action alarm ip audit attack action alarm no pdm history enable arp timeout 14400 global (outside) 1 interface nat (inside) 1 192.168.0.0 255.255.255.0 0 0 access-group outside in interface outside route outside 0.0.0.0 0.0.0.0 xx.xx.239.1 1 timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225

1:00:00 timeout h323 0:05:00 mgcp 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 aaa-server LOCAL protocol local http server enable http 192.168.0.0 255.255.255.0 inside snmp-server host inside **insidehost** snmp-server location ccna_closet snmp-server enable traps tftp-server inside **insidehost** /pix floodguard enable telnet timeout 5 ssh 192.168.0.0 255.255.255.0 inside ssh timeout 60 console timeout 0

terminal width 80 Cryptochecksum:ff291fef2f248d7dd0ae1e442a17df6c : end

Reply to
geewiz
Loading thread data ...

Dnia 2007-05-21 06:11 geewiz napisa?(a):

Because traffic from interface with lower security level can't flow to interface with higher security level by default. You must create access-list to allow them so You did. Your access-list 'outside' permit tcp connections (OSI model layer 4), but You forgot to permit ip protocol (OSI model layer 3).

Try insert this one: access-list outside line 1 permit ip any host webserver

Now try to do else :)

Reply to
Remigiusz Kosztowny

m, but I am not picking up the tricks which

You are partly correct, traffic from lower sec level cannot flow to higher sec level without proper configuration. However the suggestion that the problem can be solved by adding a permit IP line in addition to permit TCP is just plain wrong. This will not solve the problem but instead open a bigger "hole" that needed in the firewall. Permit TCP is the way to go, I've used this approach hundreds of time for all sorts of applications. HTTP/80, HTTPS/443, FTP it all works. A proper example to allow everyone to access a web server would be permit tcp any "web server public IP" eq www. The main addition here is however a static entry. A line that maps an external IP to an IP on the DMZ. Example static (DMZ,INTERNET) "Public IP", "DMZ IP"

The static and the permit tcp rule will do the trick if the server is set up right.

Regards Fredrik

Reply to
Hoffa

Dnia 2007-05-21 15:26 Hoffa napisa?(a): [...]

Of course, I have knew it but have no time to correct myself. I'm so sorry, my first reply was a little stupid :)

Geewiz, try this one (I wrote it from my head, without testing):

! access-list to allow NAT from dmz host(s) to outside access-list DMZ permit ip host 192.168.10.3 any nat (dmz) 2 access-list DMZ ! static to nat from outside to dmz ! xx.xx.239.yy is a public IP, Your webserver from outside static (dmz,outside) tcp xx.xx.239.yy 80 192.168.10.3 80 static (dmz,outside) tcp xx.xx.239.yy 443 192.168.10.3 443

! permit for access from outside to dmz access-list IN_OUTSIDE permit tcp any host xx.xx.239.yy eq 80 access-list IN_OUTSIDE permit tcp any host xx.xx.239.yy eq 443

Regards, R.

Reply to
Remigiusz Kosztowny

from anything outside to the dmz

Thanks! I got it working for a short while until three brief power outages seem to have dorked with something. All interfaces seem to be working except for the one path from world into DMZ. Internal out to world works. Internal to DMZ works. Very puzzling.

Reply to
geewiz

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.