Block LAN access to DMZ

[gelcom]

Hi guysm sorry for the newbie question but here I go:

Here is my setup:

WAN - ISP Internet
LAN - 192.168.1.1/24
OPT1 - 192.168.2.1/24

The problem is that I want to block all access from LAN to OPT1. This seams simple to do but I can´t figure it out what I´m doing wrong.

On the LAN rules I tried as the first rule:

ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 * LAN net * OPT1 net * * none                                 Block LAN access to OTP1

I also tried as my first rule:

ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 * *         * OPT1 net * * none                                 Block LAN access to OTP1

I also tried as my first rule:

ID Proto Source Port Destination Port Gateway Queue Schedule Description
TCP  *         * OPT1 net * * none                                 Block LAN access to OTP1

With no success. Then I tried to set the block rule on OPT1 rules with no luck too:

ID Proto Source Port Destination Port Gateway Queue Schedule Description
        IPv4* LAN net * *                 * *         none           Block OPT1 access from LAN

I also tried

ID Proto Source Port Destination Port Gateway Queue Schedule Description
        IPv4* ! OPT1 net * *                 * *         none           Block OPT1 access from LAN

What am I doing wrong?

If I try to access 192.168.2.50 from any device on 192.168.1.0 LAN  I go trough… what am I doing wrong?

kind regards
GWRosenbaum

[KOM]

By default, LAN has access to everything.  The default rule looks like this:

ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 *     LAN net  *      *            *      *        none            Default allow LAN to any rule

To block access to OPT1, simply change this rule so that the Destination is WAN net instead of *.

ID Proto Source Port Destination Port Gateway Queue Schedule Description
IPv4 *     LAN net  *      WAN net      *      *        none            Default allow LAN to any rule

[johnpoz]

Don't think I would do it that way.  Way I read that rule is lan could only go to things on the wan network, so for example my wan is 24.13.176.0/22 – so if wanting to go to 8.8.8.8 that rule would not trigger.

Better to do a "! opt1 net" (not) as dest.

[KOM]

My understanding of pfSense is a patchwork at best, but I thought that 'WAN net' was literally the entire Internet.  Or is 'WAN net' only the local subnet that your WAN IP address belongs to?  If the latter then I can't see the usefulness of 'WAN net' at all.

[johnpoz]

Depends on how your using it, if just routing on some internal network or where its placed in your network its very possible you might wan to limit something to only wan net.  Think of it this way, if your going to list interface address, interface network – why would you exclude an interface from this model?

It can also be used for a source, where again the wan is not the whole internet but just a segment on someones network.

Do you have this rule in your network, and your lan clients can talk to 8.8.8.8 for example?

[KOM]

Thanks.

No, I have mine configged differently.  DMZ is cordoned off from WAN entirely, with a few port-forwards and some specific rules so that DMZ'd servers can reach our LAN DNS and AV server etc, as well as serve externally.  My DMZ servers never need to reach out to WAN on their own.

[KOM]

Try this rule instead of the one I suggested:

ID  Proto  Source  Port  Destination  Port  Gateway  Queue  Schedule  Description
IPv4 *      LAN net  *      !OPT1 net    *      *        none              Default allow LAN to any rule

The ! means NOT, so make sure you check the Not checkbox in the Destination section of the rule.

[gelcom]

Don't think I would do it that way.  Way I read that rule is lan could only go to things on the wan network, so for example my wan is 24.13.176.0/22 – so if wanting to go to 8.8.8.8 that rule would not trigger.

Better to do a "! opt1 net" (not) as dest.

It doesn't work either …

I have just 1 rule for LAN as suggested:

ID  Proto  Source  Port  Destination  Port  Gateway  Queue  Schedule  Description
      IPv4* LAN net * ! OPT1 net  *   *             none         Allow LAN to any other but OPT1

I have no rules on OPT1

I still can access OPT1 addresses from LAN. If I try to connect to 192.168.2.40 (OPT1 address) from 192.168.1.5 (LAN) it connects.

When I connect this opt1 address from LAN I have the following history on PFsense Firewall Log:

Act Time If Source Destination Proto
pass Sep 4 16:22:56 LAN  192.168.1.5:49538  127.0.0.1:3128 TCP:S
pass Sep 4 16:22:56 LAN  192.168.1.5:49537  127.0.0.1:3128 TCP:S

There is no LOG on OPT1 side though... Why this happens?

What am I doing wrong?

Please help ...

kind regards

[KOM]

Define "access".  What are you doing specifically from LAN to OPT1?

You're only going to see a log from the interface the traffic comes IN on.

Your log bit shows a redirect to 3128.  Are you running Squid proxy?

[gelcom]

I have an IP Phone connected to OPT1 and I don't want it to be acessible from LAN but if I try to access Phone's config system on OPT1 it does connect…

I do have squid proxy running on LAN and OPT1

[KOM]

Is it possible that you're getting a cached version of your VoIP config page?

[gelcom]

I dont think so because if I try to access it from another computer on LAN it connects too …

[KOM]

Well, if you're running Squid in Transparent mode then the other computer would be using it too by default.  I don't believe this is your problem but I always rule out the easy stuff first.

Is this a brand new install?

Could we get a real screenshot of your LAN rules screen?

[johnpoz]

" LAN  192.168.1.5:49538  127.0.0.1:3128 "

Your not connecting to the opt1 your connecting to the proxy.  Tell you proxy not to go there either!

So you have a proxy setup on your client on the lan network.  So your client asks the proxy to go there, your machine is not directly going there ;)

The question is good are you using transparent proxy or explicit?  If explicit you should be set to bypass local networks anyway, and just set your opt1 network to be bypassed as well.  But you don't have any rules that says the proxy can not go there is your problem.

[KOM]

I wasn't sure if the firewall would get in between the LAN client and Squid or not.

[johnpoz]

no his rule says he can go anywhere as long as is not the opt1 network.  So clearly he can talk to the lan ip that proxy is listening on.  He asks the proxy hey got to this opt1 address.  Proxy is the source of that traffic, not lan IP.

If he wants to use a proxy, then not only does he have to worry about firewall rules - he also needs to make sure the proxy blocks what he wants blocked.

[gelcom]

I have squid proxy + havp running.

Squid proxy is in transparent mode.

attached config. pictures


[gelcom]

I disabled SQUID and now the block rule is working 100%! Now I can see Pfsense log files blocking the access but I don´t want to disable SQUID. I noticed that SQUID has an option that is supposed to bypass proxy for local addresses as above:

Bypass proxy for Private Address Space (RFC 1918) destination
Do not forward traffic to Private Address Space (RFC 1918) destination through the proxy server but directly through the firewall.

I turned SQUID on again and I set this option ON but with no luck… I can still access OPT network from LAN when SQUID is on.

There is another option to manually set which addresses SQUID will bypass proxy by destionation. I also set an specific OPT IP address on that but no luck either...

Bypass proxy for these destination IPs
Do not proxy traffic going to these destination IPs, CIDR nets, hostnames, or aliases, but let it pass directly through the firewall. Separate by semi-colons (;). [Applies only to transparent mode]

Any ideas on how to keep SQUID running and disable OPT access from LAN?

kind regards

[johnpoz]

"Do not forward traffic to Private Address Space (RFC 1918) destination through the proxy server but directly through the firewall. "

This would be the setting you would want - that should work.  I could simulate your setup when I get a chance - but that should work.

[gelcom]

It worked after a system reboot. Thanks!!