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 still facing the same issue. what's strange though is that despite the top deny rule that  drops all traffic from dmz to internal network, i can still telnet to port 80 (from DMZ to internal network)

I think that exactly the situation you have described on your earlier post. Is there a way to fix that?

PS I've followed the instructions  with no luck

Do you have the HTTP Proxy in transparent mode?  That might account for that behavior with telnet on port 80 if you don't have blocks set in Anti-Spam.

I'm curious, did the "Internet" definition trick stop the pings to the internal network from the DMZ?

Cheers - Bob

yes the operational is set to transparent mode (not full transparent). I've tried telnet from DMZ to port 21 and 80 and both are allowed. The strange thing is that I can the see the pf log and the traffic is set to block  (when trying random ports). Ping is still allowed when I set //192.168.2 under the blocked list (I can untick the Allow ICMP through firewall option and DMZ is unable to ping internal zone but internal zone is able to ping DMZ!)

however, port 80 and port 21 are still allowed if i telnet from DMZ to internal zone

21:56:18	Packetfilter rule #1	TCP	
172.16.1.2	:	52445
→	
192.168.2.31	:	25
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:56:21	Packetfilter rule #1	TCP	
172.16.1.2	:	52445
→	
192.168.2.31	:	25
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:56:27	Packetfilter rule #1	TCP	
172.16.1.2	:	52445
→	
192.168.2.31	:	25
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:56:51	Packetfilter rule #1	TCP	
172.16.1.2	:	52448
→	
192.168.2.31	:	487
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:56:54	Packetfilter rule #1	TCP	
172.16.1.2	:	52448
→	
192.168.2.31	:	487
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:57:00	Packetfilter rule #1	TCP	
172.16.1.2	:	52448
→	
192.168.2.31	:	487
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:57:19	Packetfilter rule #1	TCP	
172.16.1.2	:	52449
→	
192.168.2.31	:	8000
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:57:21	Packetfilter rule #1	TCP	
172.16.1.2	:	52449
→	
192.168.2.31	:	8000

21:57:28	Packetfilter rule #1	TCP	
172.16.1.2	:	52449
→	
192.168.2.31	:	8000
len=111	ttl=110	tos=0x00	srcmac=00:00:00:00:00:00	dstmac=00:b0:c2:02:e3:c7
21:57:40	Packetfilter rule #1	TCP	
172.16.1.2	:	52452
→	
192.168.2.31	:	8000
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:57:43	Packetfilter rule #1	TCP	
172.16.1.2	:	52452
→	
192.168.2.31	:	8000
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:57:49	Packetfilter rule #1	TCP	
172.16.1.2	:	52452
→	
192.168.2.31	:	8000
[SYN]	len=48	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89
21:58:00	Packetfilter rule #1	TCP	
172.16.1.2	:	52454
→	
192.168.2.31	:	8080
[SYN]	len=52	ttl=127	tos=0x00	srcmac=00:b0:c2:02:e4:4f	dstmac=00:1f[:D]0:0a:9a:89

however, port 80 and port 21 are still allowed if i telnet from DMZ to internal zone

Interesting.  Maybe you could try adding a logged packet filter rule at the top: 'DMZ -> HTTP -> Internal (Network) : Allow' and see if the port 80 traffic is being accepted before the PF rules.  If the traffic doesn't show up in the PF log, then that would be proof that it's being captured by the proxy as I suspect.  I would guess than any service can be used by telnet if it's in 'Allowed target services' on the 'Advanced' tab of 'Web Security >> HTTP/S Proxy'.

I'm not sure why the block is allowing the traffic.  What happens in the Content Filter (HTTP) log?

Cheers - Bob

Interesting.  Maybe you could try adding a logged packet filter rule at the top: 'DMZ -> HTTP -> Internal (Network) : Allow' and see if the port 80 traffic is being accepted before the PF rules.  If the traffic doesn't show up in the PF log, then that would be proof that it's being captured by the proxy as I suspect.  I would guess than any service can be used by telnet if it's in 'Allowed target services' on the 'Advanced' tab of 'Web Security >> HTTP/S Proxy'.

I'm not sure why the block is allowing the traffic.  What happens in the Content Filter (HTTP) log?

Cheers - Bob

JUst to add to my previous port. I am also able to telnet to port 8080 and 3128 (I have a pf rule that allows Private_Lan -->web surfing-->any allow). WEb surfing ports are : 8080,3128,443 (port 80 is only set to http proxy)

Haven't tried out your suggested action yet Bob.I am planning to do it during the weekend

I just setup a DMZ for a ShoreTel VPN Concentrator yesterday, and I'm having the exact same issue where it seems that the device on the DMZ can contact hosts on the LAN, even though I have setup the first Packet Filter rule to drop all traffic from the DMZ to the Internal network.

I have tried it both with and without HTTP security/proxying turned on, and traffic still seems to be allowed, despite the rule.

Conversely, I have tried setting up a rule to block traffic FROM the Internal LAN to the DMZ, and that works fine.

Anyone have a solution yet?

Thanks!

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

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.