News: This forum is now permanently frozen.
Pages: [1]
Topic: uresponsive NATed services  (Read 3015 times)
« on: April 14, 2008, 17:45:28 »
indywall *
Posts: 7

Hi Monowall Users:

I've encountered a puzzling problem with Monowall v1.233.

[BACKGROUND]

Here is my setup:

Internet <--> Router <--> Monowall <--> LAN

Router WAN IP: EXTERNALIP
Router LAN IP: 192.168.0.1/24
Monowall WAN IP: 192.168.0.254/24
Monowall LAN IP: 192.168.1.1/24
LAN subnet: 192.168.1.0/24

I have a number of inbound NAT (port forwarding) entries on my router (an ISP supplied SMC-Gateway v4.02.09-TWC). For example:

EXTERNALIP:25 --> 192.168.0.254:25

On Monowall I have corresponding mappings that forward each NATed service to a box on my LAN. Continuing the above example:

192.168.0.254:25 --> 192.168.1.15:25, where 192.168.1.15 is a mail server on my LAN.

There is a corresponding firewall rule set up on monowall to allow this traffic to pass through.

[PROBLEM]

This configuration WORKS GREAT at first but then stops working after 1 or 2 days; that is, inbound traffic to NATed services is silently dropped. Outbound traffic and responses are not affected at all. A reboot of both the router and monowall does not fix this problem!

When I take monowall out of the picture and fix the router NAT entries to point directly to the respective machines on the LAN then the problem goes away. Even worse, if I nuke the monowall config (and/xor wait several days) and try the setup again it works for a day then breaks in exactly the same way.

The only other possible symptom I've seen is duplicate ping responses from my router (only when the WAN side is pinged).  I don't know if this is related to the problem because it persists after I take monowall out of the picture.

Does anyone have an idea about what's causing this problem with my NATed services?

Thanks in advance,
Tim

P.S. Sorry for originally posting this in the wrong forum.
« Reply #1 on: April 14, 2008, 20:18:15 »
ChainSaw
Guest

you need to put your ISP's router in bridge mode so your m0n0wall's WAN interface has your public IP not a private 192.something address.  Also, if you have PPPOE, you will need to configure your m0n0wall's WAN to do the login.

CS...
« Last Edit: April 14, 2008, 20:29:14 by ChainSaw »
« Reply #2 on: April 14, 2008, 20:35:20 »
indywall *
Posts: 7

you need to put your ISP's router in bridge mode so your m0n0wall's WAN interface has your public IP not a private 192. address.

CS...

I wish I could. Our ISP has limited that option on the router. The only thing I can do is use NAT.

Do you think that not having the router in bridge mode explains why my configuration from the original post works for a day then stops?

The reason I'm asking is that I've set monowall to allow non-routable IP addresses on the WAN side so the private 192. address shouldn't matter. Also, my router shouldn't care because all the 192.'s are still on it's LAN side.
« Reply #3 on: April 14, 2008, 20:53:52 »
ChainSaw
Guest

have you asked your ISP if they can put your modem in bridge mode?  I understand you are not able to make this change yourself but your ISP should be able to.  Also, I wouldn't take a "No" from the first level support person.  Ask to speak to a manager.  It may not help but it sure can't hurt.  If they still refuse, I would remove your m0n0wall as it does you very little good with another NAT router in front of it.

CS...
« Last Edit: April 14, 2008, 23:51:12 by ChainSaw »
« Reply #4 on: April 15, 2008, 16:49:35 »
indywall *
Posts: 7

I want to run monowall for the captive portal functionality so even though it's behind a NAT router it will still do us some good.

Your advice is good but what bothers me about getting my ISP to switch to bridge mode is that if monowall fails then I'll be stuck with my network offline waiting for my ISP to switch my router back.

Monowall has the following option which suggests that its OK to run monowall with its WAN in a private address space.
Quote
Block private networks
When set, this option blocks traffic from IP addresses that are reserved for private networks as per RFC 1918 (10/8, 172.16/12, 192.168/16) as well as loopback addresses (127/8). You should generally leave this option turned on, unless your WAN network lies in such a private address space, too.

I just want to know why monowall doesn't work consistently in a chained NAT situation like I described in the original post. It would be one thing if it didn't work at all - I would accept that. However, it works only for a short period of time then breaks. This suggests a problem with monowall. It's this problem that I am trying to solve.
« Reply #5 on: April 15, 2008, 22:10:07 »
indywall *
Posts: 7

Well, I'm going to recreate the problem this weekend and sniff all the packets on the wire while it is happening. Hopefully doing this will shed light on the issue. I'll keep this thread updated with my progress.

Btw, thanks for your ideas ChainSaw. I appreciate it.
« Reply #6 on: April 15, 2008, 23:27:35 »
ChainSaw
Guest

but what bothers me about getting my ISP to switch to bridge mode is that if monowall fails then I'll be stuck with my network offline waiting for my ISP to switch my router back.

Spare hardware to backup most m0n0wall systems ranges from very inexpensive to free so I would recommend you keep a spare around and backup your config before and after every config change.  To restore your latest config on your spare box should take no longer than five minutes.

As to why it works for a day then quits, I don't have a clue.  I personally would focus on getting it set up correctly then worry about fixing any remaining problems.

Will check back to see how it's going.

Good Luck, CS...

« Reply #7 on: April 21, 2008, 17:21:31 »
indywall *
Posts: 7

Well, I seem to have it working now. It's been running fine since Friday night.

I'm using a combination of 1:1 NAT and proxy ARP. Here's how:

1) Inbound NAT on my router to map ports to internal IP's on 192.168.0/24
2) 1:1 NAT on monowall that maps each affected 192.168.0.*/32 to a 192.168.1.*/32 address.
3) Proxy ARP to allow monowall to masquerade as each 192.168.0.*/32 address in step 2

Thanks again for your help CS.

-Tim
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines