DMZ Hosts can connect to the internal hosts?

on the top of the pf there should be a deny from the dmz to the internal host

When i create a deny Rule:

Source: DMZ (Network)
Dest: Internal (Network)
Action: Drop

there is no function... I can reach the interal hosts... ??

I am currently trying different configurations to solve that issue. I will post when I find a solution

Even though I don't have any rule that allows web traffic from DMZ to private lan it still goes through. I don;t have DMZ on the allowes hosts of HTTP/S

it's strange :s

Jtarnoff, did you put the blocking rule at the top of your list of packet filter rules?  Remember that, like most everything in the Astaro, PF rules are processed sequentially, and the rest are skipped when the traffic pattern is matched.

One thing is certain, and that is that this is not an Astaro bug; this must be an unintended consequence of some conguration item.

If you have a logged block or alllow rule at the top and see no application of the rule in the PF log, then you have proof that the traffic is being allowed by automatic packet filter rules in a proxy or NAT.  If it does appear in the log, then you know that one of the following PF rules is allowing the traffic.

Cheers - Bob

I have the blocking (traffic from DMZ to Internal Zone is rejected not Dropped) rule on the top to block all traffic from DMZ to private Lan. All  traffic is blocked (tried telnet via random ports). However telnet on port 80 is still allowed but traffic is not logged on the pf. 

Telneting on port 8080,3128 is blocked by the pf but telnet works :s

21:18:04	Packetfilter rule #1	TCP	

172.16.1.2	:	49767

→	

192.168.2.31	:	3128

[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89

21:18:07	Packetfilter rule #1	TCP	

172.16.1.2	:	49767

→	

192.168.2.31	:	3128

[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89

21:18:13	Packetfilter rule #1	TCP	

172.16.1.2	:	49767

→	

192.168.2.31	:	3128

[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:

The only possible solution for this traffic to be allowed is via HTTP proxy (However I believe there is an issue since  port 8080 and 3128 are still allowed despite the fact that pf blocks them!!)

On the HTTP proxy I have blocked URL : \192.168.2.31 (the destination for the telnet test) but the traffic still is permit.


Can someone confirm in which way does Astaro checks the traffic? (ie first HTTP Proxy then pf etc)

NATS and proxies get the traffic first.

If you have the HTTP Proxy enabled in trasparent mode, and you allow the DNZ to use the proxy, then you give access from the DMZ to 'Internal (Network)' via port 80.

I'm pretty certain of that.

Cheers - Bob

That make sense and that'y I've blocked on the HTTPS DMZ proxy filter the \192.168.2.31 which is the specific hosts but the traffic still goes through.
I can try to change the DMZ proxy profile to Standard if that will make a change

I guess that would just change from 80 to 8080, but I haven't tried it, so if you do try it, please post your results here.

Have you tried putting \198.162.2 into 'Always block'?

Bob, is there a way to have the proxy not listen at all on the DMZ interface?

Barry

I think it listens to everything.

Wingman, if everything fails and you just want to block something. Just blackhole it via dnat. Dnat is always applied before everything. 

Here is how to dnat(screenshot attached)
Create a host that doesn't exist in the IP range of dmz
Create a rule dnat 
Source: Host that you want to block (I am blocking the whole dmz network)
Traffic service: service that you want to block (ping in this case)
destination: LAN (important if you only want to block lan, put any and block all)
NAT mode DNAT
Destination: Host that doesn't exist

You can block anything this way.

Bob, is there a way to have the proxy not listen at all on the DMZ interface?

You have to explicitly allow dmz to use proxy like any other proxy on astaro otherwise its denied by default.

P.S Also in my opinion, the block ping /traceroute  in the ICMP section of the packet filter should take care of icmp and traceroute and should block as advertised but it doesn't. ICMP is only blocked to the firewall and all the other buttons are just taking space doing nothing. Someone wants to submit a bug since its still non functional in 7.5beta... Maybe I will go and mention that

I am trying to understand the reason behind this issue as I still believe it's a bug related issue.

I 've now created a specific DMZ filter proxy where I block everything by default. PF has no rules associated to port 80,8080,3128 and DMZ Zone. 

I've tried to telnet and I got the result below:

2009:06:14-10:04:16 Astaro httpproxy[16603]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="172.16.1.2" user="" statuscode="400" cached="0" profile="REF_SMhzaanRSw (DMZ Internet Filter)" filteraction=" ()" size="2117" time="344 ms" request="0xb2363f00" url="" exceptions="" error="Received invalid request from client"

Astaro HTTPS log can see the traffic and is blocked, However telneting from DMZ zone to port 80 is still permitted.

I am trying to understand the reason behind this issue as I still believe it's a bug related issue.

I 've now created a specific DMZ filter proxy where I block everything by default. PF has no rules associated to port 80,8080,3128 and DMZ Zone. 

I've tried to telnet and I got the result below:

2009:06:14-10:04:16 Astaro httpproxy[16603]: id="0002" severity="info" sys="SecureWeb" sub="http" name="web request blocked" action="block" method="" srcip="172.16.1.2" user="" statuscode="400" cached="0" profile="REF_SMhzaanRSw (DMZ Internet Filter)" filteraction=" ()" size="2117" time="344 ms" request="0xb2363f00" url="" exceptions="" error="Received invalid request from client"

Astaro HTTPS log can see the traffic and is blocked, However telneting from DMZ zone to port 80 is still permitted.