255.255.255.255 broadcast changed from 4.x to 5.x
I've noticed a change in behaviour between FreeBSD 4.9 and FreeBSD 5.4 When sending an undirected broadcast to 255.255.255.255, FreeBSD 4.9 encapsulates this with the broadcast MAC address (ff:ff:ff:ff:ff:ff) as the destination. However, FreeBSD 5.4 encapsulates the packet using the MAC address of the default router, and therefore nobody else on the network sees it. Where this broke me was using wakeonlan. This utility sends a magic packet to 255.255.255.255 by default, and worked under FreeBSD 4.9 but not 5.4. After debugging with tcpdump -e, I found the issue with the MAC address. Configuring the program to send to the network's broadcast address instead of 255.255.255.255 fixed the problem; the packet was addressed to ff:ff:ff:ff:ff:ff, and the other computer woke up. Now I know about this, I can demonstrate it using 'ping 255.255.255.255' just as easily. My question is: is this an intentional change? Is it documented? # egrep -i '(broadcast|255)' /usr/src/UPDATING # Thanks, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: For advice in tcp implementation
On Sat, Oct 15, 2005 at 09:16:56PM -0700, shafi kamal wrote: > I am wishing to implement tcp minimally .I have taken it as a project > work. Good for you. That has nothing to do with FreeBSD, of course. > Is it possible to do that? Of course it is possible, depending on a suitable definition of "minimal". Try this for size: http://www-ccs.cs.umass.edu/~shri/iPic.html And if it were not possible, then you shouldn't have taken it as a project work, should you? > How much coding capability & man-hour > may required through your estimation? How long is a piece of string? If you don't know anything about programming practices or TCP/IP, or can't be bothered to research the TCP/IP protocols for yourself, then I would say the coding capability required is higher than you possess. > I think you are the best man for > this advice. I find it interesting that you think of a mailing list as a "man". > Expecting quick response. shafi kamal I hope this is quick enough for you. Before you post to any more mailing lists, there is a very useful guide here which I suggest you read: http://www.catb.org/~esr/faqs/smart-questions.html Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bind 8
On Tue, Oct 18, 2005 at 07:54:02PM +0200, Anton Bester wrote: > The following is a tcpdump from the secondary when bind is running: You really want to use tcpdump -n. Otherwise, every packet seen will trigger a new reverse DNS lookup, which in turn will trigger your nameserver to make further lookups to other nameservers on the Internet. This may mask any underlying problem. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: openssl & gmail problem
On Wed, Nov 02, 2005 at 09:35:04AM +0100, Meka[ni] wrote: > Why doesn't this work: > openssl s_client -starttls smtp -connect smtp.gmail.com:25 > > I've tried adding -CApath /usr/local/share/ssl/certs (that's where I keep > certs), but nothing changed. This is the error I get: > CONNECTED(3) > 17478:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown > protocol:s23_clnt.c:567: > > openssl version > 0.9.7e > > /usr/local/bin/openssl version > 0.9.8a > > None of this works. Any ideas? Run tcpdump and/or ktrace to see what's happening. # tcpdump -i nv0 -n -s1500 -X tcp port 25 When I do this, I see: < 220 mx.gmail.com ESMTP g1sm241248nfe > STARTTLS < 503 5.5.1 EHLO/HELO first g1sm241248nfe I think that should be clear enough. Please feel free to submit a patch to the openssl project, so that it sends EHLO first. Remind them that you shouldn't try to use an ESMTP extension until you've first had it announced to you that the extension is available. (RFC 2821 section 4.1.1.1) "In any event, a client MUST issue HELO or EHLO before starting a mail transaction." Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: openssl & gmail problem
On Wed, Nov 02, 2005 at 02:17:15PM +0100, Meka[ni] wrote: > On Wed, 2 Nov 2005 12:35:29 + > Brian Candler <[EMAIL PROTECTED]> wrote: > > > Run tcpdump and/or ktrace to see what's happening. > > > > # tcpdump -i nv0 -n -s1500 -X tcp port 25 > > > > When I do this, I see: > > > > < 220 mx.gmail.com ESMTP g1sm241248nfe > > > STARTTLS > > < 503 5.5.1 EHLO/HELO first g1sm241248nfe > > > This is what I get. I can not see anything enough readable. Either look in the right-hand column for the text part of each packet, or the left-hand part shows it in hex. > > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on tun0, link-type NULL (BSD loopback), capture size 1500 bytes > 14:07:03.627614 IP 82.208.205.163.59631 > 64.233.183.109.25: S > 2803137835:2803137835(0) win 65535 1,nop,nop,timestamp 29846462 0> > 0x: 4500 0040 63d0 4000 4006 be1d 52d0 cda3 [EMAIL > PROTECTED]@[EMAIL PROTECTED] > 0x0010: 40e9 b76d e8ef 0019 a714 7d2b @..m..}+ > 0x0020: b002 a267 0204 05b4 0101 0402 .g.. > 0x0030: 0103 0301 0101 080a 01c7 6bbe ..k. > 14:07:03.785968 IP 64.233.183.109.25 > 82.208.205.163.59631: S > 1718924688:1718924688(0) ack 2803137836 win 8190 > 0x: 4500 002c ef4b f106 c1b5 40e9 b76d E..,[EMAIL PROTECTED] > 0x0010: 52d0 cda3 0019 e8ef 6674 b590 a714 7d2c R...ft}, > 0x0020: 6012 1ffe 360b 0204 05a8`...6... > 14:07:03.786320 IP 82.208.205.163.59631 > 64.233.183.109.25: . ack 1 win 65535 > 0x: 4500 0028 63d1 4000 4006 be34 52d0 cda3 E..([EMAIL > PROTECTED]@..4R... > 0x0010: 40e9 b76d e8ef 0019 a714 7d2c 6674 b591 @..m..},ft.. > 0x0020: 5010 6dba P...m... > 14:07:03.946036 IP 64.233.183.109.25 > 82.208.205.163.59631: P 1:40(39) ack 1 > win 5720 > 0x: 4510 004f c384 3206 ac4a 40e9 b76d [EMAIL PROTECTED] > 0x0010: 52d0 cda3 0019 e8ef 6674 b591 a714 7d2c R...ft}, > 0x0020: 5018 1658 d657 3232 3020 6d78 2e67 P..X.W..220.mx.g > 0x0030: 6d61 696c 2e63 6f6d 2045 534d 5450 207a mail.com.ESMTP.z > 0x0040: 3733 736d 3233 3930 3536 6e66 620d 0a73sm239056nfb.. Note the right hand side for the last three lines: "220 mx.mail.com ESMTP z73sm239056nfb" + CRLF (0d 0a) > 14:07:03.946545 IP 82.208.205.163.59631 > 64.233.183.109.25: P 1:11(10) ack > 40 win 65535 > 0x: 4500 0032 63d2 4000 4006 be29 52d0 cda3 [EMAIL > PROTECTED]@..)R... > 0x0010: 40e9 b76d e8ef 0019 a714 7d2c 6674 b5b8 @..m..},ft.. > 0x0020: 5018 2b29 5354 4152 5454 4c53 P...+)..STARTTLS > 0x0030: 0d0a .. "STARTTLS" + CRLF > 14:07:04.096053 IP 64.233.183.109.25 > 82.208.205.163.59631: . ack 11 win 5720 > 0x: 4510 0028 c385 3206 ac70 40e9 b76d E..([EMAIL PROTECTED] > 0x0010: 52d0 cda3 0019 e8ef 6674 b5b8 a714 7d36 R...ft}6 > 0x0020: 5010 1658 5731 P..XW1.. > 14:07:04.106000 IP 64.233.183.109.25 > 82.208.205.163.59631: P 40:82(42) ack > 11 win 5720 > 0x: 4510 0052 c386 3206 ac45 40e9 b76d [EMAIL PROTECTED] > 0x0010: 52d0 cda3 0019 e8ef 6674 b5b8 a714 7d36 R...ft}6 > 0x0020: 5018 1658 88c2 3530 3320 352e 352e P..X503.5.5. > 0x0030: 3120 4548 4c4f 2f48 454c 4f20 6669 7273 1.EHLO/HELO.firs > 0x0040: 7420 7a37 3373 6d32 3339 3035 366e 6662 t.z73sm239056nfb > 0x0050: 0d0a .. "503 5.5.1 EHLO/HELO first z73sm239056nfb" + CRLF > 14:07:04.112871 IP 82.208.205.163.59631 > 64.233.183.109.25: P 11:153(142) > ack 82 win 65535 > 0x: 4500 00b6 63d3 4000 4006 bda4 52d0 cda3 [EMAIL > PROTECTED]@...R... > 0x0010: 40e9 b76d e8ef 0019 a714 7d36 6674 b5e2 @..m..}6ft.. > 0x0020: 5018 aa17 808c 0103 0100 6300 P.c. > 0x0030: 2000 0039 3800 0035 1600 .9..8..5 > 0x0040: 0013 0a07 00c0 3300 0032 ..3..2.. > 0x0050: 2f03 0080 6600 0005 0401 0080 /.f. > 0x0060: 0800 8000 0063 6200 0061 1500 .c..b..a > 0x0070: 0012 0906 0040 6500 0064 [EMAIL PROTECTED] > 0x0080: 6000 0014 1100 0008 0604 0080 `... > 0x0090: 0302 0080 a6a3 3dcd 03c8 5411 ea55 =...T..U > 0x00a0: f2c7 b618 88dd 5790 28f8 51f9 93c5 38f5 ..W.(.Q...8. > 0x00
Re: openssl & gmail problem
On Thu, Nov 03, 2005 at 12:16:51AM +0100, Meka[ni] wrote: > > > 14:07:04.306017 IP 64.233.183.109.25 > 82.208.205.163.59631: P 82:129(47) > > > ack 153 win 5720 > > > 0x: 4510 0057 c387 3206 ac3f 40e9 b76d [EMAIL PROTECTED] > > > 0x0010: 52d0 cda3 0019 e8ef 6674 b5e2 a714 7dc4 R...ft}. > > > 0x0020: 5018 1658 4026 3530 3220 352e 352e P..X@&..502.5.5. > > > 0x0030: 3120 556e 7265 636f 676e 697a 6564 2063 1.Unrecognized.c > > > 0x0040: 6f6d 6d61 6e64 207a 3733 736d 3233 3930 ommand.z73sm2390 > > > 0x0050: 3536 6e66 620d 0a56nfb.. > > > > "502 5.5.1 Unrecognized command z73sm239056nfb" + CRLF > > (looks like openssl has tried to start a TLS session anyway) > Is there anything I can do about it? It works on my gentoo-linux box. > I've tried all available versions of openssl. By the way, where should I keep > the certs, and do I need anything from the FreeBSD source code? Thanx a lot. > :o) Please stop replying to me personally. See http://www.eyrie.org/~eagle/faqs/questions.html To "do something about it" you modify the openssl source code so that it sends the correct SMTP sequence (EHLO, wait for reply, STARTTLS). If it "works" on your gentoo-linux box, pointing to the same smtp server, then I can only guess that your gentoo-linux box is running a different or patched version of openssl. You can run the session from there and use tcpdump to show what is different in the message exchange. If it's a different version of openssl then try installing the version of openssl which is in the ports collection. If you reply to me again personally, your message will go straight in the trash. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: volunteer computer-geek to help us for FREE? please contact !
On Thu, Nov 03, 2005 at 11:44:08AM +0100, jan tore wrote: > Example 1: a clock-file that limits the speed for sending group mail.(we > bought the most excpencive version)makes us BIG problem. > a program limit-send-speed file in the group mail program we bought > is set to 6 thousand per hour maximum. How to dobble this? If you bought the program, then you will have a manual. You may also have a technical support line to call. You are unlikely to get support for commercial software on a FreeBSD mailing list. > -needle in a heystack-job?maybe use auto search program to find it??? > Name of the program is group mail version 3.4.214 Google is your friend: http://www.google.com/ Good luck with your query. > we can even use tips on all our projects example this limitation file name, > we tried talk with infacta for extended speed but they couldnt help > > Download program here: > http://www.infacta.com/download.asp?a=ftr "Minimum requirements Operating System: 95, 98, ME, NT4 (with service pack 5 or higher), 2000 or XP" So what makes you think that a *FREEBSD* mailing list will be able to help you with a *WINDOWS* problem? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
On Wed, Nov 09, 2005 at 02:06:28PM +0100, Jon Otterholm wrote: > I want to create a bridge-interface (if_bridge) with a bunch (500+) of > sub-interfaces (vlan) as members. All members of the bridge should be > able to "talk" to each other but MAC-addresses must be isolated to their > "own" vlan. That doesn't really make any sense to me, can you give a concrete example of how it should behave? And/or a higher-level description of what it is you're actually trying to achieve? Note that if the VLANs are *bridged* together then: (1) they form a single broadcast domain. A broadcast packet on any one VLAN will be forwarded to all other VLANs (2) a unicast packet to MAC address XX:XX:XX:XX:XX:XX will be forwarded only to the VLAN which has that node, as long as the forwarding table knows where it is (if not, it will be forwarded to all VLANs) So bridging VLANs really just collapses them back into a single LAN, which means you shouldn't have set up any VLANs in the first place :-( ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
On Thu, Nov 10, 2005 at 02:25:07PM +0100, Jon Otterholm wrote: > In all this - our role is similar to an ISP, but we are buying access to > our customers from an external part. Every customer is delivered on a > separate vlan trunked. > > - Our DSL customers cannot be set on the same VLAN i a single DSLAM > (don't ask me why - ask Alcatel). > - We cannot build a simple bridge because the Network service provider > can't handle when a MAC-address shows up on 2 different VLAN's. > > The arp-proxy should do the following: > - Forward any broadcast packets but rewrite src to its own mac. > - Forward unicast packets according to FDB but rewrite src to its own > mac. Can you not perform normal routing - that is, allocate a separate IP subnet to each VLAN? This uses some more IPs than a 'flat' addressing space, but it's guaranteed to work properly. If your DSL traffic is presented as PPPoE, maybe you can get away with just having a separate PPPoE listener on each VLAN. If it's presented as L2TP you could use private IPs for the tunnel endpoints. Otherwise, a bridge which rewrites source MAC addresses as packets pass through - that's just too awful to contemplate. As you say, you'd also have modify ARP responses to have the bogus MAC addresses too. Dealing with multicast, IGMP, Netbios... no I really don't want to contemplate it :-) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
On Thu, Nov 10, 2005 at 03:08:34PM +0100, Jon Otterholm wrote: > The point in all this is to reduce administration on my hand and in some > cases to offer a service to customers with the feeling that they reside > "on the same layer". That is, customer A *wants* to see all the Netbios broadcasts from customers B, C and D, and vice versa? Oh well. I can't help you really, except perhaps to point you to the Netgraph module API :-) > Alcatels soloution to this is to put an ARP-proxy in a Cisco-router. Proxy-ARP is easy enough in FreeBSD: there are net-mgmt/choparp and net/arpd in ports (I have used the former, not the latter) and `arp pub`. However that's a long way removed from a bridge which rewrites packets - a sort of layer 2 NAT... Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NFS clearing attribute cache in nfs_open
I have been tracing some performance problems on diskless systems. In
particular, the following test program:
perl -e 'for ($i=0;$i<1000;$i++) { open F,"; close F;}'
generates 1000 'access' transactions, and hence an exchange of 2000 UDP
packets, just from repeatedly opening the same file.
After some digging around, I have found the cause: the NFS attribute cache
for a file is explicitly invalidated every time the file is opened.
[sys/nfs/nfs_vnops.c]
static int
nfs_open(ap)
...
if ((nmp->nm_flag & NFSMNT_NQNFS) == 0)
np->n_attrstamp = 0; /* For Open/Close consistency */
return (0);
}
For test purposes I changed this to
if ((nmp->nm_flag & NFSMNT_NQNFS) == 0 && (np->n_flag & NMODIFIED))
np->n_attrstamp = 0; /* For Open/Close consistency */
return (0);
and suddenly the problem went away - attributes were being cached happily,
and NFS traffic dropped to virtually zero.
Now, there is obviously some "consistency" issue to beware of. Are there any
NFS gurus out there who can say why it is necessary to clear the attribute
cache on _every_ open? Could it safely be made less restrictive, e.g. don't
clear the cache when opening a file for read? I think there are some
potentially large performance gains for diskless server clusters, where the
same file is being repeatedly exec()'d.
I see that the code in nfs_close doesn't invalidate the cache unless the
file has been modified. However that doesn't help much if the cache is going
to get invalidated anyway the next time the file is opened :-)
Many thanks,
Brian Candler.
P.S. I am working to FreeBSD-4.5-STABLE-20020426
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: NFS clearing attribute cache in nfs_open
On Fri, Apr 26, 2002 at 04:42:48PM -0700, Andrew P. Lentvorski wrote: > > ... Could it safely be made less restrictive, e.g. don't > > clear the cache when opening a file for read? > > In a word, no. Why couldn't the sysadmin be running "make installworld" > on the NFS server while you're running that program? By definition, for > better or worse, NFS is "stateless". The only way in which NFS can know > that your file hasn't changed (been deleted, renamed, etc) is to make that > round trip to the server. Sorry. Sounds fair. I was talking about the _attribute_ cache, but does re-fetching the attributes also tell the client that the _content_ of a file has changed? A version number, perhaps? > If you are really > into clusters with low-latency, you might want to look into something like > NFS V4 (Is anybody working on that on FreeBSD, anymore?), AFS, CODA, or > something more specialized. Those networked filesystems have a > bidrectional characteristic and cached state protocols so that they can > minimize communication. Will do. For a diskless bootup I think I am restricted to either NFS or ramdisk for the root filesystem though. Is it possible to replace the root filesystem with a different one after the system has started? Regards, Brian. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: NFS clearing attribute cache in nfs_open
Thanks for comments so far. It looks like the best solution for me is going to be to boot diskless into a ramdisk. It's been quite a job finding out how to do that; there doesn't seem to be much in the way of documentation. Reverse-engineering the source suggests that the following methods exist: (1) Including an MD image within the kernel itself options MD_ROOT options MD_ROOT_SIZE n # kilobytes then use usr/src/release/write_mfs_in_kernel.c to patch the image into the kernel. Trouble is you must reserve sufficient space for the image, and repatch a clean kernel every time you wish to change the ramdisk. (2) Module preload mechanism dev/md/md.c calls preload_search_info(mod, MODINFO_NAME) This accepts a 'module' of type "md_image" or "mfs_root" It then creates a ramdisk using data at MODINFO_ADDR of MODINFO_SIZE. These in turn come from sys/kern/subr_module.c which uses a block of "preload_metadata" As far as I can tell, either I can put something like load -t md_image myfile in boot/loader.rc, or do what release/Makefile does, which is to put mfsroot_load="YES" mfsroot_type="mfs_root" mfsroot_name="/boot/mfsroot" in boot/loader.conf. I'm not sure if that's sufficient to replace the NFS root, or if I have to recompile the kernel _without_ options BOOTP and BOOTP_NFSROOT for this to work, but I'll give it a go later on... Cheers, Brian. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: arp-proxy
On Thu, Nov 17, 2005 at 04:06:03PM +0100, Jon Otterholm wrote: > Not a big fan of Linux though. I will have to wait for this to be ported > to BSD. Anyone with info if this is being done? ... > > [1] http://www.sjdjweis.com/linux/proxyarp/ You can do proxyarp like that with FreeBSD now. However you can't assign the same range of IPs to multiple interfaces, for obvious reasons. I think the way you'll have to do it is to lie to your customers about the subnetting. For example, tell all your customers that they need a /16 (255.255.0.0 netmask). Then you can actually configure: ifconfig vlan0 192.168.0.1/28 ifconfig vlan1 192.168.0.17/28 ifconfig vlan2 192.168.0.33/28 ... ifconfig vlan4095 192.168.255.249/28 Now, the customer on vlan0 can use 192.168.0.2 to 192.168.0.14 with a /16 netmask. The customer on vlan1 can use 192.168.18 to 192.168.30 with a /16 netmask, and so on. When the FreeBSD machine sends a packet to the customer, that's fine. It knows which vlan interface to use, and hence ARPs for the customer down that interface, based on the fact that each customer is within their own /28 range. When the customer tries to send to another customer, you run choparp or a similar program so that if they ARP for 192.168.X.X the FreeBSD machine always responds with its own MAC address. However, I see virtually no benefit in going down this route. The customer might as well just set up a /28 netmask and point defaultroute at the relevant FreeBSD IP address (192.168.0.1 or 192.168.0.17 or ...), and then you do *proper* routing. After all, even with proxyARP, they will still see your router as an IP-level "hop" (it decrements TTL). And non-IP packets and broadcasts won't be forwarded between the subnets. Furthermore, if a customer decides to configure an IP address outside of their 'allowed' range, it won't work - and it will be hard to debug, as the FreeBSD box and the wrongly-configured box will *both* respond to the same ARP request, and so sometimes one will win and sometimes the other will win. So, I really don't think you want to do this :-) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
On Thu, Nov 17, 2005 at 04:52:03PM +0100, Jon Otterholm wrote: > Scenario#1: > -I have a range of ip's, for example 215.10.10.0 - 215.10.10.255. > -I want to distrubute theese ip's to my customers via DHCP. > -They are all atached to me via a VLAN-trunk on a unique VID > -I have 200+ customers. > > If I was to subnet these addresses so that all the sustomers would get > their own IF (with an IP) in my router and their own IP I could create a > bunch of /30-nets but each customer would take up 4 IP's (net, G/W, > CustomerIP, Broadcast) - and that is a big vaste of IP's in my opinion. Albeit one that you can sensibly justify to a registry for your purpose. If you could get clients to run PPPoE, then you wouldn't need to allocate any /30 subnets to the VLANs, and you could give each customer a single /32 IP (either statically or from a pool). Multiple customers could share a VLAN which might be useful in future, e.g. if one VLAN serves a building with multiple users. > If I instead could create a pseudo bridge with a "mother if" acting as > gateway, distrute IP's via DHCP (ISC?) I could reduce the number of IP's > and administration when adding new customers. > > Anyone with a souloution or revelation? I think it's tricky, given the additional constraints you gave in your other E-mails. In particular, you said that MAC address xx:xx:xx:xx:xx:xx which originates on VLAN X must never appear as a source MAC address on any other VLAN, because that would confuse the switching infrastructure which links the bundle of VLANs to the customer sites. (i.e. the VLANs are not true VLANs because they are not properly isolated from each other) Given DHCP, you're not statically assigning a particular IP or range of IPs to a particular vlanN interface: so you can't "route add" to send traffic for IP address x.x.x.x down VLAN Y. Hence you need to do dynamic bridging, but with the MAC source address masquerading. Now, this is not the Linux proxy-arp solution described in the link you gave; it's something very different. I'm not aware of any implementation of this on any platform. If you're happy to hack code, the best I can suggest is you start with ng_bridge and modify it to fit. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
On Thu, Nov 17, 2005 at 05:35:35PM +, Baldur Gislason wrote: > I've also wanted to have multiple interfaces on the same physical network > with > different addresses on the same subnet. That's a reasonable thing to want to do, and I remember seeing a statement saying that FreeBSD plans to allow that, by separating the ARP table from the forwarding table (which should never have been merged in the first place, really) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: arp-proxy
> > On Thu, Nov 17, 2005 at 04:52:03PM +0100, Jon Otterholm wrote: > > > Scenario#1: > > > -I have a range of ip's, for example 215.10.10.0 - 215.10.10.255. > > > -I want to distrubute theese ip's to my customers via DHCP. > > > -They are all atached to me via a VLAN-trunk on a unique VID > > > -I have 200+ customers. Let me see if I can summarise your requirements: vlan1 cust1 , \ service network vlan2\ trunkedsingle subnet x.y.z.0/24 cust2 ---===*--++--- / || vlan3 /DHCP srv router ---> Internet cust3 ' The constraints are: - cust1, cust2, cust3 are all on the same subnet x.y.z.0/24 and get an IP address allocated by DHCP - However, the MAC address for cust1 must never appear as a source MAC address on vlan2 or vlan3, as this would confuse the provider's trunked switching infrastructure So you can't just bridge all the VLANs together. Rather: 1. a broadcast from custX must appear on the service network, but not on any of the other customer VLANs. More strongly, no packet from custX may appear on any other VLAN apart from the service network. [*] 2. a broadcast from the service subnet should appear on all customer VLANs (e.g. ARP from DHCP server or router) 3. an ARP request for custY from custX must be proxy-ARP responded to by a device on the service network, otherwise customers wouldn't be able to communicate with each other. 4. a unicast packet from the service network to a customer must be forwarded to the correct customer VLAN Is that a reasonable summary? Taking that as the base: Point (4) implies that a bridge forwarding table must still be built, because the device performing this function (labelled '*' in the above diagram) needs to associate a MAC address with a VLAN, and do so by learning rather than static configuration. Point (1) says that you can't just bridge all the VLANs together, because otherwise a packet to a broadcast address or to an unknown MAC address would be forwarded to all the other VLANs. We want this to happen for packets originating from the service network (point (2)), but not for packets which originate from the customer networks. So, some sort of L2 forwarding filter should do the trick: configure it so that packets may only be forwarded to customer VLANs if they originate from the service network. If this filter is applied, you guarantee that a customer's MAC address will never appear as a source on any other VLAN. Point (3), proxy ARP, is easy enough. You know all the possible customer IPs - they are exactly the range assigned to the DHCP server to allocate - and therefore you can proxy-ARP respond for any IP address within the DHCP range, as long as the request originated from a customer VLAN (which can also be determined by the ARP source IP). The router itself could perform this proxy ARP function, or else any server on the service network running something like choparp (which can give out the router's MAC address in the ARP responses). IP datagrams from custX to custY then go custX->router->custY. So actually, when thought about like this, the L2 masquerading requirement vanishes, and what you really need is bridging plus some L2 filtering based on ingress and egress interfaces. Unfortunately, I don't know if FreeBSD has this level of L2 filtering (I note that the bridge(4) documentation says that ipf/ipfw filtering only works for IP datagrams). However a frob on the bridging code should be possible; call the first interface 'master' and the rest 'slaves', and have a rule so that packets to a 'slave' interface are only forwarded if they originated from the 'master' interface. Aside: the network as designed above has an obvious flaw that any customer can DHCP for as many different machines as they wish, and therefore exhaust your DHCP pool. You could have a separate mini DHCP server listening on each VLAN and only handing out a single IP, but that doesn't stop customers stealing other customer's IPs through static configuration. So actually, I think you need anti-spoofing filters on each VLAN too. Doing that, you end up statically routing a separate IP down each VLAN, in which case what you *really* want is to be able to configure each VLAN subinterface as if it were a point-to-point interface. But I don't think FreeBSD supports that on broadcast media. Regards, Brian. [*] Or if it did appear on the other customer VLANs, it would have to be masqueraded to appear as if it came from a MAC address on the service network; however I believe this isn't actually necessary, as the only broadcasts we really care about here are ARP requests. All others can be dropped, and indeed probably should be dropped so that all your customers don't get drowned in each other's broadcast traffic. __
Re: arp-proxy
On Mon, Nov 21, 2005 at 01:45:44PM +0100, Jon Otterholm wrote: > The reason why I have to proxy-arp mac between VLANs is that one mac > cannot end up mapped to more than one port in the switches FDB. If they > do - we get something called "host-flapping" on IOS-language. Or put it another way - Cisco haven't properly virtualised their VLANs so that they have separate forwarding tables. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug in routing tables ?
On Thu, Nov 24, 2005 at 02:28:37PM -0200, Ricardo A. Reis wrote: >I insert this route in my workstation for network test, > > #route add -net 200.144.xx.xx 255.255.254.0 172.22.x.x Linux user I bet ;-) For FreeBSD you need: #route add -net 200.144.xx.xx -netmask 255.255.254.0 172.22.x.x > Internet: > DestinationGatewayFlagsRefs Use Netif Expire > default200.144.xx.xxx UGS 113407rl0 > 127.0.0.1 127.0.0.1 UH 0 46lo0 > 136.16&0xac160181 255.255.254.0 UGS 0 34rl0 As you can see, 255.255.254.0 was interpreted as the gateway, not the netmask. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Bug in routing tables ?
On Fri, Nov 25, 2005 at 01:20:01PM -0200, Ricardo A. Reis wrote: > But i use route add 200.144.xx.xx/[mask] 172.22.xx.xx for > many year, and this work perfectly on freebsd and linux. Yes it does (as of a couple of years ago, I think). However if you want to specify the netmask explicitly instead of a prefix length, as the O.P. did, then you have to include the '-netmask' keyword. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: proposal: TCP rendevous
On Sat, Nov 26, 2005 at 10:18:49PM -0800, Julian Elischer wrote: > In this world of P2P apps it would be neat to have a way that two P2P apps > could attach to each other even though each is through a firewall. Most > firewalls only allow > "outgoing" connections. > > It would of course be possible via a 3rd party relaying but that is > inneffieient and the throughput > would be limited by throughput limits on the 3rd party link. > > It must be possible, with the connivance of a 3rd party both parties > could be able > to make suitable 'OUTGOING' connections. > The 3rd party would spoof needed packets using information supplied > by the two parties. See this: http://samy.pl/chownat/ (Haven't tried it myself, but came across it on Freshmeat a while ago. I imagine it must rely on the NAT firewalls not changing the source UDP port unless they have to) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: natd redirected ports from LAN
On Tue, Nov 29, 2005 at 12:46:10PM +0200, asko wrote:
> I'm searching for a better, faster solution..
> Does it exist?
Do your constraints allow you switch to 'pf' instead of 'ipfw'? I think you
may be able to do it that way. I had a similar situation where I wanted
traffic originating from the local host to be processed specially. The case
in point was redirection rather than NAT, but the same principles probably
apply. Using pf I forced the traffic back through the loopback interface so
it was treated as 'incoming' traffic. e.g. see thread around
http://lists.freebsd.org/pipermail/freebsd-pf/2005-September/001495.html
Maybe in your case you just need two rdr rules: one bound to the internal
interface, and one to the external one.
I stopped using ipfw several years ago because of a number of issues with
NAT, especially some horrible scenarios with multiple external interfaces,
IPSEC tunnels, and needing to run multiple instances of natd :-{
Regards,
Brian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FBSD 6.0 ipfw weirdness with ssh x-forwarding
On Sat, Dec 10, 2005 at 10:43:16AM -0500, Eric W. Bates wrote: > Dec 9 23:15:33 gertrude kernel: ipfw: 510 Deny TCP > [::0001]:6010 [::0001]:61310 out via lo0 Note that ::0001 is the IPv6 "localhost" address (equivalent to IPv4 127.0.0.1) > I was hoping someone smarter than I could point me to any documentation > about the change. > > Has ipfw recently split me and me6 (I never noticed the latter before > because I'm not using IPv6 yet [shame])? Looking on a 5.4-STABLE system, the ipfw(8) manpage mentions 'me' but not 'me6'. Looking on the web, at http://www.freebsd.org/cgi/man.cgi?query=ipfw&apropos=0&sektion=8&manpath=FreeBSD+6.0-RELEASE+and+Ports&format=html I see 'me' and 'me6' options. So yes, it looks like it has been split. > Is this a change in the way the 6.0 kernel handles lo0 traffic in general? > > Is this a change in ssh forwarding? Or has there always been IPv6 traffic? IPv6 support has been around in FreeBSD for a long time. If this causes you pain (as it does for me), then I recommend you remove 'options INET6' from your kernel config and rebuild the kernel. Other things to look for are your hosts file, which may have ::1 localhost 127.0.0.1 localhost in which case you can swap them, or comment out the IPv6 ::1 one altogether (otherwise IPv6 is preferred over IPv4 when using localhost). Also, a lot of ports tend to build with IPV6 support unless you explicitly disable it. I think there's a setting you can put in /etc/make.conf but I can't remember offhand what it is. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: high interrupts by network interfaces
On Sun, Dec 11, 2005 at 03:26:50AM -0800, kamal kc wrote: > i modified the bridge.c file and added a routine to > compress/decompress > ip packet. i put my code in bdg_forward(). And ran the > pc in bridge mode. > > The modified kernel is deployed in network where the > datarate is > about 4 to 6 Mbps. One thing to be noted is that the > pc receives > continues data at 4 to 6 Mbps rather than sudden burst > at intervals. > > Now the problem is, I am getting very high interrupts > from the network > interfaces. the cpu utilization by the interrupts is > high due to which there > is latency added to the packets forwarded by the pc. > The pc attempts to > compress/decompress all tcp packets. Suggestion: start with a standard kernel, without your custom modifications. If unmodified bridging works, and you get the high interrupt level, then you have found a problem with in FreeBSD. If unmodified bridging works, but interrupts are at a normal level, then you have a found a problem with your own code. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction
On Mon, Dec 26, 2005 at 01:41:50PM +0200, Oleg Tarasov wrote: > mpd configuration is attached in mpd.conf and mpd.links. Shortly, ng0 > is a PPPoE connection on rl1 interface. ^ Sounds to me like an MTU problem. Windows machine sends a 1500-byte packet, but it can't fit into an ethernet frame along with PPPoE encapsulation, so the router should either send back an ICMP error (if DF bit is set), or it should fragment (if DF bit is not set). With DF, the Windows client is supposed to automatically detect that the path MTU has been exceeded, and try again with a smaller MTU. The tcpdumps you show indicate DF is set. They don't show any ICMP responses, but then again you didn't show the *exact* tcpdump command line you gave. I am guessing you did something like tcpdump -i rl0 tcp port 80 because you let tcpdump perform DNS lookups which means you omitted the -n flag (bad idea), but I don't see the DNS packets going back and forth, which means you had some sort of tcpdump filter which doesn't show DNS packets. Better would be: # tcpdump -i ng0 -n -s 1500 -X host 209.132.176.176 # tcpdump -i rl0 -n -s 1500 -X host 192.168.82.111 so that you see all packets to/from the clients, _including_ ICMP. Something is causing a 'R' (RST) to be sent, terminating the TCP connection. I'm not sure which device this is. Anyway, there's an easy way you can prove whether MTU is the problem or not: on the Windows client, manually set the MTU to something smaller, like 1460. If that works, you know exactly what the problem is. I _think_ your problem is that you are using natd, which is creaking and ancient and maybe does not support NAT for path MTU discovery. But it maybe that PPPoE doesn't support DF properly either. You didn't show your full ipfw ruleset and natd configuration so it's hard to analyse further. Does the PPPoE connection set up some sort of virtual interface, e.g. a 'tun' interface? If so you could try setting a lower MTU on it. Otherwise, personally I would try switching from ipfw/natd to pf. Hope that gives you a few ideas. Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DHCP oddity
On Mon, Dec 26, 2005 at 12:15:14PM -0600, Skylar Thompson wrote:
> While doing some network stress-tests from a dual-CPU x86 FreeBSD 5.4
> server, I noticed that a "ping -f" drives dhcpd's CPU usage way up. I
> put dhcpd into debug mode and didn't get any error messages. I then ran
> dhcpd with strace, and saw loads of these messages when I started the
> ping flood:
>
> select(8, [?], [?], [?], NULL) = 1 ()
> gettimeofday({...}, NULL) = 0
> recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84
> select(8, [?], [?], [?], NULL) = 1 ()
> gettimeofday({...}, NULL) = 0
> recvfrom(4, 0xbfbfe090, 1500, 0, {...}, [?]) = 84
>
> Does anyone know why this would happen?
Were you running tcpdump or similar at the same time, such that the
interface was put into promiscuous mode?
Check using ifconfig that it is not (i.e. there is no PROMISC flag shown)
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp performance
On Tue, Dec 27, 2005 at 07:56:51PM +0900, Zongsheng Zhang wrote: > Hi, *, > > For testing throughput of a TCP connection, the following topology is used: > Host-A ---GB Ethernet--- Dummynet ---GB Ethernet--- Host-B > > Host-A/B use FreeBSD v6.0. Sysctl parameters of Host-A/B are: > kern.ipc.nmbclusters=32768 > net.inet.tcp.inflight.enable=0 > net.inet.tcp.sendspace=2097152 # 2M > net.inet.tcp.recvspace=2097152 # 2M > > When RTT in Dummynet is set to 0ms, the throughput (A--B) is about > 900Mbps. The buffer size is enough to fill a link bandwidth=800Mbps, and > RTT=20ms. However, if RTT is set to 20ms, the throughput is only about > 500Mbps. I don't understand what you mean by "the throughput is about 900Mbps... the buffer size is enough to fill a link bandwidth=800Mbps". What buffer size? What have you actually measured, and how have you measured it? By "RTT is set to 20ms" do you mean "dummynet delay is set to 20ms in one direction only", or "dummynet delay is set to 10ms both ways", or something else? Assuming you're not using jumbo frames, a single datagram contains 1460 bytes of payload, 40 bytes of IP header, 16 bytes of ethernet header and FCS, and a little bit of framing (I'm not sure exactly how much) So 2097152 bytes will take 1436.4 frames, giving a total of at least (2097152/1460) * 1516 * 8 = 17,420,725 bits The actual time to transmit this much data at 1,000,000,000 bits per second is 17.4 ms. If your dummynet delay is more than this, then you will not be able to keep the send pipeline full. Put another way: your delay.bandwidth product is 0.02 secs * 10 bits/sec * 1/8 bytes per bit * (1460/1516) = 2,407,651 bytes so I would expect your sendspace needs to be at least that to keep the pipeline full. This is a very simplistic analysis, someone else please feel free to substitute a more thorough one :-) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction
On Tue, Dec 27, 2005 at 10:31:48PM +0300, Gleb Smirnoff wrote: > O> I have the latest version of ported mpd (3.18_3) installed and tried > O> to insert > O> set iface enable tcpmssfix > O> but no positive result, but I understand that this option should help > O> in this situation. > > Unfortunately this options will not help in your situation. It affects > only the packets received on the mpd's interface, while you need > to alter outgoing packets. > > I have fixed this in mpd CVS, but this isn't included in any release > yet. However, if you are experienced enough with CVS you can grab > and compile sources yourself. BTW, I found a really nice description of this problem (with colourful diagrams and FreeBSD solutions) here: http://renaud.waldura.com/doc/freebsd/pppoe/#pmtu Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPSEC documentation
The IPSEC documentation at
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html is
pretty weird. It suggests that you encapsulate your packets in IP-IP (gif)
encapsulation and THEN encapsulate that again using IPSEC tunnel mode.
e.g. notice where it shows
spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
esp/tunnel/A.B.C.D-W.X.Y.Z/require;
...
ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
('ipencap' is IP protocol 4, aka RFC 2003 encapsulation). The diagram
beneath makes this double-tunnelling explicit.
This is a really strange approach which is almost guaranteed not to
interoperate with other IPSEC gateways. (It might be useful if you were
using etherip encapsulation and attempting to bridge two remote networks,
but that's not what it's doing either. In any case, if you're encapsulating
with a different protocol then you only need IPSEC transport mode, not
tunnel mode)
ISTM that this chapter should be rewritten to use IPSEC tunnel mode solely.
Do people here generally agree? If so I'll try to find the time to modify
it.
Regards,
Brian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Wed, Dec 28, 2005 at 10:08:54AM -0500, Matt Emmerton wrote: > While correct, note the scenario for which the configuration is describing: > > 14.10.3 The Scenario: Two networks, connected to the Internet, to behave as > one. > > This is something I do all the time to connect retail outlets to the server > at the head office. This double-encapsulation ensures that nobody can sniff > my packets, which contain sensitive information such as credit card data > (which is already encrypted via HTTPS, but you can't be too safe!) Well yes, but that's the whole point of IPSEC tunnel mode. The original IP datagram (header+payload) is wrapped in an ESP encrypted packet, a new IP header added (with the tunnel endpoint IPs as source and destination), and the packet is sent. If you sniff it, all you see is the tunnel header and the opaque ESP blob. You can see neither the original data nor the original source and destination IP addresses. There's no point doing GIF tunneling tunneling as well when IPSEC tunnel mode does that already. For someone new to IPSEC it confuses the issue; it adds extra processing overhead; and it reduces the number of bytes of usable payload data in each packet. I can also see a problem where someone implements the first part of this document (the GIF tunnel without IPSEC), finds that their two networks are communicating successfully, and says "great, I have a VPN, I don't need to do any more!" Or they could make a mistake with their IPSEC policy configuration, and believe that they have a secure encrypted VPN, when in fact all they have is GIF encapsulation. > > ISTM that this chapter should be rewritten to use IPSEC tunnel mode > solely. > > Do people here generally agree? If so I'll try to find the time to modify > > it. > > This perhaps would be a good _addition_ to the existing documentation -- > it's likely a configuration that many would want to set up, especially to > inter-operate with corporate networks (using commercial IPSec solutions) -- > or for those who don't need the double-encapsulation. My question is: who *does* need the double-encapsulation? I cannot see any benefit, and I can see good reasons not to do it. I would like to rewrite this document (or see it rewritten) to include: - Gateways with IPSEC tunnel mode and static keys - Gateways with IPSEC tunnel mode and racoon - Gateways with IPSEC tunnel mode, racoon and XAUTH/RADIUS (= Cisco road warrier) - IPSEC Transport mode with racoon - L2TP + IPSEC transport mode (= Windows road warrier) plus descriptions of how to get each of those to interoperate with some other common IPSEC implementations. Those are the most useful modes of IPSEC. Having others like GIF+IPSEC just complicates something which is already far too complicated, and shows a lack of understanding of the IPSEC security model anyway. If FreeBSD supports etherip encapsulation (RFC 3378), and it's possible to combine bridging with etherip and IPSEC transport mode, then that's another mode which would be useful to document (i.e. ethernet bridge over WAN) Also excellent would be "bump in the wire" bridging, where the gateway negotiates transport-mode security on behalf of clients without their being aware of it, but as far as I know only OpenBSD supports that. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Wed, Dec 28, 2005 at 04:26:43PM +0100, Eric Masson wrote: > gif/gre tunnels and ipsec transport mode are quite convenient when > associated with dynamic routing protocols. OK, I'll buy gif + IPSEC transport mode as an option. [Although in that case, perhaps what you want is an external IPSEC tunnel mode implementation which attaches to a 'tun' device. That's yet another category which I hadn't even considered] I still think that gif + IPSEC tunnel mode (as currently documented) is not a good approach, especially if it's the *only* mode of operation to be documented and hence implicitly recommended as the 'right' way to do it. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Wed, Dec 28, 2005 at 04:04:04PM +0100, Phil Regnauld wrote: > > This is a really strange approach which is almost guaranteed not to > > interoperate with other IPSEC gateways. > > It's probably for FreeBSD <-> FreeBSD setups, where it might make sense > to have an interface endpoint, rather than the "transparent" IPsec > approach -- otherwise it's not possible to route via the remote > endpoint, or apply filters at interface level before leaving the > gateway. If it's done that way purely as a workaround for limitations of the FreeBSD IPSEC architecture then that's OK, but I think it should be explicitly documented as such. Otherwise the rationale is unclear. (Presumably by "transparent" IPSEC you mean that the kernel takes care of IPSEC policy independently of ipfw/pf filtering; you're not talking about a transparent IPSEC gateway such as http://www.thought.net/jason/bridgepaper/node12.html ) It's a shame that this workaround means that you actually have to change the data format on the wire, as this will reduce interoperability. ISTM what you really want is to be able to have IPSEC tunnels each appear as separate interfaces, e.g. ipsec0 or tun0, so that firewall policy can be associated with each one. The old userland IPSEC implementations had this benefit, of course. Are any of these still maintained and usable? If so then perhaps they should also be documented as an alternative. Actually, I did come across a paper which discussed extending the socket API so that application decisions could be made on the basis of the IPSEC attributes by which the data was delivered; ah yes, here it is. http://seclab.cs.ucdavis.edu/papers/314-PHIL.pdf Integrating something like that with ipfw/pf would also give the flexibility to associate packets with their IPSEC flows. But I digress. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Wed, Dec 28, 2005 at 05:15:39PM +0100, Eric Masson wrote: > Brian Candler <[EMAIL PROTECTED]> writes: > > > OK, I'll buy gif + IPSEC transport mode as an option. [Although in that > > case, perhaps what you want is an external IPSEC tunnel mode implementation > > which attaches to a 'tun' device. That's yet another category which I hadn't > > even considered] > > Any url describing this setup please ? I don't know definitively. security/vpnc works fine for me as a client for talking to a Cisco VPN concentrator. I think that's IPSEC tunnel mode + PSK + XAUTH (which can also assign an IP address and insert routes into your forwarding table) There's net/pipsecd in ports. Its version is 19991014. I have no idea if it still works. I know of non-IPSEC solutions using tun (OpenVPN, TINC). I also know of userland IPSEC solutions which I don't think run under FreeBSD (FreeS/WAN, OpenS/WAN). All a bit of a nightmare really. Documentation would be good :-) > > I still think that gif + IPSEC tunnel mode (as currently documented) is not > > a good approach, especially if it's the *only* mode of operation to be > > documented and hence implicitly recommended as the 'right' way to do it. > > Well, ipsec section of the handbook is probably not the best one, I'd > like to see it extended with the sections you talked about in this > thread. Maybe it's time to submit patches... Sure. I first just wanted to check that there wasn't something I was missing. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Wed, Dec 28, 2005 at 05:43:39PM +0100, VANHULLEBUS Yvan wrote: > > Also excellent would be "bump in the wire" bridging, where the gateway > > negotiates transport-mode security on behalf of clients without their being > > aware of it, but as far as I know only OpenBSD supports that. > > What is the benefit of transport mode for that, instead of just using > an IPSec tunnel between the gates ??? "Opportunistic" encryption and gradual deployment. http://www.thought.net/jason/bridgepaper/node9.html (an interesting paper, read through to at least "Transparent Policy Enforcement") One use would be if you decided to roll out transport mode IPSEC across your network; you could put all the legacy hosts behind such a gateway as a transition measure until you had managed to upgrade them. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Wed, Dec 28, 2005 at 06:04:37PM +0100, Eric Masson wrote: > > Did someone tried such a setup ? > > I plan to do so. > > Just have to find ios images that support l2tp and ipsec for my 1601R > or 2611 and bigger flash modules (I've been given them two weeks ago, > hardware upgrade is the easy part, for software, hope cisco will > permit hobbyist licences one of these days) > > > is there a L2TPD daemon running on FreeBSD which could be used for > > that ? > > ports/net/sl2tps I was rather surprised that I just got IPSEC tunnel mode working between Windows XP and FreeBSD; and then afterwards I also got transport mode + L2TP working using the Windows client and sl2tps. Zounds! There is a bug (arguably) in the ipsec-tools port, in that all useful messages are logged at level 'daemon.info', but the default syslog.conf discards these messages. Once that's fixed, debugging suddenly becomes a whole lot easier :-) I've submitted a PR. sl2tps seems flaky: it dumped core once at startup, although the backtrace was nothing I could make use of (see below), as I don't know how to debug a threaded application. It also desperately lacks the ability to authenticate against a RADIUS server. Once up, I can happily ping through the L2TP tunnel and run short telnet sessions but I can't view large web pages, which looks like an MTU issue. >From the PPP negotiation it lloks like an MRRU of 1600 is offered and rejected, and 1400 negotiated instead, which ought to be OK: debug: [192.168.1.200:1701]: LCP: event UP in state STARTING info: [192.168.1.200:1701]: LCP: xmit Conf-Req #0: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] [MP-MRRU 1600] [MP-ShortSq] [EID IP:0.0.0.0] debug: [192.168.1.200:1701]: LCP: STARTING -> REQ-SENT info: [192.168.1.200:1701]: LCP: recv Conf-Rej #0: [MP-MRRU 1600] [MP-ShortSq] [EID IP:0.0.0.0] debug: [192.168.1.200:1701]: LCP: event RCN in state REQ-SENT info: [192.168.1.200:1701]: LCP: xmit Conf-Req #1: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] info: [192.168.1.200:1701]: LCP: recv Conf-Ack #1: [ACFComp] [PFComp] [Magic 0x4ae82076] [Auth CHAP-MD5] debug: [192.168.1.200:1701]: LCP: event RCA in state REQ-SENT debug: [192.168.1.200:1701]: LCP: REQ-SENT -> ACK-RCVD info: [192.168.1.200:1701]: LCP: recv Conf-Req #1: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] [Callback] debug: [192.168.1.200:1701]: LCP: event RCR- in state ACK-RCVD info: [192.168.1.200:1701]: LCP: xmit Conf-Rej #1: [Callback] info: [192.168.1.200:1701]: LCP: recv Conf-Req #2: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] debug: [192.168.1.200:1701]: LCP: event RCR+ in state ACK-RCVD info: [192.168.1.200:1701]: LCP: xmit Conf-Ack #2: [MRU 1400] [Magic 0x685733f2] [PFComp] [ACFComp] debug: [192.168.1.200:1701]: LCP: ACK-RCVD -> OPENED A tcpdump on the external interface of the FreeBSD box is a bit strange though: the client chooses an mss of 1360 (= 1400 - 40 which is IP+TCP header), but the webserver chooses an mss of 1380 which is too large: 12:06:51.773708 IP myhost.60084 > www.example.com.80: S 3030435125:3030435125(0) win 65535 12:06:51.960445 IP www.example.com.80 > myhost.60084: S 4134768352:4134768352(0) ack 3030435126 win 65535 12:06:51.961377 IP myhost.60084 > www.example.com.80: . ack 1 win 65535 12:06:51.961922 IP myhost.60084 > www.example.com.80: P 1:299(298) ack 1 win 65535 12:06:52.136869 IP www.example.com.80 > myhost.60084: . 1:1361(1360) ack 299 win 65535 12:06:52.136959 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 12:06:52.138064 IP www.example.com.80 > myhost.60084: . 1361:2721(1360) ack 299 win 65535 12:06:52.138125 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 12:06:52.139195 IP www.example.com.80 > myhost.60084: . 2721:4081(1360) ack 299 win 65535 12:06:52.139256 IP myhost > www.example.com: ICMP myhost unreachable - need to frag, length 36 As it happens this FreeBSD box is also acting as a NAT gateway using pf (myhost is on a private IP) and actually its external IP is also private - it sits behind a second NAT firewall. So maybe that's where the problem originates, although I really can't understand where the value of 1380 comes from. Regards, Brian. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Core was generated by `sl2tps'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libpdel.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpdel.so.0 Reading symbols from /usr/local/lib/libexpat.so.5...(no debugging symbols found)...done. Loaded symbol
Re: IPSEC documentation
On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote: > If we would also have NAT-T support, FreeBSD would be the best choice > of VPN concentrator. /usr/ports/security/ipsec-tools/pkg-descr says: "Known issues: - Non-threaded implementation. Simultaneous key negotiation performance should be improved." I think that would limit its usefulness as a scalable concentrator, if the comment is still valid. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Thu, Dec 29, 2005 at 01:35:21PM +0100, VANHULLEBUS Yvan wrote: > > As it happens this FreeBSD box is also acting as a NAT gateway using pf > > (myhost is on a private IP) and actually its external IP is also private - > > it sits behind a second NAT firewall. So maybe that's where the problem > > originates, although I really can't understand where the value of 1380 comes > > from. > > 1500 - (pppoe encapsulation ?) - ESP header - L2TP encapsulation Yeah, but what I don't understand is that this value was chosen by a remote webserver which is on the other side of the world, and knows nothing about the L2TP/ESP encapsulation going on locally. All it knows is that the client offered an MSS of 1360; for some reason it offered back an MSS of 1380. Weird. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
On Thu, Dec 29, 2005 at 01:38:15PM +0100, VANHULLEBUS Yvan wrote: > > "Known issues: > > - Non-threaded implementation. Simultaneous key negotiation performance > > should be improved." > > > > I think that would limit its usefulness as a scalable concentrator, if the > > comment is still valid. > > The comment is still valid, but impact is not so strong. > > Key negociations doesn't happen so much during an IPSec tunnel > lifetime, and negociating simultaneous SAs will be slow even with a > multi-threaded implementation if you have a low-end CPU. You could have a crypto accelerator card even in a low-end CPU. My concern is with long network RTTs to the clients, and packet loss. Anything like that which slows down the exchange will block out other clients from negotiating, if I understand rightly. With 10,000 clients and a phase 2 SA lifetime of one hour, that's a lot of negotiations going on, and one badly-behaved connection could cause a backlog of outstanding SA negotiations and probably a meltdown. Another issue is with DoS. Is it possible for an attacker to start an IKE exchange and get sufficiently far through it that they can block out other negotiations, before getting to the point of needing to provide valid credentials? Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: forwarding icmp redirects.
On Thu, Dec 29, 2005 at 09:01:50PM -0800, Julian Elischer wrote: > >IMHO we should disable emitting and acting upon ICMP redirects by default. > > I know many places that rely on them heavily.. please don't do that.. > Cisco PIX doesn't generate them.. it makes that machine a pain in the > to use in some situations. But you can always turn them back on if you need them. I also vote for disabling ICMP redirects by default, from painful experience. One place I worked many years ago had a pair of Cisco border routers as gateways to the outside world. They talked iBGP to each other, but just HSRP on the local network, i.e. there was a single shared IP address which the servers pointed defaultroute to. Whenever a client machine sent a packet to X.X.X.X on the Internet, it would hit whichever router was the HSRP master. If BGP said that the best egress route was via the other router, it would forward the packet to the other router but also send back an ICMP redirect saying "to reach X.X.X.X in future use Z.Z.Z.Z as your next hop" (Z.Z.Z.Z being the other Cisco's own IP) So, lots of machines on the network starting building up *permanent* forwarding table entries saying that X.X.X.X should be reached via Z.Z.Z.Z. As a result, on the day that the second router died, half the Internet became unreachable from those machines. So much for resilience! The solution was to turn off the generation of redirects on the Ciscos, followed by lots of route flushing everywhere else. But the moral is: ICMP redirects are evil and are no substitute for a routing protocol. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.0 release,
On Sat, Dec 31, 2005 at 02:52:14AM +, Paul wrote: > I've just installed FreeBSD 6.0 Release yesterday, I've spend the last > two days trying to resolve a networking problem, the problem is this: > when I try and connect to a domain or an IP for that matter, it takes > several minutes for it to connect + receive the content. It doesn't > seem to effect all addresses though, I've had no problems connecting > to ftp://ftp.freebsd.org to download software etc., nor have I had any > problems connecting to domains inside my LAN. > > As far as I can tell, it isn't a dns problem because I can ping > without any problems. I had a similar problem here, and it was due to IPv6. Grr, I hate it. What happened was: some router was allocating IPv6 prefixes, and so my network interface picks up an IPv6 address. However actually there is no working IPv6 connectivity here. As a result, whenever I try to connect to a site which has both IPv6 and IPv4 addresses, I get a long delay of several minutes while the IPv6 one is tried out, before it falls back to IPv4. To show if this is the problem, use 'ifconfig' to show if your interface has been polluted by an IPv6 address. Then use 'ping6 www.foo.com' where www.foo.com is one of the sites you're having problems with. The problem is hidden by ping because ping only asks the DNS for IPv4 addresses. You can check if a site has an IPv6 address using $ dig www.foo.com. or $ nslookup -q= www.foo.com. IMO, the best solution to this is to remove IPv6 entirely from your kernel (comment out 'options INET6' and recompile). Your life will be much happier. Of course this would not be a problem if the IP stack were to try IPv4 addresses first, falling back to IPv6 if it fails. Of course, if IPv4 were to have precedence over IPv6, then the IPv6 stack would never get exercised. This is one of several problems which have plagued me simply because IPv6 is enabled by default when I don't want or use it. However if that's not the problem, then maybe your problem is with reverse DNS. That is, when you connect from your address (x.x.x.x) to a remote site (y.y.y.y), the remote site may do a reverse DNS lookup for x.x.x.x to try to find your hostname; if it gets a hostname, it will then do a forward DNS lookup to see if it maps back to x.x.x.x. You won't notice this problem as DNS lookups with ping, because you're just mapping www.foo.com to y.y.y.y; you're not trying to convert your own address x.x.x.x back to a domain, as a remote webserver would do. The solution then is to fix your reverse DNS. If your own IP address is 192.0.2.1, then a PTR query for 1.2.0.192.in-addr.arpa. is where you should be looking. Probably you have a lame delegation somewhere in the tree. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/lib/libc/net/res_debug.c: compile problem fixed
On Mon, Jan 02, 2006 at 12:39:26PM +1030, Aluminium Oxide wrote: > Below is the output of `diff res_debug.org.c res_debug.c` > > I've also attached this. > = > 574,575c574,575 > < precsize_aton(strptr) > < char **strptr; > --- > > precsize_aton(char **strptr) > > /* char **strptr; */ > 616,618c616,618 > < latlon2ul(latlonstrptr,which) > < char **latlonstrptr; > < int *which; Suggestion: use unified diff (diff -u res_debug.org.c res_debug.c). It's *much* easier to read. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sl2tps, MRU, MTU, and MSS
I've done a bit more debugging on the MSS problem I'm having with sl2tps running with IPSEC transport layer security. The client is Windows XP out-of-the-box. Here's what happens: 1. PPP negotiates an MRU of 1400 2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) 3. When the client opens a TCP connection, it offers an MSS of 1360 4. When the remote webserver responds, it offers an MSS of 1380 (?) 5. The client sends a HTTP request, the server responds (MSS1360 / MTU1400), but that's too large to fit ng0 (MTU 1376) [EMAIL PROTECTED] ~# ifconfig ng0 ng0: flags=88d1 mtu 1376 inet 172.17.0.216 --> 192.168.100.100 netmask 0x [EMAIL PROTECTED] ~# tcpdump -i rl0 -n -s1500 tcp port 80 or icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 1500 bytes 10:41:16.454720 IP 172.17.0.216.58826 > 212.100.234.54.80: S 1482417021:1482417021(0) win 16384 10:41:16.464675 IP 212.100.234.54.80 > 172.17.0.216.58826: S 1193972421:1193972421(0) ack 1482417022 win 5840 10:41:16.465486 IP 172.17.0.216.58826 > 212.100.234.54.80: . ack 1 win 17680 10:41:16.466490 IP 172.17.0.216.58826 > 212.100.234.54.80: P 1:522(521) ack 1 win 17680 10:41:16.477538 IP 212.100.234.54.80 > 172.17.0.216.58826: . ack 522 win 6432 10:41:16.485841 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1:1361(1360) ack 522 win 6432 10:41:16.485983 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36 10:41:16.487047 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1361:2721(1360) ack 522 win 6432 10:41:16.487114 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36 10:41:19.512030 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1:1361(1360) ack 522 win 6432 10:41:19.512182 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36 172.17.0.216 is the IP address of the FreeBSD box; the client's L2TP pool address has been NATted to this using pf. And of course, being a private address, the FreeBSD box is also behind a NAT firewall. And because of this, the ICMP 'need to frag' message isn't getting back to the webserver, and everything falls over. So I have the following questions: 1. If the PPP MRU is 1400 (which appears to be correctly picked up on the Windows side), why is the ng0 MTU 1376? 2. How can I fix this problem, without manually frigging the MTU at the Windows client side? I don't think the IPSEC transport header is anything to do with this: the PPP session sits *within* the IPSEC encapsulation, and 1400 is plenty of space for an IPSEC header to be added and still fit within Ethernet MTU. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DHCPD + Relay
On Mon, Jan 09, 2006 at 08:59:56PM +0100, Jon Otterholm wrote: > I am having trouble to get isc-dhcp-server to start up without a > subnet-declaration for a local subnet. Write empty subnet declarations for those subnets. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NAT over IPSECed WLAN
On Mon, Jan 16, 2006 at 11:13:32AM +0100, Przemyslaw Szczygielski wrote:
> Well, for me the config is so complex, that I doubt anyone will
> waste time on going into my config files, but, well... There's
> always hope...
A diagram helps lots. Tell me if this is correct:
\|/ - - - - - - - \|/
| |
10.2.0.2 10.2.0.1 ndis0
WinXPFreeBSD 6.0
client x.x.x.x fxp0
|
+---> Internet
<==>
IPSEC tunnel mode?
> I have a working setup that has working NAT ("Client" sees Internet
> throuogh NAT on "Gateway", configured as default gateway on
> Windows), when IPSEC is turned off.
>
> I also have working IPSEC between these two machines (they can ping
> each other) but then NAT stops working (but "Gateway" still connects
> to the Internet, so i.e. I can putty from "Client" to "Gateway", it
> goes through IPESECed WLAN, and from putty use Lynx to browse. But
> can't browse internet on "Client".
>
> So to make it short: IPSEC working = no NAT. IPSEC off = NAT working.
It's possible that IPSEC isn't configured properly, since you have IPSEC
only ever working between the two endpoints.
How have you configured IPSEC:
(a) on the Windows XP box? and
(b) on the FreeBSD box?
I think you should be running IPSEC tunnel mode, so I'm guessing at the
Windows XP side you have something like:
ipseccmd -f 0=* -t 10.2.0.1 -a PRESHARE:"foo"
ipseccmd -f *=0 -t 10.2.0.2 -a PRESHARE:"foo"
And at the FreeBSD side you have in /etc/ipsec.conf
spdflush;
spdadd 10.2.0.2/32 0.0.0.0/0 any -P in ipsec
esp/tunnel/10.2.0.2-10.2.0.1/require;
spdadd 0.0.0.0/0 10.2.0.2/32 any -P out ipsec
esp/tunnel/10.2.0.1-10.2.0.2/require;
Also, the output of 'tcpdump' on both ndis0 and fxp0, while you try to
browse a website from the XP box, could be very enlightening.
Regards,
Brian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NAT over IPSECed WLAN
On Mon, Jan 16, 2006 at 02:30:08PM +0100, Przemyslaw Szczygielski wrote:
> > ipseccmd -f 0=* -t 10.2.0.1 -a PRESHARE:"foo"
> > ipseccmd -f *=0 -t 10.2.0.2 -a PRESHARE:"foo"
> >
>
> XP: (configured by wizard, from MMC):
>
> "InboundIPsec" prot: ANY, src port: ANY, dst port: ANY, src IP:
> ANY/0, dst IP: MY/0
>
> "OutboundIPsec" prot: ANY, src port: ANY, dst port: ANY, src IP:
> MY/0, dst IP: ANY/0
But if you've not given any tunnel endpoints, then you have configured
*transport* mode, and that won't work for communicating with arbitary hosts
on the Internet.
Perhaps you've got tunnel mode (I guess you must if you have tunnel mode in
your SPD), but I'd still prefer working from the command line. To get
ipseccmd.exe run setup.exe from the \support\tools directory on the XP SP2
CD.
Note that in XP you can give 'MY' as a policy source/destination ('0' in
ipseccmd), but not as a tunnel endpoint. You must give the explicit IP
address, as in the -t example above.
> > And at the FreeBSD side you have in /etc/ipsec.conf
> >
> > spdflush;
> > spdadd 10.2.0.2/32 0.0.0.0/0 any -P in ipsec
> esp/tunnel/10.2.0.2-10.2.0.1/require;
> > spdadd 0.0.0.0/0 10.2.0.2/32 any -P out ipsec
> esp/tunnel/10.2.0.1-10.2.0.2/require;
> >
>
> BSD:
>
> flush;
> spdflush;
> spdadd 10.2.0.2/8 0.0.0.0/0 any -P in ipsec
> esp/tunnel/10.2.0.2-10.2.0.1/require;
> spdadd 0.0.0.0/0 10.2.0.2/8 any -P out ipsec
> esp/tunnel/10.2.0.1-10.2.0.2/require;
10.2.0.2/8 can never match any IP address, but perhap the kernel masks it
silently to 10.0.0.0/8
In any case, you should list only the address which you want to protect
(i.e. 10.2.0.2/32), unless there is a separate subnet sitting behind the XP
laptop which needs to be protected.
Otherwise, once you have a second laptop, you will have two conflicting
policies, both trying to protect 10.0.0.0/8
> > Also, the output of 'tcpdump' on both ndis0 and fxp0, while you try to
> > browse a website from the XP box, could be very enlightening.
> >
> Ermmm... on ndis0 I can only see encrypted content, but haven't
> tried fxp0, thought nothing interesting will be happening, as I
> can't browse from XP...
Not true. Seeing what packets are sent out to the Internet, even if nothing
comes back, is definitely interesting. It would show, for example, if your
NAT isn't working.
Even if nothing at all goes out of fxp0, that is also interesting. It shows
your tunnel is not configured correctly. (Presumably you do have IP
forwarding turned on, since the gateway works in the absence of IPSEC)
I suggest you don't "browse" from XP: start by sending pings. Then you have
a steady stream of packets, and DNS doesn't get in the way either.
Regards,
Brian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NAT over IPSECed WLAN
On Mon, Jan 16, 2006 at 08:55:18PM +0100, Przemys?aw Szczygielski wrote: > Well - both ways work. The one from the wizard and the one by > ipseccmd. The difference is i don't know how to deactivate ipseccmd > filters ;-) ipseccmd -u > From XP I pinged 10.2.0.1 with IPSEC on > > tcpdump -i ndis0 host 10.2.0.2 on 10.2.0.1 showed encrypted packets ESP packets with source 10.2.0.2 and destination 10.2.0.1? Is the SPI in your SAD? # echo "dump;" | setkey -c > tcpdump -i fxp0 host 10.2.0.2 on 10.2.0.1 showed nothing... Hmm. Then I would next try turning off ipfw completely, to see if you get outgoing non-NAT packets on fxp0 with a source of 10.2.0.2 and destination of x.x.x.x If so, you've narrowed it to an ipfw problem. If you're trying to do reverse-path checking or the like, that could be it. Turning on logging for all deny rules might help locate it. If you still think its an IPSEC problem, "options IPSEC_DEBUG" might also be useful. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: pf: redirect packets from localhost
On Wed, Jan 18, 2006 at 03:49:18PM +0100, Sebastian Schwerdhoefer wrote: > Short question: > Is it possible to redirect packets from localhost with "rdr"? Short answer: yes. Longer answer: perhaps this is the kind of thing you're looking for. http://lists.freebsd.org/pipermail/freebsd-pf/2005-September/001487.html http://lists.freebsd.org/pipermail/freebsd-pf/2005-September/001495.html http://lists.freebsd.org/pipermail/freebsd-pf/2005-September/001498.html (Note that there is a pf-specific mailing list...) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC documentation
> On Thu, Dec 29, 2005 at 09:50:47AM +0300, Alexey Popov wrote:
> > If we would also have NAT-T support, FreeBSD would be the best choice
> > of VPN concentrator.
I just saw this patch posted on the ipsec-tools-devel list:
http://ipsec-tools.sf.net/freebsd6-natt.diff
It's for FreeBSD 6 but also seems to apply cleanly to 5.4, apart from one
file which I think needs this instead:
--- ./netinet/in_proto.c.orig Mon Mar 21 16:05:35 2005
+++ ./netinet/in_proto.cFri Jan 20 21:41:59 2006
@@ -108,7 +108,7 @@
&nousrreqs
},
{ SOCK_DGRAM, &inetdomain,IPPROTO_UDP,PR_ATOMIC|PR_ADDR,
- udp_input, 0, udp_ctlinput, ip_ctloutput,
+ udp_input, 0, udp_ctlinput, udp_ctloutput,
0,
udp_init,0, 0, 0,
&udp_usrreqs
Haven't tested it yet - just waiting for kernel to recompile :-)
Regards,
Brian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sl2tps, MRU, MTU, and MSS
On Thu, Jan 05, 2006 at 11:04:04AM +, Brian Candler wrote: > I've done a bit more debugging on the MSS problem I'm having with sl2tps > running with IPSEC transport layer security. The client is Windows XP > out-of-the-box. > > Here's what happens: > > 1. PPP negotiates an MRU of 1400 > 2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) > 3. When the client opens a TCP connection, it offers an MSS of 1360 ...and then fragmentation problems occur, because the remote server sends IP datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU 1376 rejects them, the generated ICMP messages are discarded by an intervening NAT gateway, and the TCP connection fails. > [EMAIL PROTECTED] ~# ifconfig ng0 > ng0: flags=88d1 mtu 1376 > inet 172.17.0.216 --> 192.168.100.100 netmask 0x I've done some digging, and I've found the sources of this problem, but I don't know what the right fixes are. After PPP has negotiated an MRU of 1400, why does the ng0 interface get an MTU of 1376? There appear to be two reasons for this. (1) In libpdel, file ppp/ppp_link.c, the interface MRU is explicitly set to 20 less than the requested MRU: #define WINXP_PPTP_HACK(x)((x) - 20) /* winxp pptp stupidity hack */ ... lconf->mru = MIN( WINXP_PPTP_HACK(link->lcp_req.mru[PPP_PEER]), ppp_channel_get_mtu(link->device)); My test client for L2TP over IPSEC does happen to be WINXP, but as far as I can see this hack is done unconditionally. (2a) In libpdel, file ppp/ppp_bundle.c, the interface MTU is taken from the PPP MRU, and then additionally 4 is subtracted if conf.mppe_40, conf.mppe_56 or conf.mppe_128 is set. if (bundle->conf.mppe_40 || bundle->conf.mppe_56 || bundle->conf.mppe_128) mtu -= 4; /* allow for mppe header */ Note that this happens even if MPPE has not been negotiated. (2b) in sl2tps, file sls_manager.c, conf->mppe_128 is set to 1 conf->mppe_128 = 1; conf->mppe_stateless = 1; Now, if I modify sl2tps to set conf->mppe_128 to 0, and I change the WINXP_PPTP_HACK macro to make it a no-op, my L2TP/IPSEC client connects, ng0 gets the correct MTU of 1400, and TCP traffic flows happily through the tunnel. So what's the correct fix? Well in case (2), I'd have thought that the MTU should not be reduced by 4 unless MPPE has actually been negotiated in CCP (option 18, see RFC 3078). For case (1), I don't know, because I don't know where the WINXP_PPTP_HACK macro comes from or under what circumstances it is required. All I can say is that WINXP using L2TP over IPSEC does *not* need this hack (and indeed, the hack breaks things). Perhaps it should only be used if PPTP is the underlying transport. I don't know if there's a straightforward way to detect when that's the case. Is there anyone here who knows the libpdel ppp code better and can suggest the right fixes? Thanks, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Named could not listen on UDP socket: permission denied
On Thu, Jan 26, 2006 at 05:01:50PM +0200, Oleg Tarasov wrote: > I run FreeBSD 6.0 and I have begun to recieve quite periodic error messages > like these: > > Jan 25 19:45:50 central named[728]: could not listen on UDP socket: > permission denied > Jan 25 19:45:50 central named[728]: creating IPv4 interface ng0 failed; > interface ignored > > ng0 is my main internet interface and is created on early boot > (rcordered like ppp-user) by mpd. Certainly, I need DNS listening on > this interface. > > The reason is that if mpd is restarted for some reason, interface ng0 > is destroyed and created again while listener on this interface is > destroyed too. Named is chrooted at this time and cannot re-bind > listener on this interface. Only manual restart of named helps it bind > to this interface. > > This is not deadly situation as if I manually restart mpd I will be > able to restart named too... > > Running named under root user or out of chroot environment is not > quite acceptable way... named needs to be root in order to bind to port 53. If ng0 has a fixed IP address, then you could configure an alias on lo0 with that address. Then, even though named cannot rebind to ng0, it will still answer queries to that address. If ng0 has a dynamic address, then I think your only solution is to run named as root within a chroot environment or jail(8) - or to write a script which is run when ng0 comes up, which kills and restarts bind. Does mpd have a hook to call a script on interface up? Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sl2tps, MRU, MTU, and MSS
On Fri, Jan 27, 2006 at 08:39:41AM -0600, Archie Cobbs wrote: > Brian Candler wrote: > >>1. PPP negotiates an MRU of 1400 > >>2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) > >>3. When the client opens a TCP connection, it offers an MSS of 1360 > > > >...and then fragmentation problems occur, because the remote server sends > >IP > >datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU > >1376 rejects them, the generated ICMP messages are discarded by an > >intervening NAT gateway, and the TCP connection fails. > > Sounds like the NAT gateway is the root cause of all this, no? > > While all the MTU logic in slt2ps is probably not optimal, in theory > it shouldn't matter if it's not optimal because ICMP should be working. > A router is supposed to be able to reduce the MTU if it needs to and > things should continue to work. > > Instead of "fixing" sl2ps to work in your particular situation (and > breaking it in other situations), is it possible to fix/replace the > broken gateway instead? (Try a FreeBSD box instead :-) It's a PIX. Perhaps I should draw out the test scenario properly just to make sure all is clear: fxp0 rl0 RFC1918 pub Win FreeBSD 6.0 ---//-- firewall Internet XP + ipsec-tools PIX + sl2tps <> L2TP over IPSEC The FreeBSD box runs pf NAT, in order for the IP address given out from the sl2tps pool to be usable. The rl0 address is from private address space, as it hangs on an office network. The PIX firewall also runs NAT to give external connectivity. When I bring up the tunnel, LCP negotiates an MRU of 1400. The Windows box is happy with this, and therefore chooses a TCP MSS of 1360 for outbound connections. FreeBSD configures its ng0 interface with an MTU of 1376. Even if this is technically allowed, because path MTU discovery should take care of it, it's certainly suboptimal, since we *could* send datagrams with an MTU of 1400 over the negotiated tunnel. Although I understand your argument that the PIX is broken, there are also parts of the Internet which wrongly block ICMP fragmentation-needed messages. Unfortunately, fixing the whole Internet is outside of my power. However I'm happy to rely on the vast majority of the Internet supporting an MTU of 1500, and for the last hop to be lower than this since the originating socket will directly set the initial MSS to an appropriate value. > Some background as best as I can remember... > > The reduction of MTU to account for PPP protocol overhead (MPPE) is > not controversial. Obviously if the hard MTU is (say) 1400 and you've > got 4 bytes of MPPE overhead, then the interface MTU should be <= 1396. > > You're right that this shouldn't really happen unless MPPE is actually > negotiated, but that's harder to do.. MPPE negotiation happens after > link negotiation. To avoid this, disable MPPE if you can. OK. I already changed sl2tps not to allow MPPE. I guess an option in config.xml would be better. > The WinXP hack is something that at some time was deemed necessary to > work around a bug in Windows XP. As I recall, it would advertise a MRU > that was actually bigger than what it would really accept. Since there > was no easy way to detect WinXP clients, we had to put in this workaround > unconditionally. This may have only been a bug in pre-SP2 WinXP. It > was (IIRC) when trying to do L2TP over IPSec, not PPTP. To paraphrase your words: instead of "fixing" sl2tps to work in this particular situation, is it possible to fix/replace the broken WinXP box instead? :-) The WinXP box I'm using is running SP2, and doesn't seem to have the bug you describe. Since SP2 has been out for a long time, perhaps it would now be reasonable to drop this workaround, or to make it a compile-in option. In any case, I think pre-SP2 XP has other problems with IPSEC, so any serious XP user should be upgrading to SP2 anyway. Besides which, any PPP implementation which announces an MRU of X but then refuses to receive packets of size X is so totally broken that it defeats the object of PPP option negotiation in the first place. Cheers, and thanks for your quick response, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sl2tps, MRU, MTU, and MSS
On Fri, Jan 27, 2006 at 10:39:08AM -0600, Archie Cobbs wrote: > First of all, let's be clear about terminology.. there are two different > MRU's negoatiated in opposite directions and those negoations are done > independently. The problem, which is basically "the FreeBSD->WinXP MTU > is causing a PIX-bug-triggering MSS in the WinXP->FreeBSD direction" > arises because: > > - WinXP sets its MSS (which applies to data flowing in the FreeBSD->WinXP >direction) based on the MTU that it sees (which applies to the >WinXP->FreeBSD direction). This is a heuristic "guess" made by the >TCP stack, based on the assumption that the link is MTU-symmetrical. > - This "guess" is wrong and because of path-MTU problems can't be >corrected. I have to admit that it's a long time since I used dial-up PPP, so I'm very rusty on all of this :-) I thought the L2TP link was symmetric in my test (i.e. both sides accepted 1400) but I don't have the logs to hand, so I'll have to check that when I'm next in the office. As an observation: when you ifconfig ng0, you can't set separate "transmit MTU" and "receive MTU". So I imagine that the configured MTU only applies to outbound datagrams, i.e. it means "don't transmit any datagram larger than this on this interface". If ng0 were to *receive* a datagram larger than the MTU I don't know for sure what would happen, but given that it was successfully received, I see no reason why the kernel should discard it. So the ng0 MTU should just match the requested MRU from the WinXP side, and all will be well in that direction. Equally, the WinXP interface MTU should match the MRU requested by FreeBSD. > In any case, in the FreeBSD -> WinXP direction, you say we could send 1400 > byte packets out the ng0 interface, but this is not necessarily true. What > is the MRU that the WinXP machine asked for? If it's 1400, then the ng0 > interface must definitely be < 1400, because of PPP overhead (e.g., IPCP). > The 1400 negiotiated by LCP applies to PPP frame payload, not IP size. I think you're mistaken; see here in RFC 1661 | 2. PPP Encapsulation | ... |+--+-+-+ || Protocol | Information | Padding | || 8/16 bits| * |*| |+--+-+-+ | ... | The maximum length for the Information field, including Padding, | but not including the Protocol field, is termed the Maximum | Receive Unit (MRU), which defaults to 1500 octets. By | negotiation, consenting PPP implementations may use other values | for the MRU. And explicitly in RFC 1332 (IPCP): |The maximum length of an IP packet transmitted over a PPP link is the |same as the maximum length of the Information field of a PPP data |link layer frame. So, a PPP MRU of 1400 lets you send an IP datagram of size 1400. Of course, IPCP is just a control protocol for negotiating IP options. There is no "IPCP overhead" when encapsulating an IP datagram, since the IPCP exchange has already finished. In any case, I didn't see anything in libpdel which tried to make allowance for a smaller IP MTU than the PPP MRU, except the WINXP_HACK > Seems like the proper workaround would be to configure sl2tps to negotiate > a smaller MRU (WinXP->FreeBSD direction) than 1400. There's no config > knob for this but one could be added. Then WinXP would "guess" better. Bear with me while I try to understand this. We have two independent channels, as you say. 1. For the flow of packets from FreeBSD to WinXP: WinXP < FreeBSD <--- rest of world 1a. WinXP asks for MRU of 1400 1b. FreeBSD accepts this 1c. FreeBSD configures the MTU in this direction as 1376, for its own reasons 2. For the flow of packets from WinXP to FreeBSD: WinXP > FreeBSD ---> rest of world 2a. FreeBSD asks for MRU of 1400 2b. WinXP accepts this 2c. I presume WinXP configures the MTU in this direction as 1400, although I don't know how to confirm this (i.e. ipconfig doesn't show the MTU) Now: when opening a TCP connection to the outside world, Windows proposes an MSS of (2c)-40, since there are 40 bytes of IP+TCP headers. So yes you're right, if FreeBSD is going to choose an MTU of 1376 in step 1c, then it could propose an MRU of 1376 in step 2a, so that Windows would choose an MSS of 1376-40. However I don't see how it could do this (easily), since it would have to wait until it has finished negotiating the MRU from WinXP (step 1a/1b) before it could even offer an MRU in the opposite direction (step 2a). This does seem to be a lot of hoops to jump through, when you could simply fix step 1c: if the WinXP machine says it can receive 1400-byte datagrams, then configure the interface to send it datagrams of up to 1400 bytes! > >Besides which, any PPP implementation which announces an MRU of X but then > >refuses to receive packets of size X is so totally broken that i
Re: /usr/src/lib/libc/net/res_debug.c: compile problem fixed
On Sun, Jan 29, 2006 at 06:50:06PM +1030, Aluminium Oxide wrote: > > Suggestion: use unified diff (diff -u res_debug.org.c res_debug.c). It's > > *much* easier to read. > > > > Regards, > > > > Brian. > > Thankyou Brian, I've done as you suggested. > > Q: How can I edit the new PR title to reflect that I've fixed the > problem? You mean this one? http://www.freebsd.org/cgi/query-pr.cgi?pr=92488 Audit-Trail State-Changed-From-To: open->closed State-Changed-By: arved State-Changed-When: Sun Jan 29 09:46:25 UTC 2006 State-Changed-Why: You are using unsupported CFLAGS ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: multiple natd + ipfw, with 2 internal ip's
On Sat, Jan 28, 2006 at 01:01:53PM +0100, Unix-Solutions - Steven wrote: > Hi you guy's, > > I have a little problem with my natd or ipfw configuration. This may not be what you want to hear, but in my experience if you have a configuration with multiple external interfaces and multiple NAT instances, ipfw + natd becomes almost impossible to configure correctly. You need multiple running instances of natd, which isn't a problem, but making a set of ipfw rules which correctly passes the right packets to the right natd instances, both inbound and outbound, is pretty hard. If I were you, I'd switch to pf. Having two NAT interfaces in pf.conf is trivial. So then the only thing you need to do is to swing your defaultroute from ISP1 to ISP2, to change the traffic flow. > Now I want to add 192.168.2.253 as alias on the FXP0 > and when a PC on my internal network sets his gateway to 192.168.2.253 > I want that this PC takes the versatel route. > How is this possible ? Unfortunately, it's not possible at all. When your PC sends a packet from X.X.X.X to Y.Y.Y.Y, and decides that 192.168.2.254 is the next hop router, it uses ARP to find the MAC address of this router. It then encapsulates the IP datagram in an ethernet frame using this as the destination MAC address. If it decided to use 192.168.2.253 as the next hop, and this is an alias on the same machine, then it would still get the same MAC address. So when the packet arrives at the router, it would be impossible to tell whether the originator had used 192.168.2.254 or 192.168.2.253 as the next-hop address. (That's unless you do something very nasty, like assigning multiple MAC addresses to the same interface and writing your own ARP daemon to respond with different MAC addresses, but even then you would still have to somehow make a forwarding decision based on the MAC address of the incoming frame. You could put two different NICs on the same LAN segment, which would automatically give you two MAC addresses and let you forward based on the source interface, but I think that FreeBSD still has a problem when running two NICs on the same LAN segment, because it mixes the ARP table into the forwarding table) If you want to selectively have some clients using ISP1 and other clients using ISP2, then I think you could implement that using pf 'route-to' or ipfw 'fwd' rules, matching the source IP address, which is a lot simpler. In any case, if all you're concerned about is failover, then you probably don't want to reconfigure every client PC when ISP1 goes down in order to point to ISP2. Rather, you could run a script on the gateway PC which monitors the link status, and changes its own defaultroute to point to the other ISP. HTH, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/lib/libc/net/res_debug.c: compile problem fixed
On Mon, Jan 30, 2006 at 08:50:00AM +1030, Aluminium Oxide wrote: > A... > > You're right, but there's only a handlful of these that stop buildworld > with -O3 I think the issue is that although you may be able to get FreeBSD to *build* using -O3, it's quite unlikely that it will *work* properly. If I understand correctly, gcc -O3 makes a lot of assumptions about when it's OK to keep values around in registers, which may not be valid when there are interrupts or other threads modifying memory. I think it's possible to make the code -O3 safe, e.g. by putting loads of 'volatile' declarations in, but catching every single case where this is required is extremely different. This may be more of a problem with the kernel than with userland though. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network client is the same from server
On Mon, Jan 30, 2006 at 10:51:28AM -0800, Julian Elischer wrote: > Tiago Cruz wrote: > > >On Fri, 2006-01-27 at 13:19 -0800, Julian Elischer wrote: > > > > > > > >>it is definitly possible > >>but you will have to do some reading > >>natd can do it. > >> > >> > > it should be in the natd man page.. (or libalias page) Maybe, but it's not very clear though. I think he needs to NAT destination addresses as well as source addresses, and statically map a whole /24 to another /24. Put diagramatically: 192.168.0.0/24 192.168.0.0/24 --+-- GW1 GW2 -+--- | | X Y In order to allow X (say 192.168.0.1) to communicate with Y (say also 192.168.0.1), then we need to map both address ranges into new space. Let's say we use 192.168.100.0/24 for the first network and 192.168.200.0/24 for the second network. Then the connection from X to Y will appear to be from 192.168.100.1 to 192.168.200.1 when viewed on the middle wire. So at GW1, *outbound* packets from 192.168.0.X to 192.168.200.Y need to have their *source* IP mapped to 192.168.100.X At GW2, *inbound* packets from anywhere to 192.168.200.Y need to have their *destination* IP mapped to 192.168.0.Y Plus the mirror: at GW2, outbound packets from 192.168.0.X to 192.168.100.Y need to have their source IP mapped to 192.168.200.X; at GW1, inbound packets from anywhere to 192.168.100.Y need to have their destination IP mapped to 192.168.0.Y The only way I can see to do this with natd is with 254 separate -redirect_address rules. On GW1 you'd need -redirect_address 192.168.0.1 192.168.100.1 -redirect_address 192.168.0.2 192.168.100.2 ... and on GW2 you'd need -redirect_address 192.168.0.1 192.168.200.1 -redirect_address 192.168.0.2 192.168.200.2 ... Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network client is the same from server
On Tue, Jan 31, 2006 at 12:42:36PM -0800, Julian Elischer wrote: > >And, If I have't not control about the second gateway? Because my client > >have a notebook, and he can try connect at anyplace, anytime :-( > > > >So, I think that is impossible to to... is true? > > > > > no, > you should be able to do it all on your own machine I think.. > by NATing on both interfaces, effectively puting your machine in the middle, > with one natd on each interface. Some careful thought is needed though. Before: 192.168.0.0/24 [nat1][nat2] 192.168.0.0/24 --+-- GW1 GW2 -+--- | | X Y After: 192.168.0.0/24 192.168.0.0/24 --+-- GW1 GW2 -+--- | [nat1] [nat2] | X Y In this example, the sense of 'inbound' and 'outbound' is wrong for each natd, which you might be able to fix using -reverse on both of them. Or: 192.168.0.0/24 192.168.0.0/24 --+-- GW1 GW2 -+--- | [nat2] [nat1] | X Y Here the in/out sense is the same, but now we're doing nat2's processing before nat1's. Is that a problem? I think it is. * Packet from 192.168.0.1 to 192.168.200.1 - at nat2: destination changed to 192.168.0.1 - at nat1: source changed to 192.168.100.1 Trouble is that at the first step, the destination is now 192.168.0.1, which means it will be delivered back to the local LAN instead of out of the external interface. So a pair of natd's with -reverse and 254 -redirect_address flags each *might* be able to fix your problem. If it gets any more complex than this - let's say you need another natd for traffic destined to the public Internet, while traffic to 192.168.200.0/24 is nat'd down a tunnel to the second network - then it becomes a PITA. I don't like natd/ipfw interaction, if you hadn't guessed :-) OTOH, it might not be easy to make work with pf either. You should only need two 'binat' rules, but I'm not sure how you go about reversing the in/out sense. There's a separate freebsd-pf mailing list which might be able to help. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: freebsd 6.0 network card / route fail over question
On Fri, Feb 03, 2006 at 01:33:44PM -0600, Matthew Lineen wrote: > I'm trying to workout the specifics of NIC/route fail over on FreeBSD > 6.0 and hoped someone here could point me in the right direction. > > We have 2 ServerIron load balancers and each of our application servers > is plugged into both LBs. > > So, for example, an app server would have the following... > > bge0 IP of x.y.z.61 netmask 255.255.255.128 > bge1 IP of x.y.z.63 netmask 255.255.255.128 > > In /etc/rc.conf the default route is x.y.z.1 > > In the routing table, the default route uses Netif bge0. So, when we > turn off the first load balancer, bge0 goes down, but the default route > never "moves" from bge0. > > I assume this is because ... > > #1 - FreeBSD doesn't like having two interfaces bound to the same > x.y.z/25 network (we get plenty of the "arp: x.y.z.123 is on bge0 but > got reply from ... on bge1" messages) Correct. > #2 - The default route is bound to bge0 because bge0 is the first > interface that contains an IP in the same network as the default route's. > > So, my question is: what approaches do people take to solve this > problem? I've come across forwarding and carp, but I thought I'd ask > the list to see if there is something simple I'm missing, other ways of > handling this, etc... I don't see a simple alternative. The approaches I can see are: (1) The layer 2 approach. Try to make an ethernet bundle consisting of two links; a single IP address will be shared by both. I don't know if FreeBSD supports this, and in any case, it will almost certainly only work if the two uplinks go into the same switch. (2) The layer 3 approach. Assign bge0 and bge1 different IP addresses (preferably on two different subnets). Learn your default route via OSPF or RIP from the upstream router(s), using something like quagga. Given that the upstream devices are ServerIrons, which are really just fancy switches, this may not work, but maybe you can get a RIP defaultroute announcement out of them. (3) The layer 7 approach. On each server just have a *single* uplink into one of the two ServerIrons, and rely on your application failover mechanism. You presumably have multiple application servers, so if a whole server fails, everything keeps working properly, right? In that case, rely on this mechanism to cope with the case where your server's NIC or the cable or the upstream switch fails. Make sure half the servers are on one switch and half on the other, so if the whole switch fails, you still have half your servers reachable. And keep a spare switch in the closet. Method (3) is the one I've used successfully for a mailserver cluster. There were two MX receivers, two webmail servers, four POP3 servers; half on one uplink and half on the other. IMO it's at least as likely likely that a whole server will fail (bad PSU, failed hard drive etc) than the NIC or switch port fails. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fastforward problem
On Sat, Feb 11, 2006 at 05:35:33PM +0100, GiZmen wrote: > I would like to use fastforward option on my freebsd 6.0-stable > box. But i have strange problem with it. My box is a router for LAN > with IP visible to internet. I am managinc C class network. > When i turn on fastforward option any of the computers in my network > can't open google.com page. This option is quite good because i have > quite a lot interrupts and this option lower this about half. > Could anyone tell me why i can't open google.com page ? > I have tested different pages and i don't have such problem only with > google. Just saying "I can't see google.com" is not a good diagnosis of the problem. If it's your job to manage a router, then you need to be able to do lower- level tests to isolate the problem. Check each of the components in turn: (1) can my client resolve google.com in the DNS? If the client is some sort of Unix then try $ nslookup google.com You should see a response such as: Non-authoritative answer: Name: google.com Address: 72.14.207.99 Name: google.com Address: 64.233.187.99 Name: google.com Address: 64.233.167.99 (2) can my client ping these addresses? That is, is there layer 3 network reachability between my network and theirs? $ ping 72.14.207.99 PING 72.14.207.99 (72.14.207.99): 56 data bytes 64 bytes from 72.14.207.99: icmp_seq=1 ttl=238 time=133.730 ms 64 bytes from 72.14.207.99: icmp_seq=2 ttl=237 time=133.179 ms 64 bytes from 72.14.207.99: icmp_seq=3 ttl=238 time=133.316 ms 64 bytes from 72.14.207.99: icmp_seq=4 ttl=237 time=133.396 ms ^C --- 72.14.207.99 ping statistics --- 5 packets transmitted, 4 packets received, 20% packet loss round-trip min/avg/max/stddev = 133.179/133.405/133.730/0.203 ms (3) what happens when I open a TCP/IP connection to port 80, and manually fetch a HTTP page? $ telnet 72.14.207.99 80 Trying 72.14.207.99... Connected to 72.14.207.99. Escape character is '^]'. GET / HTTP/1.0 Host: google.com < end with a blank line HTTP/1.0 301 Moved Permanently Location: http://www.google.com/ Set-Cookie: PREF=ID=f811e9355f349c08:TM=1139748428:LM=1139748428:S=UhZOEU98p2mnw_H0; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com Content-Type: text/html Server: GWS/2.1 Content-Length: 219 Date: Sun, 12 Feb 2006 12:47:08 GMT Connection: Keep-Alive 301 Moved 301 Moved The document has moved http://www.google.com/";>here. Connection closed by foreign host. OK, that's fine. google.com has redirected me to www.google.com. So try the whole process again with www.google.com instead of google.com Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fastforward problem
On Sun, Feb 12, 2006 at 09:53:44PM +0100, GiZmen wrote: > Yes, clients can ping google IPs. > > ping 64.233.187.99 > PING 64.233.187.99 (64.233.187.99): 56 data bytes > 64 bytes from 64.233.187.99: icmp_seq=0 ttl=238 time=155.613 ms > 64 bytes from 64.233.187.99: icmp_seq=1 ttl=238 time=152.681 ms > > PING 72.14.207.99 (72.14.207.99): 56 data bytes > 64 bytes from 72.14.207.99: icmp_seq=0 ttl=237 time=142.530 ms > 64 bytes from 72.14.207.99: icmp_seq=1 ttl=237 time=143.632 ms > 64 bytes from 72.14.207.99: icmp_seq=2 ttl=237 time=143.517 ms > > > (3) what happens when I open a TCP/IP connection to port 80, and manually > > fetch a HTTP page? > > When i try connect by telnet i have smth like this. > > telnet 64.233.167.99 80 > Trying 64.233.167.99... > Connected to 64.233.167.99. > Escape character is '^]'. > GET / HTTP/1.0 > Host: google.com > > > Connection closed by foreign host. > > There is nothing happening after pressing enter couple times the connection > is closing by foreigh host. Next: in another window, do # tcpdump -i fxp0 -n -s1500 -X (replace fxp0 with your external interface name). Then at the same time, have one of the clients do the same test (3). If you see too much tcpdump output, then try # tcpdump -i fxp0 -n -s1500 -X host 64.233.167.99 or icmp What you're looking for is the connection being closed, and what device is closing it (Google? Perhaps some upstream device?) I can only guess at a few causes. (1) Broken DNS. Your IP address maps to host.example.com but host.example.com does not map back to the same IP address. Since you've not said your client's IP address, I can't check this for you. I'd expect the server to drop the connection immediately in this case, but it's still worth checking. (2) Upstream from you is some sort of transparent HTTP proxy/cache, which is broken. To test this theory, try # telnet 1.1.1.1 80 Does this connect? Or does it time out after 75 seconds? If it connects, there's almost certainly a transparent cache upstream. (3) You have some sort of path MTU issue. I don't know why. Perhaps your upstream link is running PPPoE or something which is not clear for 1500-byte packets. If so, it ought to work, but bad filtering of ICMP or bad use of NAT can cause problems. Try to run a tcpdump as far up the upstream path as possible, to see what's going on. Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: socket / bind - specific address
On Sat, Feb 25, 2006 at 06:07:22PM +1100, Edwin Groothuis wrote: > The situation is as follows: > > We have a couple of FreeBSD routers, with RFC1918 addresses on the > ethernets and a public address on the loopback. This works fine for > connecting to the routers, but is problematic for locally originated > outgoing traffic (think NTP, think syslog): it takes the IP address > of the outgoing interface, which is the RFC1918 address. > > Is there a way (sysctl, kernel option) to define which IP address > is used for locally originated outgoing traffic? One way is to run your daemon (ntpd, syslogd etc) within a jail, and give the jail your public loopback as its IP address. Another is just to configure each daemon to bind to the appropriate port, if it supports that option. syslogd has a '-b' flag; I don't know if ntpd can be configured thusly. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nfs locking broken
On Fri, Feb 24, 2006 at 03:58:09PM +0100, Palle Girgensohn wrote: > It seems that NFS locking is broken for the combo of 4.11 or 5.4 server and > 6.x client. Apps like eclipse and firefox fail to start with my home dir on > a 4.11 server and a 6.x client. This in interesting to me - I'll explain why in a moment. But firstly, do you have any evidence that this is an NFS locking issue? I thought (maybe incorrectly) that FreeBSD did not implement NFS locking on the server side at all, only as a client. My issue is this. I used to use a noisy but fast 2.4GHz machine as my general-purpose workstation - browsing, compiling etc. I have now moved this onto a low-power passively-cooled machine (Mappit A4F) which is fantastic; I can leave it on 24x7 and it doesn't make a whisper. However to have fast compiling when needed, I decided to export /home from this box to the old fast machine. I thought that I should just be able to compile software as before, but some makefiles just don't seem to work. The clocks on the two boxes are synchronised, to within a second anyway. I haven't yet taken the time to nail down what the problem exactly is though. Maybe it *is* relying on locking somehow, directly or indirectly. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: floating a server room... how do you deal with ethernet connections?
On Mon, Mar 13, 2006 at 02:57:35AM -0600, Nikolas Britton wrote: > I'm currently planning renovations for the power mains supplying are > server room. One of the ideas I have is to float the entire room using > a isolation transformer. The only problem to this solution, that I can > think of, is that all of the equipment that's attached to the other > end of the Ethernet cabling won't be isolated, the NIC cards do have > 1:1 transformer coupling for the wire pairs but... In the event of > power surges, spikes, brownouts, and/or nearby lighting strikes I feel > that It's conceivable for there to be a large voltage differential on > the wires that could damage the equipment on ether end of the wire. > > Are there any easy (cheap) work arounds to this problem You could use fibre. Might not immediately qualify as "easy or cheap", but then again, if you've got local distribution switches in each floating rack, then all you need is fibre uplinks to the central switching infrastructure. But apart from that, I can't say how good an idea floating the room is. AFAIK, most mains inlet filters have some inductive and capacitive components to earth, so it may not float that far. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is NFS production-ready ?
On Mon, Apr 10, 2006 at 11:26:40PM +0400, dima wrote: > 3. Is at least implementation of NFS client (either kernel-side or > user-space) stable enough for production use? Client OS replacement is > impossible (hardly suitable, really) in my project. I built a big mail/web cluster a few years ago using FreeBSD 4.x (4.6.2 I think), where all the front-ends used NFS to access data on a shared fileserver platform (NetApp). It worked without a hitch, and still does. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: is NFS production-ready ?
On Tue, Apr 11, 2006 at 05:59:50PM +0400, dima wrote: > > I built a big mail/web cluster a few years ago using FreeBSD 4.x (4.6.2 I > > think), where all the front-ends used NFS to access data on a shared > > fileserver platform (NetApp). It worked without a hitch, and still does. > > What is the reaction on network/NAS failure? > I mean, I'm about to provide transparent storage service in the case of > failures of different types. It never came up as an issue. The backend was a clustered NetApp pair, so if one failed, the other head-end would take over the disks belonging to the first one, and continue to serve from the same IP address. However, I believe that if you do a "soft" mount, and the server goes away, eventually the client will get an I/O error. The client program has to be written in such a way as it will handle I/O errors in all situations (and many are not) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPPoE question.
On Wed, Apr 12, 2006 at 11:27:00AM +0800, fooler wrote: > >what the heck is synchronous pppoe? we connect to pppoe via ethernet so > >it is already synchronous (?) > > set speed sync And how does that change the pppoe ethernet frames? ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: PPPoE question.
On Wed, Apr 12, 2006 at 10:59:52PM +0800, fooler wrote: > >>set speed sync > > > >And how does that change the pppoe ethernet frames? > > nothing change and still the same... ethernet frames are at layer 2 while > synchronization (either asynchronous or synchronous) is at layer 1... > synchronous is much better than asynchronous for ethernet links... Then I think you have a misunderstanding. Ethernet frames are *always* synchronous. There are no 'start' and 'stop' bits in ethernet, only frame delimiters. The sync/async difference only has meaning for serial links (e.g. where layer 1 is RS232 / V24) PPP frames carried inside ethernet (i.e. pppoe) are therefore also carried using synchronous encoding, since ethernet is synchronous. Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Libpcap based: packet generator + capture file editor + bridge for IEEE802.3 on FreeBSD
On Sun, Apr 16, 2006 at 08:02:04AM -0700, Yeow C.H. wrote: > It is designed to compliment tcpdump, which by itself has done a great > job > in capturing network traffic. With Bit-Twist, you can now regenerate the > captured traffic onto a live network. Packets are generated from saved > tcpdump > capture file (trace file). Interesting - how does it differ from /usr/ports/net-mgmt/tcpreplay ? Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to use if_bridge
On Tue, Apr 18, 2006 at 01:14:27PM +0200, Sten Daniel Srsdal wrote: > hostap should work, ad-hoc should work. by infrastructure you mean that > the card operates as a 'station'? then it shouldn't work (correctly) as > defined by the standard. commercial products tend to implement "mac-nat" I've seen this; a 'wireless bridge' is actually a masquerading router. See http://forum.openwrt.org/viewtopic.php?id=5105 for some ARP and tcpdump capture which shows the device actually mangling the ARP responses. It does seem to work though (as long as you only want to bridge IP datagrams) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VLAN interfaces and routing
On Wed, Apr 26, 2006 at 01:55:11PM +0100, William wrote: > The switch is a Cisco 3550, trunking is setup on the port and I've > allowed the VLANS I'm interested in using. > > The end result is being able to communicate with all devices on said > VLANS which is fantastic but my next objective is to have the box talk > to other networks via a default route, I've tried applying the default > route by defaultrouter= in rc.conf, also manually adding it using > route once the box has booted up but it always results in no replys > back from other networks, even netstat -r seems to hang. The hang is probably just because your DNS server is unreachable. Use "netstat -rn" instead, or just rm /etc/resolv.conf. (It annoys me that traceroute and some versions of ping and telnet default to trying DNS lookups, when if there's a network problem the DNS server is probably not available) Manually adding the route ought to be fine. Can you ping your default gateway? Does 'ifconfig -a' show the correct settings? The default gateway must be on a directly-connected network of course, i.e. within the range of one of the subnets shown by 'ifconfig -a'. When you ping the default gateway, does the ARP cache get updated? (arp -an) HTH, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DHCP Over PPPoE
On Thu, Apr 27, 2006 at 02:38:03PM +0530, JOBY THAMPAN wrote: > > > Hi all , > > > > I have a setup like this > > > > Linux Machine 1 > > Eth0- DHCP Server > > > > > > Linux Machine 2 > > Eth1- Got IP from DHCP Server > > Eth0- PPPoE Server > > ppp0 Interface formed > > > > > > Linux Machine 3 > > Eth0- PPPoE Client > > Eth1- IP is 192.168.40.1 > > ppp0 Interface formed > > Dhcp Relay is running on Linux Machine 3 > > > > > > Windows Machine 4 > > Expecting an IP of 192.168.40. after renewing the ip address > > of windows machine > > > > But there is no result > > > > Without PPPoE interfaces the windows machine is getting an > > ip in the range 192.168.40. > > > > Wouldn't DHCP Protocol work over PPP Interface? Yes. But those are Linux machines, and this is a FreeBSD mailing list, so you are asking in the wrong place. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: DHCP Over PPPoE
On Thu, Apr 27, 2006 at 11:14:09AM -0700, Julian Elischer wrote: > > > A few things.. > > 1/ thisn is a FreeBSD list so we are not very familiar with linux. > 2/ PPPOE uses PPP which is a point-to-point protocol and does not support > broadcast. > 3/ DHCP is a broadcast protocol and does not support point-to-point > networks. > 4/ PPP (oE) has its own IP allocation mechanism. But note that he is using DHCP relaying to a remote DHCP server. This original DHCP broadcast is picked up and turned into a unicast message for relaying to the DHCP server. This works quite happily over PPP or indeed any intervening IP network and any number of hops. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [fbsd] Re: [fbsd] Network performance in a dual CPU system
On Mon, May 01, 2006 at 11:38:39AM +1000, [EMAIL PROTECTED] wrote: > Would it be possible to improve the behaviour of the TCP protocol > implementation so that out-of-order reception was acceptable? Possibly - but if your FreeBSD box is acting as a router, and it re-orders packets in transit to the rest of the Internet, then in principle you'd need to upgrade the TCP implementations on every other device in the Internet :-( ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How do i send mail to certain domain users over external smtp using sendmail?
On Wed, May 10, 2006 at 05:47:48AM -0700, Nash Nipples wrote: >hi, i just dont see any options to make it work > > "| /usr/sbin/sendmail -Ac -t" works fine > but "| /usr/sbin/sendmail -O ConnectOnlyTo=smtp.external.co... -Ac -t" just > wont work: > WARNING: RunAsUser for MSP ignored, check group ids (egid=10103, want=25) > can not chdir(/var/spool/clientmqueue/... Permission denied > Program mode requires special privileges, e.g., root or TrustedUser. > 554 5.3.5 Local configuration error > > I dont want to set up trusted users. Any work-around available? Upgrade to exim - *any* mail routing policy you can think of can be implemented in exim. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How do i send mail to certain domain users over external smtp using sendmail?
On Thu, May 11, 2006 at 06:19:59AM -0700, Nash Nipples wrote: > Upgrade to exim - *any* mail routing policy you can think of can be > implemented in exim. > >lol thanks! i've read about it and i think its awesome but yet i dont >know how do i uninstall sendmail? It's part of the base system, so you just ignore it. 1. Install exim from ports or packages 2. Edit /etc/mail/mailer.conf so that it reads sendmail/usr/local/sbin/exim send-mail /usr/local/sbin/exim mailq /usr/local/sbin/exim # optional extras newaliases /usr/bin/true hoststat/usr/local/sbin/exim_dumpdb /var/spool/exim wait-remote_smtp purgestat /usr/local/sbin/exim_tidydb -t 1d /var/spool/exim wait-remote_smtp (I'm not sure if the port does that for you automatically) 3. Edit /etc/rc.conf sendmail_enable="NONE" exim_enable="YES" So whilst this doesn't actually purge your system of the devil-spawn, it does neutralise it :-) The default install works as a basic out-of-the-box sendmail: i.e. it delivers to mbox files /var/mail/foo, honours /etc/aliases and .forward files. You then read the config samples and start tweaking to add whatever features and policies you like. The entire flow-of-control, from accepting mail to delivering it, is soft-coded in the configure file (but it doesn't look like Snoopy swearing) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can't delete route
On Thu, May 18, 2006 at 02:52:19PM -0300, Alexandre Biancalana wrote: > > > # route add 128.110.0.0 255.255.0.0 10.0.0.17 > > > add net 128.110.0.0: gateway 255.255.0.0 ... > > >Running netstat -nr I get the following: > > > > > > 0&0xa11255.255.0.0UGSc 15 332 fxp0 => ... > Have some way to remove this stupid route without flushing the routing > table ??? > This machine is main gateway of the company and I can't do a route flush > now, but I need to have this new route working... Try: # route delete -net 0.0.0.0 -netmask 10.0.0.17 (i.e. network 0, netmask &a11, like the netstat entry shows). I've tried it here, it successfully removes your junk route under 6.0 Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
On Fri, May 19, 2006 at 12:38:31PM -0400, Mike Tancsa wrote: > Thanks for the reply. Even at 28.8 I am seeing loss with > the connection dropping and seeing dropped packets (e.g. > May 19 12:04:43 soekris4801 ppp[3404]: tun0: Phase: 1: HDLC errors -> > FCS: 1, ADDR: 0, COMD: 0, PROTO: 0) If you have an error-correcting modem, but you are seeing data corruption, then I'd expect the data corruption is occuring on the RS232 link between the PC and the modem at one end or the other. You may have a handshaking problem (i.e. ensure the modem is configured for CTS/RTS handshaking, and the port is configured for this too; with pppd it's "crtscts", I don't know about userland ppp; and ensure the cables are wired properly) If your app could cope with the lack of bandwidth, forcing the modems to 2400bps operation can make links over dodgy lines a lot more reliable. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
On Sun, May 21, 2006 at 11:09:23AM -0400, Mike Tancsa wrote: > The internal USR seems to correctly see the carrier drop and PPP > hence sees it. However, the 2 external Intels I am experimenting > with on the USB serial ports do not. USB-serial adaptors tend to be very broken, unfortunately. I don't know about under Windows, but under FreeBSD/Linux where drivers seem to be reverse-engineered, several I've tried don't seem to handshake properly. I tried two back-to-back to run a local pppd link and it failed (haven't had time to debug that one) IMO there's no substitute for a real COM port. > (not sure why, but chats tx/rx are for all calls in the pas 216 days, > not just this one). This is in the past 4hours. Perhaps with this > one, I am just better off telling it not to try v.90. A pair of analogue modems will never negotiate v90, as for this one end has to be digitally connected (typically T1/E1 trunk, although in theory you might be able to find a modem which is physically connected as ISDN BRI but which supports v90 analogue modulation) The best you'll get is v34bis (33.6K) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to Quicken TCP Re-transmission?
On Mon, May 22, 2006 at 07:51:33PM +0800, [EMAIL PROTECTED] wrote: > I want to transmit data between host A and host B. The link between > these two hosts is really bad: PING reports 30% packet loss How big are the pings? Try ping -c100 -s1472 x.x.x.x to send 1500-byte pings (20 bytes IP header + 8 bytes ICMP header + 1472 bytes padding). This will give you a more realistic indication of packet loss for TCP transfers than the small pings you get by default. TCP performs really, really badly on packet loss over 5%. I don't think that any amount of tweaking will cope with 30% packet loss. Perhaps a mechanism which sends each packet 3 times would work, but then tripling the load on your link will increase your packet loss even more, perhaps leading to total collapse. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: improving transport over lossy links ?
On Tue, May 23, 2006 at 02:10:39PM -0400, Mike Tancsa wrote: > It looks like its an issue with the USB serial device and or driver. > Whether the driver or the actual device (or both) not sure. If I put > the same 2 modems put on 2 regular serial ports, ppp is able to see > the carrier is down and drop the connection from the bundle. Same > init strings, only difference is the ports they were on. That matches my experience with USB dongles. The basic functionality of sending and receiving characters is there, but flow control and call handshaking tends to be either non-existent or flaky. I expect this is either because the drivers are reverse-engineered, but the person doing the reverse-engineering wasn't thorough enough to toggle all the control lines, in and out; or because these chipsets are actually not full RS232 implementations. Either way it makes them pretty useless for anything more than a 9600bps console (and even then, they're risky if you want to squirt a string of bytes at the target device) It's a real shame, because most laptops don't have COM ports these days. If someone knows of a USB serial dongle which is widely available, documented by the manufacturer, and has a full robust implementation of all the RS232 control lines in an open-source driver, I'd like to buy one. For some laptops a PCMCIA COM port is an option, but many modern laptops don't have that slot either these days. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: VPN with FAST_IPSEC and ipsec tools
On Fri, Jun 16, 2006 at 01:43:54PM +1000, Michael Vince wrote: > I have setup the GRE tunneling and that is working fine doing pings and > tracerts when I disable ipsec and ipsec-tools, its just the encryption > side thats the problem. Ah, I guess this means you're following the instructions in the FreeBSD handbook, which last time I looked gave a most bizarre and unnecessary way of setting up IPSEC (GIF tunneling running on top of IPSEC *tunnel* mode). I raised it on this list before. Most people are better off just setting up IPSEC tunnel mode. A few use GIF running on top of IPSEC _transport_ mode (e.g. those running routing protocols like OSPF over tunnels) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Simple LAN IP accounting
On Sun, Jun 18, 2006 at 07:26:44AM -0700, Nash Nipples wrote: >ipfw add 5 skipto 500 ip from 192.168.110.1 to any out via tun0 > ipfw add 10 skipto 500 ip from any to 192.168.110.1 to any in via tun0 > ipfw add .. skipto 500 ip from 192.168.110... to any out via tun0 > ... > ipfw add 500 divert from any to any in via tun0 #back to normal rules > > ipfw show > 5 274943 64986791 ip from 192.168.110.1 to any out via tun0 > 00010 274943 64986791 ip from any to 192.168.110.1 in via tun0 > > thats pretty stupid but works. and you need a program to proccess the output > thats what im working on time to time :) > > it doesnt overload the filter cuz a matching rule is passed once at a time > and the unmatched skipped to normal rules. if you get out of ipfw rules > limits you might consider to split.. lol > > anyone else? Another approach is to capture absolutely everything using libpcap into a userland process, and then post-process afterwards. This is how 'ntop' works. At a very simplistic level you could just use tcpdump -w to capture the packets (or packet headers) into a file, and then tcpdump -r to pipe them into a script to analyse them, such as totalising the sizes of all packets to/from a particular IP address. Another approach is to use statistical sampling - pick packets at random, so that overall you capture, say, 1 packet in 128, and analyse those. This is the approach used by sflow. If you have an sflow-capable switch, this is a very efficient way of doing this analysis. You can turn the sflow data into simple CSV records using 'sflowtool', or ntop has an sflow module. This assumes that taking the sampled data and multiplying it by 128 will be sufficiently accurate for your purposes, of course. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Simple LAN IP accounting
On Sun, Jun 18, 2006 at 08:21:51PM +0200, Phil Regnauld wrote: > > very efficient way of doing this analysis. You can turn the sflow data into > > simple CSV records using 'sflowtool', or ntop has an sflow module. > > Ntop just seems very unreliable and bloated to me, at least after > version 1. Has it changed ? I don't know. I looked at it briefly recently, but it didn't do what I wanted (which was to be able to export and analyse *all* flows seen). At least, there was an "export" function, but it was broken. If you just want something to visualize your top 20 traffic sources and protocols, i.e. keep an eye on your network and notice sudden new large sources such as viruses or P2P nodes, it may be useful. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange errors from BIND on FreeBSD 4.x system
On Wed, Jul 05, 2006 at 09:39:17PM -0600, Brett Glass wrote: > I'm working with a client's FreeBSD system (4.9 with patches) which > is having trouble resolving certain domains but not others. When I > try to execute the same queries using "dig", I see the error message > > res_nsend: Protocol not supported > > Via various search engines, I've seen hints that the problem may > have something to do with IPV6 but no instructions as to how to > resolve it. Can anyone explain what's wrong and how to fix it? The nameserver you're trying to talk to has both IPv6 and IPv4 addresses, dig is trying to use the IPv6 one, but failing because your host doesn't have IPv6 connectivity. Example: ;; ANSWER SECTION: ns-pri.ripe.net.166057 IN A 193.0.0.195 ns-pri.ripe.net.72477 IN 2001:610:240:0:53::3 If you try "dig @ns-pri.ripe.net. ripe.net. soa" I suspect you will get this error. (Of course, this bug only happens because the IPv6 address is tried in preference to IPv4 whenever this case occurs. Life would be much easier if it tried IPv4 in preference to IPv6 - but then the IPv6 stack would never get exercised at all. That would be a good thing IMO :-) Solutions: (1) try rebuilding the kernel with INET6 commented out. Or if it's commented out now, try rebuilding with it back in. I can't remember which way round caused the problem. (2) otherwise, you could upgrade dig to a version from a newer version of BIND, as ISTR this was fixed in the application. So much for the IPv4-IPv6 transition being transparent to applications :-( Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange limitation on rcmd()
On Fri, Jul 07, 2006 at 08:30:01PM -0400, Mikhail Teterin wrote: > The manual page says, that rcmd() is only to be used by root's processes. DESCRIPTION The rcmd() function is used by the super-user to execute a command on a remote machine using an authentication scheme based on reserved port num- bers. Note that only root can bind to reserved ports. > On other OSes (Solaris, AIX), trying to call rcmd() without being root simply > fails. > > FreeBSD, however, tries to be helpful and invokes rcmdsh in this case, which > is inefficient and leaves the stderr's filedescriptor (fd2p) unfilled. > > Why? > > My understanding is, this is to make it harder for would-be attackers to > attack machines with .rhosts-based security. But that is nothing more than a > bad band-aid anyway -- attacker's own implementation of rcmd() (without the > geteuid() checks) is trivial... But an attacker who doesn't have root won't be able to use their own implementation of rcmd(). It will just fail. Either the attacker will ask to bind to a privileged port (which will fail at the local host), or they will bind to a non-privileged port (in which case the remote host will reject the request) rsh is a setuid root binary. It is able to bind to privileged ports, whilst performing security checks that the requested access is valid. In the same way, the 'passwd' command lets you change your own password, without letting you change someone else's. > So, without providing any meaningful security improvement (who is relying > on .rhosts for security anyway?!), we are impeding a very useful > functionality. No security improvement is implied. Rather, you just get extra functionality. Instead of a dead failure, certain non-root requests are allowed (i.e. user A on host X can run commands as user A on host Y) > rcmd offers an efficient way to send your data to a command "abroad" and even > has a mechanism for getting the remote's stderr -- assuming, your network is > secure enough for you to trust .rhosts. And the requesting user is running as root, so they can bind to a privileged port. > Why are we duplicating the misguided efforts of commercial Unixes and > limiting > it to root only? Because this is exactly how the .rhosts security model works - it accepts requests only from privileged ports, which in turn means that it knows the request only came from root. This mechanism is only valid for trusted hosts, of course. If you allow a random person to put their own PC on the network, they can of course send packets from privileged ports (either by installing Unix with their own root password, or by installing DOS and sending packets which come from privileged ports) HTH, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange limitation on rcmd()
On Mon, Jul 10, 2006 at 11:47:33AM -0400, Mikhail Teterin wrote: > What I remain upset about, though, is that the rcmdsh(), which is used by > rcmd() ignores the fd2p parameter making it impossible to capture the > remote's stderr... Well, it's probably worth send-pr'ing it. I'd first test whether rsh itself forwards stderr properly. Maybe there's some underlying reason why rcmdsh doesn't have an fd2p argument. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: counting (not) blocks of IPs in ipfw - please help
On Mon, Jul 10, 2006 at 06:40:50PM -0400, Ensel Sharon wrote:
> I can't seem to get ipfw to handle a rule like this:
>
>
> ipfw add 00100 count ip from any not { 10.20.0.0/16 or 10.30.0.0/16 } to
> any via em0 in
>
> The error is:
>
> ipfw: missing ``to''
> ipfw: unrecognised option [-1] 10.20.0.0/16
Firstly, "from any XXX" is giving two different 'from' items. I guess you
meant "from not { 10.20.0.0/16 or 10.30.0.0/16 }". But that doesn't work
either:
# ipfw add 00100 count ip from not { 10.20.0.0/16 or 10.30.0.0/16 } to any via
fxp0 in
ipfw: hostname ``{'' unknown
According to the manpage, that syntax is not allowed. Notice:
[proto from src to dst] [options]
...
src and dst: {addr | { addr or ... }} [[not] ports]
...
addr: [not] {any | me | me6 table(number[,value]) | addr-list | addr-set}
i.e. "not { x or y }" is not a valid 'src'
The obvious boolean transformation doesn't work, since "and" is not allowed
either: i.e.
# ipfw add 00100 count ip from { not 10.20.0.0/16 and not 10.30.0.0/16 } to any
via fxp0 in
ipfw: missing ")"
I think you need to use a table. Or choose another workaround, e.g. two
rules with separate counters, or two rules which jump to another rule which
does the counting.
Regards,
Brian.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: forcing FTP-uploaded files to be of certain types only
On Mon, Jul 17, 2006 at 01:06:01PM -0400, Mikhail Teterin wrote: > How hard would it be to make the stock FreeBSD FTP-server to examine the > first, say, 100Kb of the uploaded file and interrupt transfer if the file is > of a prohibited or is not of an allowed type? > > Anything under 100Kb is fine, I guess, and 100Kb is more than enough to > detect > compression or lack thereof... I think the first few bytes should be enough to tell you if it's a gzip, pkzip or compress archive: $ gzip -c -9 /etc/services | head -c64 | file - /dev/stdin: gzip compressed data, was "services", from Unix, max compression $ compress -c /etc/services | head -c64 | file - /dev/stdin: compress'd data 16 bits $ zip - /etc/services | head -c64 | file - adding: etc/services /dev/stdin: Zip archive data, at least v2.0 to extract How wedded are you to FTP? If this was a HTTP 'PUT' then a simple CGI could read in 100 bytes, check it is compressed (e.g. with libmagic), then copy through the rest of the file. The result from the PUT can be a HTML page saying "all OK" or "please compress your data first" Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple NAT router
On Fri, Jul 21, 2006 at 11:13:47AM -0600, Brett Glass wrote: > I have an application in which I'd like a FreeBSD router to have > multiple, isolated LANS attached to it, each with the same address > space. The FreeBSD box would take the place of multiple NAT routers. > > For example, I might want to have three internal Ethernet > interfaces on the FreeBSD box. Each would be connected to a LAN > whose internal addresses are 192.168.0.0/24. The FreeBSD box would > do NAT for all of them, and of course they could not "see" one another. FreeBSD won't support this 'out of the box' - because of the problem that you identified of having multiple NICs all with the same address range assigned to them. There's a project called 'vimage' which adds a separate virtual forwarding table per jail. This might work for you, although all the natd's "outside" interfaces would need to sit on the same interface, and I don't know if it can do that. Otherwise - you can run multiple instances of FreeBSD under a virtual machine environment like Xen or VMware, and bridge all the 'outside' interfaces together onto the same NIC. Also - you may still end up with a separate outside IP per vimage or VM, so maybe then you need another NAT instance to NAT all of those onto a single IP address :-) Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: using loopback address as primary address
On Mon, Jul 24, 2006 at 12:38:56PM +0300, Nikos Vassiliadis wrote: > Can I somehow use lo1 address > for connections initiated from Host_2? Options I know of: (1) the application which originates the connection can explicitly bind to the lo1 address (see for example telnet -s and ping -S options) (2) the application can run in a jail(8) whose IP address is lo1, in which case a 'bind to any' will bind to this address only (3) use source NAT with pf etc ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple NAT router
On Mon, Jul 24, 2006 at 04:09:29PM +0200, Marko Zec wrote: > > There's a project called 'vimage' which adds a separate virtual forwarding > > table per jail. This might work for you, although all the natd's "outside" > > interfaces would need to sit on the same interface, and I don't know if it > > can do that. > > Yes this should work with a virtualized stack - all the "outsied" interfaces > in each jail / virtual stack could be simply bridged together using netgraph > which is virtualization-agnostic, i.e. a global facility in the current > implementation of "vimage". > > Of course a significant problem might be that the stack virtualization > patches > exist only for FreeBSD 4.x, but there's a very good chance that a formal > project aimed at bringing vimage into sync with 6.x and -CURRENT could start > shortly... Also, what would really suit him is a netgraph IP interface node - i.e. something which takes raw ethernet frames from the interface, performs IP encapsulation/decapsulation and ARP - and an IP forwarding node with its own forwarding table. Has anyone done any work in that area? It would be really cool for VPN edge routing, for example. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple NAT router
On Mon, Jul 24, 2006 at 01:40:13PM -0700, Julian Elischer wrote: > an ng_ip node :-) > I've considerred it. Then all the tools like 'netstat' and 'route' need modifying to talk to a netgraph socket, but in principle I don't see why it couldn't be done. ISTM there are a zillion userland-to-kernel and kernel-to-kernel communication interfaces: - ioctl - geom - cam - netgraph - vfs - sysctl - kmem - procfs - ... Perhaps they could all be replaced by netgraph?? Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple NAT router
On Mon, Jul 24, 2006 at 09:17:37PM -0600, Brett Glass wrote: > I've been noodling over this for two weeks now, and am thinking > that the easiest thing to do might be is map every address in each > "virtual" router to a unique address from FreeBSD's point of view > (i.e. 192.168.0.2 on LAN 1 becomes 10.0.0.2, while 192.168.0.2 on > LAN 1 becomes 10.0.1.2, etc.). The translation would be done by > "hooks" as close as possible to the interfaces, so FreeBSD's stack > wouldn't know it was being done. > > All that would be needed in that case would be to do "dumb" address > translation at the interfaces -- transparently to FreeBSD -- just > before the packets entered and left. One problem is managing the allocation of the translated addresses. But why not do dumb mapping of IPv4 addresses to IPv6 ? That would let you have up to 2^96 "virtual routers", and finally provide a reason for the IPv6 code to exist :-) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: No DHCPOFFERS received.
On Tue, Aug 01, 2006 at 02:43:22AM +, Alexandre Martins Garcia wrote: > Hello everybody, > I have a modem connected to my freebsd machine in ethernet, so to have a > configuration from my ISP I did: > > hydrus[/home/amg]# dhclient fxp0 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 5 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 11 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 9 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 15 > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 12 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > But it gives this error saying No DHCPOFFERS received... > > Anyone had this problem before? And how to fix this? :-S Erm, does your ISP "modem" definitely offer a DHCP service? In that case it would be a "router". Maybe you need to talk PPPoE instead. Have a look at their instructions for configuring a Windows client. If it talks about setting up a dialler, where you enter a username and password, then it's PPPoE. For a FreeBSD PPPoE client, look at /usr/ports/net/mpd HTH, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Redundant/failover NFS servers - stale NFS file handle
On Mon, Aug 14, 2006 at 08:43:28PM +0200, Attila Nagy wrote: > >We use NetApp Filer clusters (NAS) for that purpose. > >They aren't cheap, but they work very well. > I don't like blackboxes with nice GUIs. :) They have a command-line interface too :) Seriously, these are really excellent devices. > >There's another possibility, but I haven't tried it for > >myself, so it's just theory. :-) You can try to put > >geom_mirror (see gmirror(8)) on top of geom_gate (see > >ggated(8), ggatec(8)). Then you will have a RAID1 with > >one component local and the other component remote. > >However, I think it only works reliably in read-only > >mode. > Yes, both of them must be read only, several years ago I've used a > similar setup, but with a shared SCSI disk. > Read only on the client side is OK for me, but is hard to maintain on > the server side. > I guess it would be possible to do this RW, mounted only on the master > and if it fails, remounted (fscked, etc) on the slave, but I consider > that a little bit hackish. The filesystems would have to be mounted RO on both NFS servers, in other words be entirely static content. This is because both boxes have local caches. If an update were to occur on box 1, and be propagated to box 2 via ggated, then even if box 2 has the filesystem mounted RO it will then have stale data in its local caches of disk blocks and inodes, because the blocks on disk have changed under its feet. At best, the wrong data will be served. At worst, the whole filesystem will crash due to inconsistencies. So to make an update, you would have to unmount from box 2, remount RW on box 1, make the change, remount RO on box 1, and mount RO again on box 2. > I can solve this problem with Linux How? > Of course what is really needed here is a cluster filesystem, or an NFS > server/file system which can solve this problem at its level. Indeed. This was discussed at some length before, and the same answers were given. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Redundant/failover NFS servers - stale NFS file handle
On Tue, Aug 15, 2006 at 02:44:52PM +0200, Attila Nagy wrote: > >>I can solve this problem with Linux > >How? > With a shared filesystem of course. Specifically, which one? If there is a good filesystem for this application perhaps it could be ported. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Redundant/failover NFS servers - stale NFS file handle
On Tue, Aug 15, 2006 at 11:20:47AM -0700, Chuck Swiger wrote: > On Aug 15, 2006, at 5:30 AM, Phil Regnauld wrote: > >Brian Candler (B.Candler) writes: > >>So to make an update, you would have to unmount from box 2, > >>remount RW on > >>box 1, make the change, remount RO on box 1, and mount RO again on > >>box 2. > > > > To make it short: if you want a reliable NFS head, you need NetApp. > > If you want to make failover, you'll need something like WAFL that > > has virtual inodes and allows for concurrent access from multiple > > writers. This is more of a freebsd-fs discussion. > > I think Solaris also makes a reliable NFS platform, and it even > supports failover and replication for read-only mounts. For read/ > write replicated filesystems, you're probably looking at AFS (Andrew > File System, but an opensource version is at www.openafs.org from > IBM, who apparently bought out Transarc) or maybe Coda. Hmm, I'm not sure I'd want to run Maildir on either of those, or at least Coda. When I looked at Coda, ISTR you could have conflicting updates in disconnected operation which required manual intervention to fix. Admittedly this was a few years ago, maybe things have moved on since then. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Routing IPSEC packets?
On Fri, Aug 18, 2006 at 11:59:39AM +0200, Remko Lodder wrote: > Ofcourse I should do the [1] trick: > > I want to do the following; I have three IPsec endpoints > at this moment, one at home, one in my personal colo environment > and one in another colo environment. > > The machine(s) in the personal colo environment are the point > to where all the others connect to. So the other colo env > connects to the personal colo environment, and my home also > connects to the personal colo environment. > > I would like to be able to: > > Other colo -- ipsec tunnel -- personal colo -- ipsec -- home > > Have these communications possible, and ofcourse the other way > around. In the event that another tunnel will be attaching, > I would like to be able to route these packets to the other > host as well (so that I can reach all the IPsec tunneled hosts > from the IPsec network, from where-ever I will be, either road > -warrior, or just at home, or at one of the colo machine's). That's fine, you just have to set up your SA's properly. For example, if you are using 10.* private addresses everywhere, then on the 'spoke' machines you set up an SA that looks like 10.0.1.0/24 -> 10.0.0.0/8 (if 10.0.1.0/24 is the address range assigned to this particular client). All other 10.* addresses will be routed down the tunnel. Or, you can always set up multiple SAs. e.g. at the 'other colo' side you could set up SAs for 10.0.1.0/24 -> 10.0.2.0/24 10.0.1.0/24 -> 10.0.3.0/24 both with a tunnel IP of the 'personal colo' server. Here, I'm assuming that 10.0.2.0/24 is the 'personal colo' space, and 10.0.3.0/24 is the 'home' space. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Optimizing a high-latency connection
On Fri, Aug 25, 2006 at 03:46:22PM +0200, Morgan wrote: > I'm trying som file transfers across the globe. The RTT is almost 400ms and > the transfer rate is painfully slow. There are 24 router hops on the path > and I assume most of the problem is there The number of routers isn't an issue, as long as they forward packets without dropping them on the floor. > but I wonder if there are any > sysctl variables I can trim on my side to help this problem slightly? I seem > to understand that there need to be an ACK received for at least every other > packet No, the two sides negotiate a 'window' which is the amount of outstanding unacknowledged traffic in transit. tcpdump will show you the negotiated window size. As long as the window is greater than the (bandwidth * RTT) product, you should be able to fill the pipe. e.g. a 2Mbps pipe (256KBps) with 400ms RTT has a delay-bandwidth product of 0.4*256 = 102.4KB You need to define "painfully slow", but my guess is that your problems are due to packet loss. Each lost packet causes the window size to be reduced by half, and it will only gradually creep back up. This is part of TCP's congestion control mechanism, since TCP equates packet loss with congestion, indicating that the transmission speed must be reduced. You can check your packet loss like this: # ping -s1472 -c100 x.x.x.x where x.x.x.x is the remote endpoint. (This sends 1500-byte sized packets: 20 bytes IP header + 8 bytes ICMP header + 1472 bytes data padding). TCP performs extremely poorly at packet loss of around 2% and above. If you see a large level of packet loss, by changing x.x.x.x to point to intermediate routers shown by traceroute, you may be able to identify where the packet loss is taking place. An ethernet full-duplex/half-duplex mismatch can cause packet loss in the 2% range, which is not enough for the network to be visibly "broken", but enough for it to perform very badly. Worst offenders here are old Cisco Catalyst 29xx switches, which don't perform auto-negotation properly. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nVidia chipset - ethernet support?
I have installed FreeBSD-5.2.1 on my brand new Soltek EQ3702A machine, which has an nVidia chipset. I have got most of the on-board hardware to work: kldload snd_ich -- pcm kldload firewire \ to mount my ipod kldload sbp / but I don't seem to be able to get ethernet to work. A google shows that this is a long-standing issue: http://lists.freebsd.org/pipermail/freebsd-questions/2003-August/016739.html http://lists.freebsd.org/pipermail/freebsd-net/2003-July/001016.html but I don't see anything else posted since August last year. I did come across this driver against FreeBSD-5.1: http://www.onthenet.com.au/~q/nvnet/ [1] Anyone have any experience with it? It claims to be in the official ports tree under net/nvnet, but I don't find it there (not in the 5.2.1-RELEASE ports tree anyway). Well actually, I did find something here: http://www.freebsd.org/cgi/pds.cgi?ports/net/nvnet [2] Unfortunately the driver page [1] doesn't link to the Linux driver it requires, and the port at [2] links to a different version of nvnet than the one at [1]. If anyone has this working with FreeBSD-5.2.1 (and either an up-to-date port, or a pointer to the correct Linux module required), that would save me some random hacking. Incidentally, my machine has two VGA ports. If anyone knows how to get both of those working together with XFree86, that would be appreciated too! Cheers, Brian. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
