General Questions

Hello,

After using 3 m0n0walls for a long time, yesterday I ran into a (small) problem, I cannot solve. Maybe someone can help me.

I added a manageable switch to Opt1 and want to reach the GUI of it from LAN - and don't find out how to do this..

Given:

Monowall with 3 NICs on Alice Board:

LAN 192.168.0.6 (static)
WAN 192.168.178.20 via DHCP from DSL-Router
OPT1 192.168.1.1 (static)

All nets have subnet-Mask 255.255.255.0

Opt1 serves for Internet-Terminals. The only connection to LAN is to some printers in LAN, everything else to LAN is blocked.

Now I added a new switch in OPT1 net with 192.168.1.5 (to reach the GUI of it)


My firewall rules:
LAN:
First: all things, that are allowed,
at last: the rejecting and blocking rules.

Before the rejects and blocks I added a rule:
"allow: proto:* source:LAN port:any destination:opt1net port:any"
Didn't work. Same with destination:192.168.1.5

So additionally I looked for an incoming rule in the firewall rules of opt1:
After the rule for accessing the printers I have 2 other rules:
1st: the block rule to LAN:
block proto:* source:opt1 net  port* destination:LAN port:*

2nd: the rule, primary intended to allow the access to internet:
allow: proto:* source:opt1 net port* destination:* port:*

I imagine, that this rule also allows incoming traffic from lan to opt1 (?).


But to be sure, additionally I added a rule:
"allow: proto:* source:LAN port:* destination:opt1 net  port:*

This didn't help too.


Additionally I asked myself, if m0n0wall didn't know how to route from LAN to OPT1 and tried defining several static routes - but this also didn't help and I deleted them again, as the routing vice versa from OPT1 to the Printers in LAN does work without a static route, too.

And now I'm stuck - and hope, someone can help me.

Especially if using opt1 as a DMZ someone from LAN must reach a mail server in DMZ for example. So my problem isn't very special, I think..

Thank you,
Knut

Hello,

I believe this is one of the classic rule issues. You have to remember:
1. Rules are evaluated on a first-match basis
2. Everything that isn't explicitly passed is blocked by default.
This means that if you use block rules, you'll have to pay attention to the rule order.

Your LAN rules seem fine to me (if 'all things, that are allowed' includes a rule to allow packets to anything in OPT1) although the blocking rules aren't necessary (see 2).
This means your switch can send packets to anything in OPT1.

Your OPT1 rules: Now there is the problem with the rule order. You are blocking anything to LAN. And that's it. Your packets to LAN are dropped. The rule below it has no effect on it.
Delete the second rule and add a rule before the first one that allows packets to your manageable switch.
This means clients in OPT1 can send packets to your switch in LAN.

Your switch in LAN has to be able to answer requests to clients in OPT1 the same as clients in OPT1 have to be able to send requests to the switch in LAN. This doesn't work the same way as NAT where you just 'punch a hole through the firewall' and then it's open.

Hope I could help.

Edit: Sorry for the massive amount of edits.

Hello,

Your OPT1 rules: Now there is the problem with the rule order. You are blocking anything to LAN. And that's it. Your packets to LAN are dropped. The rule below it has no effect on it.

I thought, if the web-frontend of the switch in OPT1 is "answering" to a connection, that is started from the LAN, then this blocking rule does not apply (?)

Perhaps is this my fault?

BTW: I'll try your suggestions, next time - but I think, that I still had tried a test-scenario  without any blocking rule on OPT1... so my hope is not too big, that it will help..

BTW2: Is it possible, that the problem has something to do with default gateways? How does m0n0wall handle them? My idea is, that not the rules are the reason for not working, but that the answering packets of the switch are sent to internet instead to lan?
On the other hand: Printing from OPT1 to LAN does work - but here the connections are initiated from Opt1..  maybe, there's a problem with a default gateway, that only is relevant for answered packages from LAN? Is this possible?  (The default gateway in the switch's settings is the OPT1 port of m0n0wall: 192.168.1.1).

Thank you,
Knut

Hello,

I have uploaded a screenshot of my OPT1 Firewall rules here:

http://private-cities.gmxhome.de/Firewall-Rules%20OPT1.jpg

Short explanations:
- "OPT1" is renamed to "Internet PCs" here.
- the rejecting rules are added because they work much more faster

Blocking is from Internet-PCs only to LAN, so incoming connections from LAN should not be blocked by this (?).

The last rule allows everything - primarily for internet access, but also incoming connections from LAN should be allowed by this (?)

