Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 28 Feb 2011 08:44:14 -0800
From:      Julian Elischer <julian@freebsd.org>
To:        Eugene Grosbein <egrosbein@rdtc.ru>
Cc:        "net@freebsd.org" <net@freebsd.org>
Subject:   Re: ipfw nat and dual-homed box
Message-ID:  <4D6BD0DE.1080301@freebsd.org>
In-Reply-To: <4D6A35A3.7060303@rdtc.ru>
References:  <4D6A30B7.2010001@rdtc.ru> <4D6A35A3.7060303@rdtc.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2/27/11 3:29 AM, Eugene Grosbein wrote:
> On 27.02.2011 17:08, Eugene Grosbein wrote:
>
> [skip]
>
>> For performance reasons, I need to create similar setup using in-kernel "ipfw nat"
>> what does not have such "multiple instances" feature but has its own "keep-state" mechanics:
> To correct myself: of course, ipfw nat has multiple instances... It does not offer
> something like natd's "globalport" feature to check all NAT instances for entry
> before creation of new one.
>
>> nat config if $if0 unreg_only
>> nat config if $if1 unreg_only
>> nat 123 ip from any to any via $if0 keep-state # For incoming packets create dynamic rule.
>> nat 124 ip from any to any via $if1 keep-state # For outgoing packet use corresponding NAT instance.
>> fwd $if0_gate ip from $if0_ip to any out xmit $if1 # Force packet go out right interface.
>> fwd $if1_gate ip from $if1_ip to any out xmit $if0
>>
>> This works just fine if we do not try to use ipfw nat's port forwarding.
>> Here it breaks because "keep-state" creates dynamic rule for incoming connections
>> before translation's done, so it records external IP of the box as destination IP.
>> Hence, replies will be translated using wrong NAT instance when routing table
>> chooses wrong outgoing interface - replies won't match ipfw's dynamic rules.
>>
>> I think this is a bug in 8.2-STABLE. Am I right?
>> Or, perhaps, there is another way to setup ipfw nat for dual-homed LAN?
Eventually
one answer (which you may or may not like) is to run your NAT daemons in
separate VIMAGE jails so that there are effectively separate machines 
on each
outgoing interface.  eac can have its own firewalls etc then.
Unfortunately I can't tell you if the ipfw NAT will work in this set up
as I have not tested it.

           +------------------------------------+
           |                                    |
           +--------------+                     |
           |              |                     |
           |              |  +----+             |
ISP1------|              |  | n  |             |
           |            ng0--| g  |             |
           |              |  | -  |             |
           +--------------+  | b  |             |
           +--------------+  | r  |--ng2        +---inside interface.
           |              |  | i  |             |
       |            ng1--| d  |             |
ISP2------|              |  | g  |             |
           |              |  |    |             |
           |              |  +----|             |
           +--------------+                     |
           |                                    |
           +------------------------------------+
> _______________________________________________
> freebsd-net@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D6BD0DE.1080301>