News: This forum is now permanently frozen.
Pages: [1]
Topic: 1:1 NAT between WAN and DMZ doesn't work :(  (Read 4719 times)
« on: May 22, 2009, 16:02:52 »
Horus *
Posts: 6

Sorry for this newby question if that's the case, but I really don't know the answer....

I'm using version 1.3b16

I'm doing some tests and I'm following this chapter (http://doc.m0n0.ch/handbook/examples.html) to set up a DMZ for test.  My m0n0 settings are like this

LAN IP = 10.3.3.1/24
WAN IP = 10.6.6.1/24
DMZ IP = 10.9.9.1/24

In my DMZ, I've a web server with IP address = 10.9.9.9

I'd like to do a 1:1 NAT of this DMZ web server to 10.6.6.9 in WAN.  I've followed exactly what's written in that chapter:
Interface: WAN
External subnet: 10.6.6.9 / 32
Internal subnet: 10.9.9.9

But any PC in WAN just can't access my web server in DMZ.  What's the reason of my failure?  A bug in this version of m0n0?  Or because my WAN IP address is 10.6.6.x which is private address instead of public address?
« Last Edit: May 22, 2009, 19:19:02 by Horus »
« Reply #1 on: May 22, 2009, 19:16:59 »
Horus *
Posts: 6

I think I've found the answer to my own question.

Firstly, it turns out that my problem has nothing to do with WAN being in a private IP address range, 10.6.6.0/24.

Secondly, I was thinking if "Proxy ARP" has anything to do with this problem.  It also turns out to be YES!  This is needed!

So, what else is needed?  A firewall rule to WAN!  Shocked

More precisely, I had to add a rule on the WAN interface to accept packets.  My setting is like this:
Action : Pass
Interface : WAN
Protocol : any
Source : Type: any
Destination : Type: any

Of course, I could have made a more restricted rule, like limiting protocol to just TCP, etc.  But the essential point is that without a rule to WAN, "1:1 NAT" won't work!  Shocked Huh

I don't know if this is a bug in this version, or if this is a new "feature"... anyway, this isn't documented in the manual...

A side-note: when I put in a PC in the WAN, I already noticed that ping from this WAN PC to m0n0's WAN IP has no reply.  I at first thought this might be some security measure by default that m0n0 is NOT replying to ping on WAN IP, but it turns out that this rule also enables it to reply to ping on WAN.

I could upload the xml config file if anyone is interested in this problem.  My config is actually is simple.
« Last Edit: May 22, 2009, 19:20:22 by Horus »
« Reply #2 on: May 23, 2009, 13:06:27 »
Seb74 ***
Posts: 115

How come proxy arp is needed?
If traffic comes in for the router-interface, why doesn't it just route it to the webserver network...how come in this case proxy arp is needed?

In case you understand, I would like to know the theory behind that Smiley
« Reply #3 on: May 23, 2009, 13:42:22 »
Manuel Kasper
Administrator
*****
Posts: 364

Secondly, I was thinking if "Proxy ARP" has anything to do with this problem.  It also turns out to be YES!  This is needed!

That's correct - since you've set up a 1:1 NAT for an IP address that isn't m0n0wall's own (WAN) IP address, and there is also no upstream router that sends traffic for 10.6.6.9 to m0n0wall, you need proxy ARP so that m0n0wall will "claim ownership" of 10.6.6.9 via ARP.

I don't know if this is a bug in this version, or if this is a new "feature"... anyway, this isn't documented in the manual...

m0n0wall has always separated NAT and firewall rules, so it's correct and normal that you need to set up both a NAT and a firewall rule in this case. The auto-add feature for normal inbound NAT mappings (checkbox) is only there for convenience.

A side-note: when I put in a PC in the WAN, I already noticed that ping from this WAN PC to m0n0's WAN IP has no reply.  I at first thought this might be some security measure by default that m0n0 is NOT replying to ping on WAN IP, but it turns out that this rule also enables it to reply to ping on WAN.

m0n0wall's default ruleset is quite conservative, so among other things it also drops ICMP echo requests sent to it on the WAN interface. If the user wants it to respond to pings, it's always easy to add a firewall rule to permit just that.
« Reply #4 on: May 24, 2009, 17:01:54 »
Horus *
Posts: 6

That's correct - since you've set up a 1:1 NAT for an IP address that isn't m0n0wall's own (WAN) IP address, and there is also no upstream router that sends traffic for 10.6.6.9 to m0n0wall, you need proxy ARP so that m0n0wall will "claim ownership" of 10.6.6.9 via ARP.

Yeah, and as a matter of fact, when I create a 1:1 NAT, there's the default checked option of "Auto-add a proxy ARP..." at the bottom.

But is there any 1:1 NAT situation where this proxy ARP should not be set?  I mean, if such situation doesn't exist, maybe a proxy ARP entry must always be created (and hidden) to make it more transparent and easier to understand; so user doesn't have to scratch his head (and tear his hairs Smiley ) to think if any upstream router would route traffic to it.

I notice that in Interfaces > LAN and Interfaces > DMZ, there're Secondary IPs tabs.  But there's no such tab for Interfaces > WAN.  Maybe it would be easier, and clearer, if such function also exists for WAN?

I don't know if this is a bug in this version, or if this is a new "feature"... anyway, this isn't documented in the manual...

m0n0wall has always separated NAT and firewall rules, so it's correct and normal that you need to set up both a NAT and a firewall rule in this case. The auto-add feature for normal inbound NAT mappings (checkbox) is only there for convenience.

OK.  In that case, it is then necessary to change the doc to reflect such decision.  You see, I first followed the "Quick start guide" for generic PC at
http://doc.m0n0.ch/quickstartpc/
I've actually followed all 5 chapters to set up a two-NIC m0n0wall.  Everything's OK up to here.

Then I jumped to the manual on the part where it's explaining how to set up DMZ:
http://doc.m0n0.ch/handbook/examples.html
Since I use 1:1 NAT, I've especially read the section on Using 1:1 NAT and Test the 1:1NAT Configuration.  But after that, DMZ web server just doesn't work as expected.  This is very frustrating to new users.  Myself, I had to re-read everything, from A to Z, to see where I had missed something, but I just couldn't see what I had missed out.  I was about to give up m0n0wall that I told myself "what if I set up a rule??" and that's how I discovered the lack of such important information in the manual...
« Reply #5 on: May 24, 2009, 20:17:31 »
Seb74 ***
Posts: 115

Complex stuff sort of....I dont get the ARP-is-needed-thing.

You have two IP's on WAN, the regular WAN and a one-IP pool that is 10.6.6.9.
If someone on the web knows that your webserver is indeed on 10.6.6.9, they will send traffic to that IP (or a domain-name if you have one setup), it will enter the router, it will look and see "hey I should forward/NAT this traffic to 10.9.9.9".....just like when any traffic enters the router, no matter if its routed or PAT'ed or whatever. I cant see why the router must act like all transparent and forward ARP-response from your webserver out on the WAN :s

Offtopic, dont mind me if you dont want to Cheesy
« Reply #6 on: June 10, 2009, 12:10:24 »
Horus *
Posts: 6

I'd like to respond, but I'm afraid my answer isn't correct.  So correct me if I'm wrong.

I think the problem resides in the ARP resolution phase.

First of all, I have to add that my WAN NIC is connected to a (virtual) switch. (No idea if this has anything to do)

I think when a computer (eg 10.6.6.123) in the WAN wants to contact my DMZ web server through its WAN IP address, ie 10.6.6.9, the ARP table has no entry for this IP address, it has to broadcast an ARP request for resolution.  And apparently, without "Proxy ARP", m0n0 won't respond to ARP request.  Am I correct?

All in all, I really think a "Secondary IPs" tab for WAN could make things easier to understand and transparent.
 
Pages: [1]
 
 
Powered by SMF 1.1.20 | SMF © 2013, Simple Machines