Dave Burgess wrote:

> I've got another one for you.
> 
> A friend of mine is trying to set up a system where one of his internal
> servers (192.168.0.11) is visible on the Internet as 204.248.22.33.  The
> Firewall is set up for the correct outgoing translation (just like
> above).  Is there a way to do a 1:1 mapping of his internal address to
> the assigned external address?  If it's any help, he's running NT, and
> the MTK* that set it up says that NT won't do IP aliasing on one network
> card.  If that's possible, that would also solve the problem handily.  I
> just don't know that much about NT administration.
> 
> *Microsoft Trained Killer
> --
> Dave Burgess                   Network Engineer - Nebraska On-Ramp, Inc.
> *bsd FAQ Maintainer / SysAdmin for the NetBSD system in my spare bedroom
> "Just because something is stupid doesn't mean there isn't someone that
> doesn't want to do it...."

There are several problems with that, one of which is because proxy arp
on NT is dodgy (try using arp -s to shove an arp entry into NT's table
-- you'll find that it will either not publish it, or it will time out
and disappear). Commercial firewall packages have ways around this;
CheckPoint's FireWall-1 comes to mind, as they have hacked around the
proxy arp limitation and added their own functionality.  

Since static NAT is usually used for giving illegally-numbered servers
the ability to be contacted by Internet-based clients, putting the
appropriate static routes on the Internet-side router is a fine
compromise -- but the point still stands on NT that you have to use a
commercial firewall product.

Actually, I don't think any of the *IX ip filtering/translating systems
(ipmasq/ipfw,ipnat/ipf) support static NAT either. It would seem to be
something only found in commercial firewall software. No reason why
something like ipf couldn't support it; it's probably not a highly
requested feature, though, and it would not work with certain types of
systems (cable modems come to mind)...

Obipf: what's the general heuristic for ipf (-current) filter
application? From my experience with it, it appears to be read from the
bottom up. All the examples in /usr/share/examples/ipf and my own filter
list have the default drop rules for tcp/udp/etc. near the top. When I
tried putting them near the bottom, all packets that matched the drop
rules started getting thrown out, regardless of what 'allow' rules were
present before. Is this sort of behavior consistent with ipf? Maybe
'top' and 'bottom' get reversed when a filter list is shoved into the
kernel, or maybe it just gets hashed to death... :)

-- 
nverenin@san.rr.com