ipfw nat and dual-homed box
Hi! Consider LAN using private IP addresses and NAT box with two uplinks to distinct internet providers each of which supplies us with one public IP only. With natd's "multiple instances" feature it's easy to setup dual-homed NAT box correctly, so that replies for incoming packets get translated right, no matter what routing table thinks about outgoing interface for such reply. ipfw configuration: divert 8668 ip from any to any in recv $if0 # Deal with incoming packets. divert 8669 ip from any to any in recv $if1 divert 8000 ip from any to any out xmit $if0 # For outgoing packets, first try to find existing divert 8000 ip from any to any out xmit $if1 # translation table entry in all NAT instances and use it. divert 8668 ip from any to any out xmit $if0 # Create new translation entry only if it was found nowhere. divert 8669 ip from any to any out xmit $if1 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 Corresponding natd configuration file: instance default port 8668 interface $if0 unregistered_only yes instance second port 8669 interface $if1 unregistered_only yes globalport 8000 #EOF 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: 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? Eugene Grosbein ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: ipfw nat and dual-homed box
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? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposed patch for Port Randomization modifications according to RFC6056
On 08/02/2011 03:47 p.m., Doug Barton wrote: [catching up with e-mail] > I've been up and running on this patch vs. r218391 for over 24 hours > now, using algorithm 4 (as someone said is now the default in Linux) > without any problems. > > I think Bjoern is better qualified than I to comment on the style of the > patch, but it applies cleanly, and seems to run fine on both v4 and v6. Has this been commited to the tree, already? -- If so, what's the default algorithm? Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposed patch for Port Randomization modifications according to RFC6056
On 02/27/2011 12:23, Fernando Gont wrote: On 08/02/2011 03:47 p.m., Doug Barton wrote: [catching up with e-mail] I've been up and running on this patch vs. r218391 for over 24 hours now, using algorithm 4 (as someone said is now the default in Linux) without any problems. I think Bjoern is better qualified than I to comment on the style of the patch, but it applies cleanly, and seems to run fine on both v4 and v6. Has this been commited to the tree, already? -- If so, what's the default algorithm? Bjoern was planning to do it, I'm going to do it if he doesn't get around to it. As for default algorithm, is there any reason not to make it 4? Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposed patch for Port Randomization modifications according to RFC6056
On 27/02/2011 05:38 p.m., Doug Barton wrote: >> Has this been commited to the tree, already? -- If so, what's the >> default algorithm? > > Bjoern was planning to do it, I'm going to do it if he doesn't get > around to it. > > As for default algorithm, is there any reason not to make it 4? Not at all. Algorithm 4 (double-hash) is the best option, IMO. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposed patch for Port Randomization modifications according to RFC6056
On Sun, 27 Feb 2011, Fernando Gont wrote: Hi, On 27/02/2011 05:38 p.m., Doug Barton wrote: Has this been commited to the tree, already? -- If so, what's the default algorithm? Bjoern was planning to do it, I'm going to do it if he doesn't get around to it. As for default algorithm, is there any reason not to make it 4? Not at all. Algorithm 4 (double-hash) is the best option, IMO. I am still planning to do it soon but there is another thing in the queue touching the pcb code, which are way harder to merge on conflicts than this, so I am waiting for that to happen first. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Proposed patch for Port Randomization modifications according to RFC6056
On 02/27/2011 14:05, Bjoern A. Zeeb wrote: On Sun, 27 Feb 2011, Fernando Gont wrote: Hi, On 27/02/2011 05:38 p.m., Doug Barton wrote: Has this been commited to the tree, already? -- If so, what's the default algorithm? Bjoern was planning to do it, I'm going to do it if he doesn't get around to it. As for default algorithm, is there any reason not to make it 4? Not at all. Algorithm 4 (double-hash) is the best option, IMO. I am still planning to do it soon but there is another thing in the queue touching the pcb code, which are way harder to merge on conflicts than this, so I am waiting for that to happen first. Do you have a timeline? It's been weeks since you and I first spoke about this, and I really don't want this change to get lost in the shuffle, or worse, to be committed late in the pre-release cycle for 9.0 (which will mean it won't get adequate testing). The patch as posted applied cleanly to HEAD when I did it locally, and I can generate a clean patch from my local tree if needed. My vote is that because the port randomization patch is ready to go now, it should go in, and other work that isn't ready will have to adapt. But I'm willing to hold off for another week for a really good reason. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/154959: [age] "Bad packet length xxxxx, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled)
Synopsis: [age] "Bad packet length x, Disconnecting: Packet corrupt" (unless TSO, rxcsum, txcsum are disabled) State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Feb 28 02:25:46 UTC 2011 State-Changed-Why: I guess TSO and TX checksum offloading have nothing to do with the issue you're seeing. If age(4) generated corrupted packets via TSO/TX checksum offloading, receiver may have dropped these corrupted packets. Anyway, would you try the patch at the following URL and let me know how it goes? http://people.freebsd.org/~yongari/age/age.csum.diff I don't have access to age(4) hardwares any more so it was not tested. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Feb 28 02:25:46 UTC 2011 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=154959 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Mini PCI express cards for TDMA on FreeBSD?
Hi guys, anyone uses mini PCI express cards for TDMA on FreeBSD? I tried to use Anatel AR5BXB6 on IBM laptops. But it doesn't work when I set the node as Master(tdmaslot 0) with PANIC or "ATH0: stuck beacons;..". Is there any solution to solve the above problem? Or does anybody succeed to use TDMA on FreeBSD with mini PCI-e cards? Please, let me know how to solve or the name of the mini PCI-e card which works well for FreeBSD TDMA. FYI, I set the node with the below command. "ifconfig wlan create wlandev ath0 wlanmode tdma tdmaslot 0 up" Thanks, K. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
