Firewall/NAT

I have been running a setup like this:

WAN - > LAN

1:1 mappings from WAN IP's to LAN IP's.

Specific Rules, such as
allow TCP 80 from WAN to LAN 10.2.2.4
allow TCP 21 from WAN to LAN 10.2.2.5
etc.
etc.

I just ran a port scan and to my suprise, all the ports on the 1:1 mapped machines were visible on the internet.  I could connect to remote desktop via the WAN IP.

This has never happened before, and I had to put this rule in the WAN rules:

Block any to any * * *

once I put that rule at the bottom of my ruleset, I could no longer connect to these other ports. I have around 40 rules permitting various ports to various machines.

Can someone help me understand what is going on;  why would monowall allow other ports through the firewall rules beyond the rules?

I thought that there was an implicit BLOCK and that rules permitted the "port holes" into the various LAN addresses.

Thanks!

See the m0n0wall Handbook, section 6.5. 1:1 NAT, for an explanation.

http://doc.m0n0.ch/handbook-single/#id11630497

Thanks, but I've been using Monowall for like 5 years, and have done port scans against my equipment, etc. and have never had this come up until a few days ago.  My configuration has always been to have the 1:1 combined with rules.  I even went back several years and looked at my rules, and none of them have had a "block rule" to blanket block all other traffic.

So I am confused as to why all of a sudden the 1:1 along with rules is allowing "all traffic" in, and a month or 1 year ago, it did not.

Is the proper solution to have the "blanket blocK" rule in there like I did on the WAN rules???

My understanding of 1:1 NAT is that all traffic is forwarded across the interface and the concepts of rules and port forwarding do not apply, hence the security warning in the handbook.

But I do not use 1:1 NAT myself, so I can't verify or refute the documented behavior.

The only thing I can think of is that something changed in the most recent version of monowall.

I recently upgraded that firewall to 1.3, after running 1.235 for a long time.

I am not sure exactly how to test this, but for YEARS I have operated in this scenario with 1:1 and rules and the only "port holes" open have been the ones I opened in rules...  I deployed out 1.3 about 10 days ago and then all the problems started with all ports on the machines being wide open.

I think the developers need to take a look at this.

I have to agree with RollingRock, when you 1:1 NAT, all ports are forwarded automatically, but you still have to create a firewall rule to let them in. So if you don't create any firewall rules for the 1:1, all ports are blocked basically.

I have a 1:1 Machine out the field that I can experiment with, it's running 1.3 m0n0wall and I'll report back here what I found.

The only thing I can think of is that something changed in the most recent version of monowall.

I recently upgraded that firewall to 1.3, after running 1.235 for a long time.

I am not sure exactly how to test this, but for YEARS I have operated in this scenario with 1:1 and rules and the only "port holes" open have been the ones I opened in rules...  I deployed out 1.3 about 10 days ago and then all the problems started with all ports on the machines being wide open.

I think the developers need to take a look at this.

Ok, I tested my machine out the field that was running websites/e-mail servers. As soon as I turned off the rules that allowed those ports in (80, 25, 110, etc.) all services quite responding. So there was no rule blocking or unblocking those ports and the default behavior was to block all outside connections.

When I turned the rule back on, I was able to access the websites and e-mail server again.

So I can confirm that the default behavior is still the same, 1:1 auto-forwards all the ports (so you don't need to make a ton of NAT rules), but until you create a firewall rule to allow traffic through, everything is blocked. 

Well, I guess that would be good input for an update to that section of the Handbook.

interesting... but all that leaves me back at square one as to why when I just went from 1.235 to 1.3, with the same rule set, it allowed "all ports" through until I added that block rule ().

it seems like my firewall hiccuped somehow and allowed everything through.

I guess my next step would be to drop the "block" rule I have in there and reboot the firewall and see what happens when it comes back online, whether it allows all ports through or not.

Very confused.

interesting... but all that leaves me back at square one as to why when I just went from 1.235 to 1.3, with the same rule set, it allowed "all ports" through until I added that block rule ().

it seems like my firewall hiccuped somehow and allowed everything through.

I guess my next step would be to drop the "block" rule I have in there and reboot the firewall and see what happens when it comes back online, whether it allows all ports through or not.

Very confused.

That's the opposite of what I experienced, so I'm not sure why. If you have no rules to allow access, everything is blocked by default. Until you create a firewall rule to allow people *in*, your server won't be accessible by anyone.

You are doing 1:1 NAT with an IP separate from m0n0wall though right? The m0n0wall machines I use have multiple WAN IPs assigned to them and I'm using 1:1 NAT on those other IPs and not the main IP of m0n0wall.

Correct.

Let's just say my monowall is IP X.X.X.2

My IP range is x.x.x.3 to x.x.x.30

I have 1:1 maps setup, from x.x.x.5 to 10.x.x.50, etc.

I have rules that allow specific holes open.  For ~5 years or more I have operated like this, and never had any issues or "unexpected ports" open to the world.  NEVER, nor have I ever had to use a "global block" rule.  I should also note that I am running on the same hardware; no changes in hardware, just a version upgrade.

I upgraded from 1.235 to 1.3 on 1/29/10 and then noticed what was going on "all machines wide open" like a week later.

the only way I stopped it was to add the global block rule at the bottom of my rule set.

what is interesting is that I wanted to do some more testing on the "wide open" issue and I deleted that global block rule - but then the "block" seems to still be in place because I can no longer get to the machines through the unexpected open ports (like Remote desktop)... of course I have yet to power cycle the firewall, but I plan on doing that late this weekend in the wee hours of the morning.

so it seems to me like something happened when I upgraded and then when I slightly altered the rules earlier this week, it "un-hiccuped" the IP filters to work properly.

the only way I am going to for certain know if this is cleared up is to:

1) remove the global block
2) power cycle the firewall

3) once if reboots, check to see if all ports are open or not.


Honestly, this whole incident makes me nervous about future monowall upgrades and odd behaviors.  I have lost a lot of time this week dealing with this issue.
 






 

Update:

tonight I have just completed removing the "block" global rule, and then rebooted the firewall.

After reboot, I attempted to connect to a few of the ports that are outside the rule set - and they do not connect, thus meaning the default "block" rule is working.

So now I am back where my rule set was on 1/31/2010 before I upgraded 1.235 to 1.3 - and it is not permitting any traffic to any unmapped port which is the way it had worked for years.

HOWEVER- there is still no explanation that I am aware of - other than monowall glitching - that caused the firewall to allow "all ports" through for a week or more.