Charles Steinkuehler wrote:
>
> The DMZ network does NOT need to have any particular relationship to the
> internal network. The fact that when you put the DMZ 'inside' your internal
> network space, the DMZ is able to access the internet (and isn't able to
> otherwise) indicates the outbound masquerade rules are not getting generated
> for the DMZ.
Hi Charles, thanks very much for your response. Assuming that I had
badly misconfigured the box, I have downloaded E2B (EigerStein2BETA.exe)
again and started configuration from scratch.
After correcting my errors in DMZ_SERVERn entries and placing the DMZ on
a network separate from the two internal interfaces, the DMZ
configuration block looks like:
DMZ_SWITCH=PRIVATE
DMZ_IF="eth3"
DMZ_NET=172.20.0.0/16
DMZ_OUTBOUND_ALL=YES
DMZ_SERVER0="tcp ${EXTERN_IP} www 172.20.0.1 www"
DMZ_SERVER1="udp ${EXTERN_IP} www 172.20.0.1 www"
> The best place to check is the forward rules.There is normally
> a single masquerade rule hooking your internal network to the
> internet. With a private DMZ, you also have a rule masquerading
> the DMZ network to the internet, the internal network to the
> DMZ network, and several individual masquerade rules for the
> port-forwarded services of the DMZ, allowing them
> to be accessed via the public IP from the internal network.
After rebooting the firewall and calling 'svi network ipfilter list',
the forward chain looks like:
Chain forward (policy DENY: 0 packets, 0 bytes):
pkts bytes target prot opt tosa tosx ifname mark
outsize source destination ports
0 0 DENY icmp ----l- 0xFF 0x00 *
0.0.0.0/0 0.0.0.0/0 5 -> *
1480 206K MASQ all ------ 0xFF 0x00 eth0
192.168.0.0/16 0.0.0.0/0 n/a
0 0 DENY all ------ 0xFF 0x00 *
0.0.0.0/0 0.0.0.0/0 n/a
Chain output (policy DENY: 0 packets, 0 bytes):
--
>From your description, something is clearly misconfigured as none
of the rules supporting the private DMZ are evident. The behaviour is
as before (no connection into DMZ from anywhere, no outgoing
connections from DMZ):-(
I looked carefully through ipfilter.conf and can find no mention of a
setting of DMZ_SWITCH=PRIVATE to generate these rules.
[matt@puff matt]$ grep -i DMZ_SWITCH ipfilter.conf
if [ "$DMZ_SWITCH" = "YES" -o "$DMZ_SWITCH" = "Yes" \
-o "$DMZ_SWITCH" = "yes" ]; then
if [ "$DMZ_SWITCH" = "YES" -o "$DMZ_SWITCH" = "Yes" \
-o "$DMZ_SWITCH" = "yes" ]; then
if [ "$DMZ_SWITCH" = "YES" -o "$DMZ_SWITCH" = "Yes" \
-o "$DMZ_SWITCH" = "yes" ]; then
if [ "$DMZ_SWITCH" = "YES" -o "$DMZ_SWITCH" = "Yes" \
-o "$DMZ_SWITCH" = "yes" ]; then
[matt@puff matt]$ grep -i private ipfilter.conf
[matt@puff matt]$
Maybe this is my problem? Looking in the 'Introduction for Configuring
network.conf' Version 1.0 dated April 7, 2000, it suggests setting
DMZ_SWITCH=PRIVATE. Have I got the wrong end of the stick here? Or maybe
the wrong distribution?
I looked at an earlier diskimage (EigerStein_1_img_EigerStein.exe) and
the ipfilter.conf looks the same. I didn't try Dachstein rc2 floppy as
I'm hoping to stay with Eigerstein for now to use Jacques existing
packages for axfrdns etc.
If you have any advice for something to try (or more/better info I can
provide) I'd really appreciate it.
Thanks,
matt :-)
>
> If switching the DMZ on and off does not cause dramatic changes to the
> forward rule chain, something basic is wrong.
>
>
>>- and finally (and sorry for the newbie question) when accessing
>>services in the DMZ from the local network(s), should the actual IP
>>address of the server on the DMZ network or the external IP address of
>>the LRP box be used?
>>
>
> When everything is setup correctly, you should be able to access the
> services using the public IP.
>
> Charles Steinkuehler
> http://lrp.steinkuehler.net
> http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)
>
>
>
>
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
