On 2/28/11 8:53 AM, Eugene Grosbein wrote:
On 28.02.2011 22:44, Julian Elischer wrote:
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.
As I've already noted, the task can be solved without separate VIMAGE
using just one running natd. And I've presented working natd config for that.
I want to run ipfw nat for better performance. Note again,
the task is to NOT separate NAT instances but to the contrary,
I need to use BOTH translation tables combined for outgoing packets.
And I've presented configuration using ipfw nat that's supposed to work too,
but there I've found misfeature or a bug I want to discuss :-)
Eugene Grosbein
not totally relevant, but for readability and clarity as to what is
actually happening,
split your various flows into different sets of firewall rules using
skipto rules.
it makes my head hurt to have to read rules where you have to watch
for packets
going in opposite directions through the same rules.
using
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[email protected]"
