On Wed, Jan 2, 2013 at 6:13 PM, Jorge Fábregas wrote:
"Server2" is another server (not yet mentioned) which sits parallel to portal and is connected only to the internet. Server2 has portal as it's only nameserver, so accessing server2 by name is only possible if portal is online and running bind.
Please elaborate more.
I'll try.
Why does 192.168.0.35 perform DNS queries
against the "external interface" of the firewall? Why not use the
internal ip?
It doesn't.
I'll try to be more specific:
There are at least four machines in this picture.
"Portal" is our company's gateway between the wide internet and the local LAN. It handles a number of services and also runs bind.
"Machine35" is a server on the local LAN.
"Server2" is another server (not yet mentioned) which sits parallel to portal and is connected only to the internet. Server2 has portal as it's only nameserver, so accessing server2 by name is only possible if portal is online and running bind.
Now the task I've been unhappily given is to allow ssh access to 35 directly from some other machine accessing from the internet. Call this machine "Developer".
The closest I've come to doing this is the rule that I posted originally. After executing that rule and no other, Developer is able to initiate a ssh connection to portal:20022 and directly log in to machine35. Beautiful. Except now, nobody can access server2 because the DNS query times out. That and the boss complains about IMAP access to portal from the outside stops working, which I figure is the same problem.
Anyway, the rule I posted is the only rule in use here. I have tried other iterations that did involve a MASQUERADE rule, but they didn't work either. Like I said, I've been scouring google to solve this for a long time.
So my question is sort of multi-faceted:
If the rule I posted can't work without an attendant MASQUERADE rule then why did it work? I'm certain it was the only rule in effect (aside from the normal rules always effective) when I tested connectivity.
Why did my rule cause other services to be blocked? I don't see anything about it that should have had that effect.
Finally, what *should* I do to make this work?
If you manually perform dig @192.168.0.1 google.com (I
assume that's your firewall ip) from 192.168.0.35, does it work? Did
you create the corresponding MASQUERADE rule (under POSTROUTING) for the
egress traffic coming from 192.168.0.35? I believe so , otherwise you
wouldn't have been able to connect from the outside to 20022.
Please post your rules if you want more detailed help. I really don't
see any relationship with what you describe & DNS problems.
Neither do I, and that's a big part of my problem.
Thanks for being patient with my ignorance.
-Alan
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
