In order to solve the problem of internal network machines reaching other internal machines using their external address on linux firewalls that I have installed that use IPTables I've had to create a NAT rule that remaps the source address to that of the firewall's internal address. The command is: iptables -A POSTROUTING -s 192.168.0.0/255.255.255.0 -d 192.168.0.0/255.255.255.0 -p tcp -m tcp -m multiport --dports smtp,http,pop3,https -j SNAT --to-source 192.168.0.1
Which says if the traffic source is the internal network and the destination is the internal network and the destination ports are smtp,http,pop3 or https then make the source address the firewalls internal address. This is in the postrouting chain because the prerouting chain has already changed the packets external destination into an internal address when it first hit the firewall rules. So what happens is that the packet is then passed off to the internal server you are trying to reach, the response goes back to the firewall because of the source address translation and then the firewall redirects the packet back to the original source. I didn't figure this out myself, years ago I googled until I found the answer and have been using it ever since. Maybe you can find the equivalent rule for m0n0wall. Packet flow diagram time: internal server sends to external address (of destination internal server) firewall rules applied that change destination to internal address packet becomes internal server address to internal address of destination internal server if you stopped here the destination server would try and respond back to the source directly, not who it was trying to talk to, so: Firewall remaps source of packet to itself and remembers who the real source is firewall internal address sends to internal address of destination internal server Internal server responds to firewall internal address firewall remaps packet destination address back to the original source and passes it on and everyone is happy! Hope this helps. Bill >---------- >From: Rob Arends[SMTP:[EMAIL PROTECTED] >Sent: Sunday, February 24, 2008 4:59 AM >To: xmail@xmailserver.org >Subject: [xmail] Re: FreeBSD problem (similar to NetBSD problem report >ed >earlier?) > >Jeff, > >There are firewalls out there that consider traffic in and out of the *same* >interface to be illegal and they deny it. >Depending on your perspective and requirements, this is a good thing. > >Also some firewalls require the traffic to pass-through to be NAT'd. >If you don't have the same-interface issue above, you may have your traffic >not pass through the NAT tables because it turns around and goes out the >same interface before it hits the NAT tables. > >This is really getting in to Firewall design specifics. You'll need to dig >deep with the doco for your firewall(s) and maybe even log a support case to >get your answer. > >Good luck. > >Rob :-) > >_________________________________________________ >It might look like I'm doing nothing, but on a cellular level, I'm quite >busy. > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >Behalf Of Jeff Buehler >Sent: Sunday, February 24, 2008 4:02 AM >To: xmail@xmailserver.org >Subject: [xmail] Re: FreeBSD problem (similar to NetBSD problem report ed >earlier?) > >Hi Rob - > >That is more or less what is happening, but I'm not clear about the >specifics. I'm finding it a bit of a mystery - the firewall does NAT, >but the external DNS server trying to contact the internal server does >so in the case of many other domains, so the firewall is properly >configured for external queries - also, a dig dns1.buehlertech.net >+trace works properly from the server (as does dns2.buehlertech.net >which is on another public IP and behind a different router running >PFSense) so dns1.buehlertech.com (and dns2.buehlertech.com) must be >visible without difficulty to the external dns server. The server >shouldn't really be trying to communicate with it's own public IP >(itself), but rather the external dns server which then should simply >return the public IP of the server doing the query, or so I would think, >but I guess dig +trace has to literally dig all the way back to itself? >Even then, why is the secondary dns, which works and is on an entirely >separate network, not stepping in? Also, if I do a "dig trikorausa.com >+trace" from my secondary server (dns2.buehlertech.net) it works fine. >Perhaps the PFSense router is handling the query and NAT properly and >the m0n0wall router is not? > >At this point to me it is some sort of voodoo dns issue (and here I am >without any animal sacrifice to offer it), but it isn't causing me any >real headaches since SmartDns works. I will look more closely at NAT, >though, as I suspect you are right that it is at the center of the issue >somehow - it simply redirect inbound requests to port 53 of the server >in question, nothing complex. I still need to look at the other >external cases, but I have a feeling that there will be some >misconfigured DNS or other problems in those cases. > >It also does not sound like an XMail issue anymore either, so my >apologies for continuing on here. I will post a final time if I find >out what is going on simply for the sake of posterity! > >Thanks, >Jeff > >Rob Arends wrote: >> This will be a fault where the world uses you public IP to access your >zone >> hosted on your server, but when your server tries to resolve >> dns1.buehlertech.net it is not contactable (probably because of NAT on a >> firewall) and so tries dns2.buehlertech.net, but it is also not >contactable. >> Then it goes back to the root to try again, but of course there is no way >> you can talk to yourself via a public IP. >> >> I may have got a little bit of the process wrong, but in essence it is >> correct. >> If anyone can talk to you, but you can't talk to you, then it will be NAT. >> >> Try BIND views, or hosting on a different server, or allowing dns >resolution >> from 127.0.0.1, then pointing resolv.conf to 127.0.0.1 >> >> >> Rob :-) >> >> _________________________________________________ >> It might look like I'm doing nothing, but on a cellular level, I'm quite >> busy. >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >On >> Behalf Of Jeff Buehler >> Sent: Saturday, February 23, 2008 11:36 AM >> To: xmail@xmailserver.org >> Subject: [xmail] Re: FreeBSD problem (similar to NetBSD problem report ed >> earlier?) >> >> Hi Davide - >> >> Sorry about the delay on this - I was in away yesterday and today... >> >> Here is a sample of the dig + trace - I copied only the last two entries >> - basically this pattern is repeated until the "too many lookups" >> result. The other domains this server is authoritative for produce the >> same result except for buehlertech.net and buehlertech.com which work >> fine. The only differences I can think of is the reverse points to >> buehlertech.net and the domain is buehlertech.net in resolv.conf and in >> the hosts file (but why would buehlertech.com work?). >> >> ;; Received 117 bytes from 192.5.6.30#53(a.gtld-servers.net) in 126 ms >> >> com. 21365 IN NS e.gtld-servers.net. >> com. 21365 IN NS f.gtld-servers.net. >> com. 21365 IN NS g.gtld-servers.net. >> com. 21365 IN NS h.gtld-servers.net. >> com. 21365 IN NS i.gtld-servers.net. >> com. 21365 IN NS j.gtld-servers.net. >> com. 21365 IN NS k.gtld-servers.net. >> com. 21365 IN NS l.gtld-servers.net. >> com. 21365 IN NS m.gtld-servers.net. >> com. 21365 IN NS a.gtld-servers.net. >> com. 21365 IN NS b.gtld-servers.net. >> com. 21365 IN NS c.gtld-servers.net. >> com. 21365 IN NS d.gtld-servers.net. >> ;; Received 504 bytes from 67.102.108.82#53(dns1.buehlertech.net) in 68 ms >> >> trikorausa.com. 172800 IN NS dns1.buehlertech.net. >> trikorausa.com. 172800 IN NS dns2.buehlertech.net. >> ;; Received 117 bytes from 192.12.94.30#53(e.gtld-servers.net) in 93 ms >> >> com. 21365 IN NS c.gtld-servers.net. >> com. 21365 IN NS d.gtld-servers.net. >> com. 21365 IN NS e.gtld-servers.net. >> com. 21365 IN NS f.gtld-servers.net. >> com. 21365 IN NS g.gtld-servers.net. >> com. 21365 IN NS h.gtld-servers.net. >> com. 21365 IN NS i.gtld-servers.net. >> com. 21365 IN NS j.gtld-servers.net. >> com. 21365 IN NS k.gtld-servers.net. >> com. 21365 IN NS l.gtld-servers.net. >> com. 21365 IN NS m.gtld-servers.net. >> com. 21365 IN NS a.gtld-servers.net. >> com. 21365 IN NS b.gtld-servers.net. >> ;; Received 504 bytes from 67.102.108.82#53(dns1.buehlertech.net) in 54 ms >> >> trikorausa.com. 172800 IN NS dns1.buehlertech.net. >> trikorausa.com. 172800 IN NS dns2.buehlertech.net. >> dig: too many lookups >> >> >> Jeff >> >> Davide Libenzi wrote: >> >>> On Thu, 21 Feb 2008, Jeff Buehler wrote: >>> >>> >>> >>>> By the way, the trace does, and always has, produced the correct name >>>> servers (dns1.buehlertech.net and dns2.buehlertech.net), it just >>>> continues to trace after that result. >>>> >>>> >>> Do they set the correct AUTHORITY bit in the answer? >>> >>> >>> >>> - Davide >>> >>> >>> - >>> To unsubscribe from this list: send the line "unsubscribe xmail" in >>> the body of a message to [EMAIL PROTECTED] >>> For general help: send the line "help" in the body of a message to >>> [EMAIL PROTECTED] >>> >>> >>> >> - >> To unsubscribe from this list: send the line "unsubscribe xmail" in >> the body of a message to [EMAIL PROTECTED] >> For general help: send the line "help" in the body of a message to >> [EMAIL PROTECTED] >> >> - >> To unsubscribe from this list: send the line "unsubscribe xmail" in >> the body of a message to [EMAIL PROTECTED] >> For general help: send the line "help" in the body of a message to >> [EMAIL PROTECTED] >> >> >- >To unsubscribe from this list: send the line "unsubscribe xmail" in >the body of a message to [EMAIL PROTECTED] >For general help: send the line "help" in the body of a message to >[EMAIL PROTECTED] > > >- >To unsubscribe from this list: send the line "unsubscribe xmail" in >the body of a message to [EMAIL PROTECTED] >For general help: send the line "help" in the body of a message to >[EMAIL PROTECTED] > > - To unsubscribe from this list: send the line "unsubscribe xmail" in the body of a message to [EMAIL PROTECTED] For general help: send the line "help" in the body of a message to [EMAIL PROTECTED]
