It cannot be done. The problem is that routing happens before NATing.
The DNS server that you are NATing to must be within the same route
as the original address. This is why you must install a host route in
the firewall, with the original address pointing to the new destination.
So, the big limitation in CheckPoint's code, is that if you are doing
port (service) based NATing, all destinations must be contained
in the same route. So, if I use one ip address and split based on
service, so SMTP goes to one host, HTTP goes to another, and
so on... All these hosts must be contained within the same subnet.
Extending this to your environment, your DNS server must be in the
path of your default route (sitting off your external interface.) If you
put your DNS server directly off your external interface, you will
be bouncing the DNS packets off your internet router. Not the
best, but it will work. You just need to make sure the router is
configured to redirect the packet to the DNS server. (Route the
packet back out the same interface it came in.) Usually by default
the router will do this and send an ICMP redirect to the firewall.
Even if the firewall acts on the ICMP redirect (which it shouldn't,)
and updates the routing table with a host route, the routing decision
was made with a completely different IP address, so the new host
route will never be used.
In an IPTables environment, you can have the NAT happen in the
PREROUTING table. With that difference, you now have the freedom
of placing the true destination host anywhere. The routing decision is
made after the final destination is known.
The only reason that I can think of why CheckPoint did this, is because
they were inserting the firewall code into the IP stack in one place only
and they needed the spot where they had the most information, after
the routing decision is made. This allowed them the filter based on
ingress and egress interfaces, at the cost of not being able to influence
the routing decision.
I have hit this issue with the need to redirect SMTP connections. I am
currently stuck with using the security server to do the work, which
kills the firewalls when a virus attack happens. I cannot bounce the
TCP session off the firewalls, back into our network. I must have
the firewalls do all the work of accepting the email, hit the policy
twice, do all of it's checks, then deliver it to the internal mailservers,
which scan the message, find the virus and drop it.
On 4/26/05, David M. Zendzian <dmz@dmzs.com> wrote:
Howdy y'all,
I have an interesting situation. Below is a simple layout:
Internet
|
<client>10.1.0.0/16 ------[fw]----internal DNS
I have the client machines all being controlled by a 3rd party, so I
don't have any control over what they assign as their IP or DNS server.
However I route all of their traffic through my firewall (sorry you
won't get an explination why, just assume it's so:).
The problem is that they are assigned DNS servers on the internet (lets
say 64.221.222.0/24 (just random #'s I just made up, but just assume
it's that).
What I want to do is take all requests from the <client> going to the
internet based DNS Servers (udp 53) and redirect that traffic (using nat
or not, whatever we can get working), to internal DNS servers.
So if I was doing this with linux/iptables, I would just redirect udp
port 53 on the <client> network over to my internal DNS IP's, however on
the checkpoint I've found that it doesn't like to have source net NAT to
a destination host. It seems to want net->net or host->host, which won't
work as we don't know if or when the <client> provider may change their
dns server settings.
Any thoughts appreciated.
dmz
Oh this is on R55
--------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------
--
END OF LINE
-MCP
--------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
--------------------------------------------------------------------------
