Packet Filter Rules not taking effect

dspender · #1 (**permalink**) 06-26-2009, 09:30 PM

Started out with a rule:

Server-in-DMZ >> web ports (80,443) >> ANY Network

can telnet from DMZserver on 443,80 to any server on local and external nets. (and use firefox)

Added rule:

Server-in-DMZ >> LDAP (389,636) >> Server-in-PrivateLAN

nothing, tried:

Server-in-DMZ >> LDAP >> Private LAN Network

nothing, tried:

DMZ >> ANY >> Private LAN Network

NOTHING, added:

Private LAN Network >> ANY >> DMZ

still nothing.... however port 80,443 traffic still goes through fine - all other traffic is blocked... tried 25, 389, 636 and some other internal websites where they start out as 80 (works) and it bumps you to 81 (timeout).

I just don't know where to start troubleshooting. It seems like I'm missing something really simple but since web traffic is making it across fine I know everything is setup right, it seems like a glitch!!

BAlfson · #2 (**permalink**) 06-26-2009, 10:27 PM

What packets are being blocked in the packet filter log? Also, depending on your IPS settings, you may be running afoul of it. Take a look in that log if you don't find what you need in the PF log.

If you are using the HTTP Proxy and you allow the DMZ to access it, then (80,443) traffic is getting through because of it.

I'm curious why you would want to allow unrestained HTTP/S access by the DMZ to your internal network.

Cheers - Bob

dspender · #3 (**permalink**) 06-27-2009, 12:41 AM

Thanks for the ideas... we're not using the proxy for the DMZ interface.

All the packets are being blocked in the PF log. For instance:

2009:06:26-15:31:43 thetube ulogd[3496]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" seq="0" initf="eth1" outitf="eth1" dstmac="00:21:5a:4e:f9:1c" srcmac="00:15:17:8a:fb:74" srcip="10.3.0.15" dstip="10.1.1.227" proto="6" length="60" tos="0x10" prec="0x00" ttl="63" srcport="60364" dstport="389" tcpflags="SYN"

But with a rule like the following as a Packet Filter exception:

DMZ Interface >> ANY >> PrivateLAN Interface

How is that possible? As I said, any rule I had previously made works fine but the new ones don't. For instance I had the following rules:

DMZ >> PING >> PrivateLAN
DMZ >> DNS >> PrivateLAN
Certain-DMZ-Server >> 80,443 >> ANY

ALL these still work. I can ping, DNS, web from the DMZ interface no problem. However ANY new rule I create concerning the DMZ does not function. It is incredibly strange.

I checked the IPS - there's nothing there....

RFCat_vk · #4 (**permalink**) 06-27-2009, 12:06 PM

Hi,
do you mean you aren't using the proxy at all or just aren't using it for the DMZ?
PING will work without a rule because of the settings in Network security -> ICMP settings. To stop PING you will need to disable all settings in this tab. A thread already exists covering this issue.

DNS will depend on how you have the ASG setup with DNS forwarders etc.

What are the priorities assigned to the DMZ rules, are they below or above a block any rule?

Ian M

dspender · #5 (**permalink**) 06-27-2009, 05:36 PM

Just aren't using it for the DMZ, we are using the proxy for our Private LAN.

I don't block/deny any traffic by rule at the moment. The Astaro denies everything by default and I poke small (unless troubleshooting) restrictive holes in it to allow what I want.

What's odd is that all the previous rules I have set up are working fine. For instance I have an IIS server in the DMZ that I setup rules for SQL/Domain traffic through to servers in our Private LAN and its working fine.

I *almost* think that if I rebooted everything would be fine.... just a hunch. But frankly I am tired of fixing issues with my Astaro by rebooting. I would rather FIX it for real....

BAlfson · #6 (**permalink**) 06-27-2009, 06:12 PM

The line from your PF log does indeed show that the packet was blocked after all PF rules were considered. I can't recall any thread here in the last six months where that was a bug rather than a mis-configuration, so that's probably what we should be looking for.

Quote:

DMZ Interface >> ANY >> PrivateLAN Interface

This looks like you have specified the addresses of the interfaces instead of the networks. Did you mean 'DMZ (Network) -> Any -> Internal (Network) : Allow'?

Quote:

DMZ >> DNS >> PrivateLAN

I'm not sure why you would need/want this rule. The DNS Proxy is the best place to organize that; just be sure you have included your internal DNS server on the 'Forwarders' tab. If you don't have an internal DNS server, add 'DMZ (Network)' with 'Internal (Network)' to 'Allowed networks' on the 'Global' tab.

Quote:

Certain-DMZ-Server >> 80,443 >> ANY

That's interesting - What advantage does that give you as compared to allowing that server to use the HTTP Proxy?

CHeers - Bob

dspender · #7 (**permalink**) 06-28-2009, 03:03 PM

Yes I did mean DMZ:Network>>ANY>>Internal:Network

When I get everything setup how I want, I probably will look at the proxies, but I've found that for setup/testing its best to stick to simple rules and not make things more complicated right at the start - more to troubleshoot if things go awry.

In any case, my hunch was correct, and my boss's desire for a functioning network in the end (as it usually does) outweighed my desire to properly troubleshoot this issue.

Yes, I rebooted it and all is well.

This means that for some unknown reason the packet filter rules engine must have just whacked out... keeping its known ruleset and any modifications/additions did not have any effect. At least that explanation would be consistent with the limited testing I did and what I saw in the logs.

dspender · #8 (**permalink**) 06-28-2009, 06:18 PM

Another buggy issue that was happening that the reboot fixed (just fyi):

I couldn't get additional interfaces to activate. I had also been working on Multipathing and my second internet uplink would not show State:Up Link:Up... no matter what I did it was always State

own Link

own. I tried deleting the interface, recreating, different network cables, etc.

Since the reboot, that is fixed... shows UP:UP

I hate these wacky problems.