The rule above (LAN to switch GUI 192.168.1.5) is for testing only. It shouldn't be neccessary because of the last rule.

Thanks,
Knut

I thought, if the web-frontend of the switch in OPT1 is "answering" to a connection, that is started from the LAN, then this blocking rule does not apply (?)

As stated before, it doesn't work the same way as NAT does.

For sure, packets that have passed a rule on the outgoing network (e.g. LAN/OPT1) will not have to go through the rules of the destination network.
But now comes the important part: You are sending a packet/request from a client to your switch. The switch has to be able to answer to this request and this answer is just another packet. It's not handled differently by m0n0wall because it is a response. But because it's from another network you have to have rules for this scenario on both networks.

I'm sure there are many firewall guides that explain this much better than I can.

BTW2: Is it possible, that the problem has something to do with default gateways? How does m0n0wall handle them? My idea is, that not the rules are the reason for not working, but that the answering packets of the switch are sent to internet instead to lan?

You should have no problems with that as long as your clients and your switch have m0n0wall as their gateway.

Blocking is from Internet-PCs only to LAN, so incoming connections from LAN should not be blocked by this (?).

The last rule allows everything - primarily for internet access, but also incoming connections from LAN should be allowed by this (?)

The rule above (LAN to switch GUI 192.168.1.5) is for testing only. It shouldn't be neccessary because of the last rule.

Firewall rules are always for incoming packets from m0n0wall's perspective. This "LAN to 192.168.1.5" rule has no effect on incoming packets from LAN. For that you'd have to use the LAN tab.

It's important that you understand:
1. Packets from your client in OPT1 to your switch in LAN are handled on the OPT1 tab because they are incoming packets seen from m0n0wall's perspective on the OPT1 network.
2. Packets from your switch in LAN to your client in OPT1 are handled on the LAN tab because they are incoming packets seen from m0n0wall's perspective on the LAN network.

This means you have to have two rules but on different networks. One that allows packets to your switch and one that allows packets to your clients:
1. OPT1:

Proto	Source	Port	Destination	Port
*	OPT1 network	*	<ip of your switch in LAN>	*

2. LAN:

Proto	Source	Port	Destination	Port
*	<ip of your switch in LAN>	*	OPT1 network	*

And these rules have to be above any rule that would block these packets. In your case that means above your rejecting rules.

I hope this clears things up a bit.

I could explain it in German as well if you want me to.

Edit: The switch is in the LAN network... sorry.

This means you have to have two rules but on different networks. One that allows packets to your switch and one that allows packets to your clients:
1. OPT1:

Proto	Source	Port	Destination	Port
*	OPT1 network	*	<ip of your switch in OPT1>	*

2. LAN:

Proto	Source	Port	Destination	Port
*	<ip of your switch in OPT1>	*	OPT1 network	*

And these rules have to be above any rule that would block these packets. In your case that means above your rejecting rules.

Thank you very much - I tried everything from the above and much more - it does not work.
I even deactivated all blocking-rules and put on the opt1 side, where the switch is connected to, all kinds of allow-rules to the top, so that no blocking rule (even a deactivated one) can be active.

- allow everything from everywhere on every port to any destination
- allow everything from opt1 on every port to anything on opt1 net
- allow everything from lan on every port to anything on opt1 net
- allow everything from opt1 on every port to switch-ip
... and so on

no success.

On LAN i tried everything like:
allow everything from LAN on any port to opt1 net
allow everything from LAN on any port to switch-ip (in opt1 net)
alloe everything from everywhere on any port to everywhere..
and much more..

Nothing works.

Possibly the m0n0wall has a bug?

The installed version is 1.33, for alix boards.

Thanks,
Knut

BTW: Did you mean Rule1 from your table as it is written there? Source and destination in the same net? (I tried this too on the opt1 side, but also no success).

I misunderstood you completely: I thought the switch is in LAN and your clients are in OPT1.

Anyway, if you want to reach the switch in OPT1 from a client in LAN the following firewall rules would be necessary:

1. LAN:

Proto	Source	Port	Destination	Port
*	LAN network	*	<ip of your switch in OPT1>	*

2. OPT1:

Proto	Source	Port	Destination	Port
*	<ip of your switch in OPT1>	*	LAN network	*

But you said you've tried "open everything" rules so I believe this is a problem with your switch. Maybe your switch is set up to block packets from other networks (for instance my VoIP box has an option to prevent accessing the GUI from another network)?
I don't think this is a bug in m0n0wall.

Have you had a look at your firewall logs after trying to access the GUI of your switch? Maybe you could paste them here as well.