Re: Inserting NAT for a local interface into the Firewall rules
Re: Inserting NAT for a local interface into the Firewall rules
- Subject: Re: Inserting NAT for a local interface into the Firewall rules
- From: "Peter Sichel" <email@hidden>
- Date: Mon, 15 Oct 2007 13:32:32 -0400
On 10/15/07, Thomas Tempelmann wrote:
>However, when the user has enabled the OS X Firewall, this won't work for
>several reasons:
>
>1. The 'flush' would clear all rules, so it needs to be suppressed.
>2. The added rule would get _behind_ the last Firewall rule, which denies
>all packets. My rule would need to be inserted earlier.
>3. If the user turns off the Firewall, my rule gets deleted as well. But if
>I try to prevent this by using another rule set (instead of 'set 0'), OS X's
>Firewall control panel won't like it at all.
>
>So, what's the proper way to deal with this?
"Proper" is subjective, but the way Apple imagined it is that
you would turn on Internet Sharing from the Sharing Preferences
panel which will reconfigure the firewall on your behalf.
In my own case, I built an NKE based NAT that is completely
independent of UNIX ipfw.
A few advantages:
(1) Performance. UNIX natd is actually a client process which uses an
ipfw divert socket to get packets out of the network kernel, translate
them, and then re-inject them back into the kernel. This means it must
shuffle every packet between different address spaces and wait for the
corresponding process to be scheduled. In contrast, IPNetRouterX uses a
Network Kernel Extension to perform translation within the network stack
itself thus avoiding a huge amount of overhead.
(2) With UNIX natd you can't modify port mappings on the fly without
restarting natd and thus losing every connection, plus there's no GUI to
do this.
(3) As a shared resource, UNIX ipfw is often configured by multiple
programs with conflicting models.
But even this still faces the problem that Apple's built-in firewall is
a moving target with no supported API. In 10.4, the default firewall
configuration makes no distinction between external WAN ports and
internal LAN ports, so you would need to modify this to allow access
from your LAN.
I hope this helps.
- Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden