News: This forum is now permanently frozen.
Pages: [1] 2
Topic: new DMZ no traffic at all :(  (Read 3421 times)
« on: April 25, 2012, 12:23:59 »
will *
Posts: 9

Hi I am setting up a DMZ on a soekris box but I am not getting any traffic on the interface at all.  LAN works fine and I am not able to see what is blocking DMZ.  any help would be great.

DMZ based on sample in docs and config looks like below.

DMZ
Proto   Source   Port   Destination   Port   Description   
       *    DMZ net    *    ! LAN net    *    DMZ to ALL bar LAN    
    *    *    *    LAN net    *    Reject DMZ traffic to the LAN    
   
WAN
Proto   Source   Port   Destination   Port   Description   
   *    RFC 1918 networks   *   *   *    Block private networks   
       TCP    *    80 (HTTP)    dmz-fusion    80 (HTTP)    NAT Fusion HTTP    
       TCP    *    22 (SSH)    dmz-fusion    22 (SSH)    NAT Fusion SSH    
       TCP    *    443 (HTTPS)    dmz-fusion    443 (HTTPS)    NAT Fusion HTTS    
       TCP    *    888    dmz-scathach    80 (HTTP)    NAT Scathach HTTP    
       TCP    *    222    dmz-scathach    22 (SSH)    NAT Scathach SSH    
   
LAN
Proto   Source   Port   Destination   Port   Description   
       *    LAN net    *    *    *    Default LAN -> any    
   
   
« Reply #1 on: April 25, 2012, 17:01:46 »
Fred Grayson *****
Posts: 994

When you specify a Source Port in firewall rules it is almost always a mistake. Change them to Any (*).

Where are your Firewall: NAT: Inbound rules?

--
Google is your friend and Bob's your uncle.
« Reply #2 on: April 25, 2012, 22:30:54 »
will *
Posts: 9

NAT Inbound

If   Proto   Ext. port range   NAT IP   Int. port range   Description   
WAN    TCP    22 (SSH)    dmz-fusion    22 (SSH)    Fusion SSH     
WAN    TCP    80 (HTTP)    dmz-fusion    80 (HTTP)    Fusion HTTP     
WAN    TCP    222    dmz-scathach    22 (SSH)    Scathach SSH     
WAN    TCP    443 (HTTPS)    dmz-fusion    443 (HTTPS)    Fusion HTTS     
WAN    TCP    888    dmz-scathach    80 (HTTP)    Scathach HTTP

thanks

W
« Reply #3 on: April 25, 2012, 23:05:56 »
tuxfux *
Posts: 32

A bit OT, but: i recommend to take another port for ssh than 22, so you can avoid a lot of ssh scan traffic. ok, you can't avoid it, but it's less likely that they find it.
« Reply #4 on: April 25, 2012, 23:09:14 »
Fred Grayson *****
Posts: 994

Have you changed the firewall rules to not specify the source port yet?

--
Google is your friend and Bob's your uncle.
« Reply #5 on: April 25, 2012, 23:38:19 »
will *
Posts: 9

with * (any) should I be setting ALL ports to go to the webserver or does m0n0wall pickup port based on destination rule?

There are a couple of servers in the DMZ, how does M0n0wall differentiate services?

cheers

W
« Last Edit: April 25, 2012, 23:51:10 by will »
« Reply #6 on: April 25, 2012, 23:59:41 »
Fred Grayson *****
Posts: 994

The Source Port refers to the port being used by the client on the other end of the connection, not on m0n0wall, and not on the destination server.

Source Ports used by the connecting client are randomly picked and therefore not possible to predict. If you specify a Source Port in a firewall rule and it does not match the port actually being used, the traffic will not be passed by the rule.


--
Google is your friend and Bob's your uncle.
« Reply #7 on: April 26, 2012, 00:49:11 »
will *
Posts: 9

Thanks for that, so based on the rules now with * (any) for source - this should pickup :80 and send to webserver one but how does it handle webserver two with PAT?

Also, the DMZ is not able to be pinged from inside the DMZ nor are DHCP addresses being allocated - servers are setup with correct IP config and default routes etc but seems like FW is blocking all that traffic?  No traffic gets in or out at all? 

I have other firewalls setup with Shorewall and IP Tables (Linux based) and thought I would try m0n0wall as it would be easier for tech customers to manage and works well on the little Soekris box - maybe I should go back to Linux lol

cheers

W

« Reply #8 on: April 26, 2012, 01:24:08 »
Fred Grayson *****
Posts: 994

If you have two webservers on the same unique IP address, they can not both be listening on the same port or ports. This does not appear to be the case in your setting so long as dmz-fusion and dmz-scathach resolve to two different IP addresses.

If you want the DMZ interface to be pingable, you must have a rule that allows it.

I'm not sure I understand your question about DHCP addresses not being allocated or what you mean by no traffic getting in or out.

If you do not have properly defined rules in place to allow traffic coming into an interface, it will be dropped. What are you seeing in your firewall log?

--
Google is your friend and Bob's your uncle.
« Reply #9 on: April 26, 2012, 01:27:39 »
will *
Posts: 9

Thanks does m0n0wall not to port translation ie: in on 888 and pass to 80 on DMZ?  I can alter the Apache setting to listen elsewhere but other firewalls I have dealt with did PAT ok. 

What rules are needed for DHCP and ping on DMZ?  I was assuming that enabling DHCP would create a rule?

Anyone have a DMZ setup with multiple servers that can show they rules?

cheers and thanks for your help so far great response!

W
« Reply #10 on: April 26, 2012, 01:51:36 »
Fred Grayson *****
Posts: 994

Your NAT of

WAN    TCP    888    dmz-scathach    80 (HTTP)    Scathach HTTP

does port translation.

If you have enabled the DHCP server on an interface, that's all you would need to do on m0n0wall. Any client connected computer configured to obtain an IP address automatically would need to allow that in its own firewall unless that is done automatically when requesting an address.

A firewall rule on the DMZ to allow pings could be as simple as:

Protocol: ICMP
Source Address: *
Source Port: *
Destination Address: DMZ interface address
Destination Port: *

It might be better to restrict this to specific ICMP types, but few bother with this. Also, is it really needed for the DMZ interface IP address to be pingable, or are you really wanting this on your WAN IP instead?

The m0n0wall handbook shows an example DMZ setup, but I am guessing you already have seen that.

Your's looks to be OK now assuming you have incorporated all suggestions.

One thing that you need to know about is that if you are testing things by using a machine in your LAN to connect to your WAN IP address (or a name that resolves to it) and expect to reach a machine in the DMZ, it will not work. You have to test from a machine out on the internet instead.

--
Google is your friend and Bob's your uncle.
« Reply #11 on: April 26, 2012, 10:27:08 »
will *
Posts: 9

$Your NAT of
$WAN    TCP    888    dmz-scathach    80 (HTTP)    Scathach HTTP
$does port translation.
Thanks, I will reinstate what I had for this, thanks.

$If you have enabled the DHCP server on an interface, that's all you would need to do on m0n0wall. Any client $connected computer configured to obtain an IP address automatically would need to allow that in its own firewall $unless that is done automatically when requesting an address.
Ok, best I keep debugging as something a bit iffy


$A firewall rule on the DMZ to allow pings could be as simple as:
$
$Protocol: ICMP
$Source Address: *
$Source Port: *
$Destination Address: DMZ interface address
$Destination Port: *
$
$It might be better to restrict this to specific ICMP types, but few bother with this. Also, is it really needed for the $DMZ interface IP address to be pingable, or are you really wanting this on your WAN IP instead?
I want to ping from DMZ machine to make sure I am getting a connection as at this stage I have no activity..  testing with ICMP alloweed and still no response


$The m0n0wall handbook shows an example DMZ setup, but I am guessing you already have seen that.
$
$Your's looks to be OK now assuming you have incorporated all suggestions.
$
$One thing that you need to know about is that if you are testing things by using a machine in your LAN to $connect to your WAN IP address (or a name that resolves to it) and expect to reach a machine in the DMZ, it will $not work. You have to test from a machine out on the internet instead.

Thanks, read through the docs and that has got me this far, just trying to work out why I am not getting a connection.. I am used to working at a console with debugging tools avail..  web interface feels restrictive but I am sure it is all there for me to learn and use.

At this stage I have a working WAN and LAN but nothing on DMZ (have confirmed physical port is ok by swapping with LAN allocation).  I have one server setup with new DMZ to test and other server setup with dual gateway to test live and assist with transition to new network.  I am at a bit of a loss at the moment.

thanks

W
« Reply #12 on: April 26, 2012, 15:46:59 »
Fred Grayson *****
Posts: 994

You might post a sanitized copy of your config.xml file as an attachment. Maybe someone will spot something in it.

--
Google is your friend and Bob's your uncle.
« Reply #13 on: April 27, 2012, 03:36:53 »
will *
Posts: 9

Thanks - xml file attached - any feedback very welcome

cheers

W

* rtr-config.txt (12.65 KB - downloaded 143 times.)
« Reply #14 on: April 27, 2012, 03:56:21 »
Fred Grayson *****
Posts: 994

These firewall rules still have the problem of having the Source Port specified as something other than Any:

<rule>
         <type>pass</type>
         <interface>wan</interface>
         <protocol>tcp</protocol>
         <source>
            <any/>
            <port>222</port>
         </source>
         <destination>
            <address>dmz-scathach</address>
            <port>22</port>
         </destination>
         <descr>NAT Scathach SSH</descr>
      </rule>

<rule>
         <type>pass</type>
         <interface>wan</interface>
         <protocol>tcp</protocol>
         <source>
            <any/>
            <port>888</port>
         </source>
         <destination>
            <address>dmz-scathach</address>
            <port>80</port>
         </destination>
         <descr>NAT Scathach HTTP</descr>
      </rule>

They will not work this way.

I didn't see anything else that was obviously incorrect. Maybe someone else will look and see if I missed anything else.

--
Google is your friend and Bob's your uncle.
 
Pages: [1] 2
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines