From owner-freebsd-net@FreeBSD.ORG Sun Oct 26 01:04:18 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7CDEB16A4B3 for ; Sun, 26 Oct 2003 01:04:18 -0700 (PDT) Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1924643FBF for ; Sun, 26 Oct 2003 01:04:17 -0700 (PDT) (envelope-from babolo@cicuta.babolo.ru) Received: (qmail 33276 invoked from network); 26 Oct 2003 08:20:20 -0000 Received: from softdnserror (HELO cicuta.babolo.ru) (194.58.226.160) by softdnserror with SMTP; 26 Oct 2003 08:20:20 -0000 Received: (nullmailer pid 17160 invoked by uid 136); Sun, 26 Oct 2003 05:07:36 -0000 X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1 In-Reply-To: <3F9AC937.4070200@yuckfou.org> To: Nils Vogels Date: Sun, 26 Oct 2003 08:07:36 +0300 (MSK) From: "."@babolo.ru X-Mailer: ELM [version 2.4ME+ PL99b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <1067144856.121773.17159.nullmailer@cicuta.babolo.ru> cc: freebsd-net@freebsd.org Subject: Re: Reverse IP NAT to secondary IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 08:04:18 -0000 >>configure port with SNMP-server as 192.168.0.17/30 for example >>instead 192.168.2.1/24, and >>sysctl net.link.ether.inet.proxyall=1 >> >>and configure SNMP-server as 192.168.0.18/24 >> >>If you can change mask of SNMP-server, you can >>use 192.168.0/24 and 192.168.1/24 on gateway >>and 192.168.0/25 on SNMP-server. >> >> >Since I have the internet on the same interface, but on the primary IP >instead, would enabling ARP PROXY not fill the ARP table with every host >on the internet, that tries to contact the gateway ? Are you using default route? If yes, only default router's MAC used for every external IP. >>No NAT is needed. >> >I just tried this, but unfortunately, the same thing happens as with >ipfilter: > >The primary address of the interface ed0 on the gateway (the public >adress) is used to forward the arp request. > >Taken from a dump on the gateay, when attempting telnet: > >Incoming on rl0: >03:35:05.867883 192.168.0.2.1511 > 192.168.2.2.23: S >1377718084:1377718084(0) win 57344 (DF) [tos 0x10] > >Outgoing on ed0: >03:35:05.868333 195.0.0.1.15009 > 192.168.2.2.23: S >1377718084:1377718084(0) win 57344 (DF) [tos 0x10] No NAT is needed. Just allow 192.168.0.2 <-> 192.168.2.2 flow directly, not via NAT >Since 195.0.0.1 (obviously obfuscated) does not fall within the subnet >the 192.168.2.2 box is on, there will never be a reply from the >192.168.2.2 box. If you delete NAT on 192.168.0.2 <-> 192.168.2.2 path and wide mask on SNMP server, there will be reply. Or renumber subnet with SNMP server in such a way, that it be a subnet of net with WWW server. See my previous post with example. For ARP lookup you can try swap primary IP and alias (warning!) or use staric arp for SNMP server. >ARP proxying goes fine, on the WWW box, I can see the proxied reply >coming from my gateway for the 192.168.1.1 address ..... > >Can anyone tell me, how I can make the box use the secondary address >(alias) automatically for forwarding the telnet session? >Could it be that since the gateway is running many-to-one NAT as well, >this is conflicting ? you can fire up a lot of natd (this is one of my routers: 0sw~(2)>ps -axww | grep natd 44888 ?? Ss 31:11,88 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.100.pid -a IP0 -i 100 -o 101 -d 44890 ?? Ss 24:21,38 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.102.pid -a IP1 -i 102 -o 103 -d 44892 ?? Ss 36:25,68 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.104.pid -a IP2 -i 104 -o 105 -d 44894 ?? Ss 50:31,52 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.106.pid -a IP3 -i 106 -o 107 -d 44896 ?? Ss 26:42,38 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.108.pid -a IP4 -i 108 -o 109 -d 44898 ?? Ss 18:08,56 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.110.pid -a IP5 -i 110 -o 111 -d 44900 ?? Ss 27:32,76 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.112.pid -a IP6 -i 112 -o 113 -d 44902 ?? Ss 71:10,05 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.114.pid -a IP7 -i 114 -o 115 -d 44904 ?? Is 0:46,65 /sbin/natd -f /var/net/conf/nat.base -P /var/run/natd.98.pid -a IP8 -i 98 -o 99 -d where real IPs substituted by IPx. You are free to use IPs from some of interfaces or IPs which none interface has, You can use the same IP for different natd or not - just write the appropriate rules in ipfw. For example use one natd for proxing one port with selected paig of addresses. But again: there is not need for NAT in circumstances you wrote in first letter. Sorry my English is bad. From owner-freebsd-net@FreeBSD.ORG Sun Oct 26 05:02:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE31F16A4B3 for ; Sun, 26 Oct 2003 05:02:01 -0800 (PST) Received: from imhotep.yuckfou.org (cust.89.117.adsl.cistron.nl [195.64.89.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D80E43FDD for ; Sun, 26 Oct 2003 05:01:59 -0800 (PST) (envelope-from nivo+sender+8eb026@yuckfou.org) Received: from localhost (localhost [127.0.0.1]) by imhotep.yuckfou.org (Postfix) with ESMTP id 28914C3 for ; Sun, 26 Oct 2003 14:01:54 +0100 (CET) Received: from imhotep.yuckfou.org ([127.0.0.1]) by localhost (imhotep.yuckfou.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65251-01 for ; Sun, 26 Oct 2003 14:01:53 +0100 (CET) Received: from localhost.yuckfou.org (localhost [IPv6:::1]) by imhotep.yuckfou.org (Postfix) with ESMTP id 9C42BB7 for ; Sun, 26 Oct 2003 14:01:53 +0100 (CET) Received: from yuckfou.org (turbata-xp [192.168.2.236]) by localhost.yuckfou.org (tmda-ofmipd) with ESMTP; Sun, 26 Oct 2003 14:01:49 +0100 (CET) Message-ID: <3F9BC5BD.2040804@yuckfou.org> Date: Sun, 26 Oct 2003 14:01:49 +0100 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030912 Thunderbird/0.3a X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-net@freebsd.org References: <1067144856.121773.17159.nullmailer@cicuta.babolo.ru> In-Reply-To: <1067144856.121773.17159.nullmailer@cicuta.babolo.ru> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit From: Nils Vogels X-Delivery-Agent: TMDA/0.86 (Venetian Way) X-TMDA-Fingerprint: 3NJWpdSaUd61OqtHZ4UFc+sWY94 X-Virus-Scanned: by amavisd-new at yuckfou.org Subject: Re: Reverse IP NAT to secondary IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nils Vogels List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2003 13:02:01 -0000 "."@babolo.ru wrote: >>Since I have the internet on the same interface, but on the primary IP >>instead, would enabling ARP PROXY not fill the ARP table with every host >>on the internet, that tries to contact the gateway ? >> >> >Are you using default route? >If yes, only default router's MAC used for every external IP. > > > OK, great. >>>No NAT is needed. >>> >>> >>> >>I just tried this, but unfortunately, the same thing happens as with >>ipfilter: >> >>The primary address of the interface ed0 on the gateway (the public >>adress) is used to forward the arp request. >> >>Taken from a dump on the gateay, when attempting telnet: >> >>Incoming on rl0: >>03:35:05.867883 192.168.0.2.1511 > 192.168.2.2.23: S >>1377718084:1377718084(0) win 57344 (DF) [tos 0x10] >> >>Outgoing on ed0: >>03:35:05.868333 195.0.0.1.15009 > 192.168.2.2.23: S >>1377718084:1377718084(0) win 57344 (DF) [tos 0x10] >> >> >No NAT is needed. >Just allow 192.168.0.2 <-> 192.168.2.2 flow directly, >not via NAT > > I just changed my ipnat rule to: map ed0 from 192.168.0.0/24 ! to 192.168.0.0/16 -> 0/32 map ed0 from 192.168.0.0/24 ! to 192.168.0.0/16 -> 0/32 portmap tcp/udp 15000:19999 And this is now working. Thanks a bunch! ;-) From owner-freebsd-net@FreeBSD.ORG Sun Oct 26 22:24:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 104EE16A4B3 for ; Sun, 26 Oct 2003 22:24:36 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BBB143FA3 for ; Sun, 26 Oct 2003 22:24:34 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id RAA896657 for ; Mon, 27 Oct 2003 17:24:32 +1100 (EST) From: paul van den bergen To: freebsd-net@freebsd.org Date: Mon, 27 Oct 2003 17:24:32 +1100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310271724.32346.pvandenbergen@swin.edu.au> Subject: configuring routing for ipv6 - simple case. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 06:24:36 -0000 Hi all, I feel like a dufus for asking because this should be simple, but I'm stuck at the point where I cannot see what I am doing... attempting to set up an IPv6 mobile IP test bed. currently I am using site local addresses, specifically fec0:0:0:229::, fec0:0:0:10:: and fec0:0:0:172:: for each of the three networks I wish to set up. I do not want global connectivity as such (yet). these are running over an existing (single) ipv4 network, so I only wish to configure IPv6 routing, etc., with no IPv4to6 or 6to4 translation. I have 4 PCs to configure. Three are on the 229 network, one is a standalone node, the other two should be gateways to the 172 and 10 networks respecitvely. AFAICS, this should be a fairly simple set up... so, with nothing more than this, can someone please outline how to set up IPv6 routing in this situation? I believe I should not need to use route6d or similar just to do this static routing? to make matters somewhat complicated, I am running the KAME snap for MIP6 connectivity, which afaict requires rtadvd. does this mean that I need to set net.inet6.ip6.accept_rtadv=1 ??? since I have net.inet6.ip6.forwarding=1 because I am using wifi cards on the 10 and 172 networks as APs in hostap mode, is this going to cause a problem? I did see a table of net.inet6.ip6.forwarding and net.inet6.ip6.accept_rtadv settings last week (and do you think I can find it again this week?) that suggested that having both to 1 is either invalid or experimental... -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 00:16:19 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC44D16A4B3 for ; Mon, 27 Oct 2003 00:16:19 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9D4E743FBD for ; Mon, 27 Oct 2003 00:16:16 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 919 invoked from network); 27 Oct 2003 08:16:15 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 27 Oct 2003 08:16:15 -0000 X-pair-Authenticated: 209.68.2.70 Date: Mon, 27 Oct 2003 02:16:13 -0600 (CST) From: Mike Silbersack To: freebsd-net@freebsd.org Message-ID: <20031027014854.K2023@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1743396347-1067242013=:2023" Content-ID: <20031027020712.K2023@odysseus.silby.com> cc: iedowse@freebsd.org Subject: Changes to PCBPORTHASH wrt TCP, review needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 08:16:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1743396347-1067242013=:2023 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20031027020712.N2023@odysseus.silby.com> The attached patch is rather short, but makes a substantial change in how ports are bound, so I'd like a quick review of the code and the concept if possible. In short, what this patch does is remove established TCP connections from the PCBPORTHASH table, thereby allowing their ephemeral ports to be concurrently used by other tcp connections to other hosts/ports. To do this, I made the following changes: - in_pcbinshash was modified so that the "porthash" parameter determines whether or not the inp in question is added to the pcbporthash. - in_pcbrehash was modified so that the "remove" parameter determines whether the inp in question will be removed from the pcbportlist when it is rehashed in the pcbhash - in_pcbremlists was modified to account for pcbs not necessarily being in both hashes - syncache_socket uses the porthash parameter to ensure that incoming tcp connections are never added to the pcbporthash. - tcp_connect and tcp6_connect use ins_rehash to remove the inp in question from the pcbporthash list after the final ip/port has been determined. Note that the pcbhash is still consulted, so an attempt to create a tcp socket which conflicts with an already existing connection will be detected correctly. One easy way to test this patch is to install http_load, set your ephemeral port range to something in the range of 30, and have it start testing a host. It will quickly create TIME_WAIT sockets filling all ephemeral ports. Without this patch, you will be unable to create outgoing connections; with this patch, other outgoing connections will be fine. Note that since the port chosen is not released from the pcbporthash table until tcp_connect, repeated calls to bind can still reserve all ephemeral ports; I don't believe that is going to be a common case. So far, the only problem I can see is that in_pcbbind, being unaware of the state of pcbhash, may return ports which collide with in-use connections for the destination host while non-colliding ports are still available. I should be able to work around this potential issue with a simple retry loop, so it's not a big concern. Otherwise, can anyone see any problems that this change would cause? I believe that it would change behavior so that SO_REUSEADDR and SO_REUSEPORT would no longer be required for daemons which restart and attempt to listen on the same port, but I believe this to be a positive change. Ports used by tcp listen sockets and udp sockets should be protected as before, so that should be ok as well. Am I missing something subtle? Thanks, Mike "Silby" Silbersack --0-1743396347-1067242013=:2023 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="pcbporthash-change.patch" Content-Transfer-Encoding: BASE64 Content-ID: <20031027020653.V2023@odysseus.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME="pcbporthash-change.patch" ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQvaW5fcGNiLmMg L3Vzci9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmMNCi0tLSAvdXNyL3NyYy9z eXMub2xkL25ldGluZXQvaW5fcGNiLmMJRnJpIE9jdCAyNCAxMjowNTowMCAy MDAzDQorKysgL3Vzci9zcmMvc3lzL25ldGluZXQvaW5fcGNiLmMJU3VuIE9j dCAyNiAyMToxNDozNiAyMDAzDQpAQCAtMjEyLDcgKzIxMiw3IEBADQogCSAg ICAmaW5wLT5pbnBfbHBvcnQsIHRkKTsNCiAJaWYgKGVycm9yKQ0KIAkJcmV0 dXJuIChlcnJvcik7DQotCWlmIChpbl9wY2JpbnNoYXNoKGlucCkgIT0gMCkg ew0KKwlpZiAoaW5fcGNiaW5zaGFzaChpbnAsIDEpICE9IDApIHsNCiAJCWlu cC0+aW5wX2xhZGRyLnNfYWRkciA9IElOQUREUl9BTlk7DQogCQlpbnAtPmlu cF9scG9ydCA9IDA7DQogCQlyZXR1cm4gKEVBR0FJTik7DQpAQCAtNDYwLDcg KzQ2MCw3IEBADQogCWlmIChpbnAtPmlucF9sYWRkci5zX2FkZHIgPT0gSU5B RERSX0FOWSAmJiBpbnAtPmlucF9scG9ydCA9PSAwKSB7DQogCQlpbnAtPmlu cF9scG9ydCA9IGxwb3J0Ow0KIAkJaW5wLT5pbnBfbGFkZHIuc19hZGRyID0g bGFkZHI7DQotCQlpZiAoaW5fcGNiaW5zaGFzaChpbnApICE9IDApIHsNCisJ CWlmIChpbl9wY2JpbnNoYXNoKGlucCwgMSkgIT0gMCkgew0KIAkJCWlucC0+ aW5wX2xhZGRyLnNfYWRkciA9IElOQUREUl9BTlk7DQogCQkJaW5wLT5pbnBf bHBvcnQgPSAwOw0KIAkJCXJldHVybiAoRUFHQUlOKTsNCkBAIC00NzIsNyAr NDcyLDcgQEANCiAJaW5wLT5pbnBfbGFkZHIuc19hZGRyID0gbGFkZHI7DQog CWlucC0+aW5wX2ZhZGRyLnNfYWRkciA9IGZhZGRyOw0KIAlpbnAtPmlucF9m cG9ydCA9IGZwb3J0Ow0KLQlpbl9wY2JyZWhhc2goaW5wKTsNCisJaW5fcGNi cmVoYXNoKGlucCwgMCk7DQogCWlmIChhbm9ucG9ydCkNCiAJCWlucC0+aW5w X2ZsYWdzIHw9IElOUF9BTk9OUE9SVDsNCiAJcmV0dXJuICgwKTsNCkBAIC02 NTIsNyArNjUyLDcgQEANCiANCiAJaW5wLT5pbnBfZmFkZHIuc19hZGRyID0g SU5BRERSX0FOWTsNCiAJaW5wLT5pbnBfZnBvcnQgPSAwOw0KLQlpbl9wY2Jy ZWhhc2goaW5wKTsNCisJaW5fcGNicmVoYXNoKGlucCwgMCk7DQogCWlmIChp bnAtPmlucF9zb2NrZXQtPnNvX3N0YXRlICYgU1NfTk9GRFJFRikNCiAJCWlu X3BjYmRldGFjaChpbnApOw0KIH0NCkBAIC0xMDc1LDggKzEwNzUsOSBAQA0K ICAqIEluc2VydCBQQ0Igb250byB2YXJpb3VzIGhhc2ggbGlzdHMuDQogICov DQogaW50DQotaW5fcGNiaW5zaGFzaChpbnApDQoraW5fcGNiaW5zaGFzaChp bnAsIHBvcnRoYXNoKQ0KIAlzdHJ1Y3QgaW5wY2IgKmlucDsNCisJaW50IHBv cnRoYXNoOw0KIHsNCiAJc3RydWN0IGlucGNiaGVhZCAqcGNiaGFzaDsNCiAJ c3RydWN0IGlucGNicG9ydGhlYWQgKnBjYnBvcnRoYXNoOw0KQEAgLTEwOTQs MzAgKzEwOTUsMzQgQEANCiAJcGNiaGFzaCA9ICZwY2JpbmZvLT5oYXNoYmFz ZVtJTlBfUENCSEFTSChoYXNoa2V5X2ZhZGRyLA0KIAkJIGlucC0+aW5wX2xw b3J0LCBpbnAtPmlucF9mcG9ydCwgcGNiaW5mby0+aGFzaG1hc2spXTsNCiAN Ci0JcGNicG9ydGhhc2ggPSAmcGNiaW5mby0+cG9ydGhhc2hiYXNlW0lOUF9Q Q0JQT1JUSEFTSChpbnAtPmlucF9scG9ydCwNCi0JICAgIHBjYmluZm8tPnBv cnRoYXNobWFzayldOw0KKwlpZiAocG9ydGhhc2gpIHsNCisJCXBjYnBvcnRo YXNoID0gJnBjYmluZm8tPnBvcnRoYXNoYmFzZVtJTlBfUENCUE9SVEhBU0go aW5wLT5pbnBfbHBvcnQsDQorCQkgICAgcGNiaW5mby0+cG9ydGhhc2htYXNr KV07DQogDQotCS8qDQotCSAqIEdvIHRocm91Z2ggcG9ydCBsaXN0IGFuZCBs b29rIGZvciBhIGhlYWQgZm9yIHRoaXMgbHBvcnQuDQotCSAqLw0KLQlMSVNU X0ZPUkVBQ0gocGhkLCBwY2Jwb3J0aGFzaCwgcGhkX2hhc2gpIHsNCi0JCWlm IChwaGQtPnBoZF9wb3J0ID09IGlucC0+aW5wX2xwb3J0KQ0KLQkJCWJyZWFr Ow0KLQl9DQotCS8qDQotCSAqIElmIG5vbmUgZXhpc3RzLCBtYWxsb2Mgb25l IGFuZCB0YWNrIGl0IG9uLg0KLQkgKi8NCi0JaWYgKHBoZCA9PSBOVUxMKSB7 DQotCQlNQUxMT0MocGhkLCBzdHJ1Y3QgaW5wY2Jwb3J0ICosIHNpemVvZihz dHJ1Y3QgaW5wY2Jwb3J0KSwgTV9QQ0IsIE1fTk9XQUlUKTsNCisJCS8qDQor CQkgKiBHbyB0aHJvdWdoIHBvcnQgbGlzdCBhbmQgbG9vayBmb3IgYSBoZWFk IGZvciB0aGlzIGxwb3J0Lg0KKwkJICovDQorCQlMSVNUX0ZPUkVBQ0gocGhk LCBwY2Jwb3J0aGFzaCwgcGhkX2hhc2gpIHsNCisJCQlpZiAocGhkLT5waGRf cG9ydCA9PSBpbnAtPmlucF9scG9ydCkNCisJCQkJYnJlYWs7DQorCQl9DQor CQkvKg0KKwkJICogSWYgbm9uZSBleGlzdHMsIG1hbGxvYyBvbmUgYW5kIHRh Y2sgaXQgb24uDQorCQkgKi8NCiAJCWlmIChwaGQgPT0gTlVMTCkgew0KLQkJ CXJldHVybiAoRU5PQlVGUyk7IC8qIFhYWCAqLw0KKwkJCU1BTExPQyhwaGQs IHN0cnVjdCBpbnBjYnBvcnQgKiwgc2l6ZW9mKHN0cnVjdCBpbnBjYnBvcnQp LCBNX1BDQiwgTV9OT1dBSVQpOw0KKwkJCWlmIChwaGQgPT0gTlVMTCkgew0K KwkJCQlyZXR1cm4gKEVOT0JVRlMpOyAvKiBYWFggKi8NCisJCQl9DQorCQkJ cGhkLT5waGRfcG9ydCA9IGlucC0+aW5wX2xwb3J0Ow0KKwkJCUxJU1RfSU5J VCgmcGhkLT5waGRfcGNibGlzdCk7DQorCQkJTElTVF9JTlNFUlRfSEVBRChw Y2Jwb3J0aGFzaCwgcGhkLCBwaGRfaGFzaCk7DQogCQl9DQotCQlwaGQtPnBo ZF9wb3J0ID0gaW5wLT5pbnBfbHBvcnQ7DQotCQlMSVNUX0lOSVQoJnBoZC0+ cGhkX3BjYmxpc3QpOw0KLQkJTElTVF9JTlNFUlRfSEVBRChwY2Jwb3J0aGFz aCwgcGhkLCBwaGRfaGFzaCk7DQorCQlpbnAtPmlucF9waGQgPSBwaGQ7DQor CQlMSVNUX0lOU0VSVF9IRUFEKCZwaGQtPnBoZF9wY2JsaXN0LCBpbnAsIGlu cF9wb3J0bGlzdCk7DQorCX0gZWxzZSB7DQorCQlpbnAtPmlucF9waGQgPSBO VUxMOw0KIAl9DQotCWlucC0+aW5wX3BoZCA9IHBoZDsNCi0JTElTVF9JTlNF UlRfSEVBRCgmcGhkLT5waGRfcGNibGlzdCwgaW5wLCBpbnBfcG9ydGxpc3Qp Ow0KIAlMSVNUX0lOU0VSVF9IRUFEKHBjYmhhc2gsIGlucCwgaW5wX2hhc2gp Ow0KIAlyZXR1cm4gKDApOw0KIH0NCkBAIC0xMTI5LDExICsxMTM0LDEzIEBA DQogICogbm90IGNoYW5nZSBhZnRlciBpbl9wY2JpbnNoYXNoKCkgaGFzIGJl ZW4gY2FsbGVkLg0KICAqLw0KIHZvaWQNCi1pbl9wY2JyZWhhc2goaW5wKQ0K K2luX3BjYnJlaGFzaChpbnAsIHJlbW92ZSkNCiAJc3RydWN0IGlucGNiICpp bnA7DQorCWludCByZW1vdmU7DQogew0KIAlzdHJ1Y3QgaW5wY2JoZWFkICpo ZWFkOw0KIAl1X2ludDMyX3QgaGFzaGtleV9mYWRkcjsNCisJc3RydWN0IGlu cGNicG9ydCAqcGhkID0gaW5wLT5pbnBfcGhkOw0KIA0KICNpZmRlZiBJTkVU Ng0KIAlpZiAoaW5wLT5pbnBfdmZsYWcgJiBJTlBfSVBWNikNCkBAIC0xMTQ3 LDYgKzExNTQsMTUgQEANCiANCiAJTElTVF9SRU1PVkUoaW5wLCBpbnBfaGFz aCk7DQogCUxJU1RfSU5TRVJUX0hFQUQoaGVhZCwgaW5wLCBpbnBfaGFzaCk7 DQorDQorCWlmIChyZW1vdmUgJiYgcGhkKSB7DQorCQlMSVNUX1JFTU9WRShp bnAsIGlucF9wb3J0bGlzdCk7DQorCQlpZiAoTElTVF9GSVJTVCgmcGhkLT5w aGRfcGNibGlzdCkgPT0gTlVMTCkgew0KKwkJCUxJU1RfUkVNT1ZFKHBoZCwg cGhkX2hhc2gpOw0KKwkJCWZyZWUocGhkLCBNX1BDQik7DQorCQl9DQorCQlp bnAtPmlucF9waGQgPSBOVUxMOw0KKwl9DQogfQ0KIA0KIC8qDQpAQCAtMTE2 MSwxMCArMTE3NywxMiBAQA0KIAkJc3RydWN0IGlucGNicG9ydCAqcGhkID0g aW5wLT5pbnBfcGhkOw0KIA0KIAkJTElTVF9SRU1PVkUoaW5wLCBpbnBfaGFz aCk7DQotCQlMSVNUX1JFTU9WRShpbnAsIGlucF9wb3J0bGlzdCk7DQotCQlp ZiAoTElTVF9GSVJTVCgmcGhkLT5waGRfcGNibGlzdCkgPT0gTlVMTCkgew0K LQkJCUxJU1RfUkVNT1ZFKHBoZCwgcGhkX2hhc2gpOw0KLQkJCWZyZWUocGhk LCBNX1BDQik7DQorCQlpZiAocGhkKSB7DQorCQkJTElTVF9SRU1PVkUoaW5w LCBpbnBfcG9ydGxpc3QpOw0KKwkJCWlmIChMSVNUX0ZJUlNUKCZwaGQtPnBo ZF9wY2JsaXN0KSA9PSBOVUxMKSB7DQorCQkJCUxJU1RfUkVNT1ZFKHBoZCwg cGhkX2hhc2gpOw0KKwkJCQlmcmVlKHBoZCwgTV9QQ0IpOw0KKwkJCX0NCiAJ CX0NCiAJfQ0KIAlMSVNUX1JFTU9WRShpbnAsIGlucF9saXN0KTsNCmRpZmYg LXUgLXIgL3Vzci9zcmMvc3lzLm9sZC9uZXRpbmV0L2luX3BjYi5oIC91c3Iv c3JjL3N5cy9uZXRpbmV0L2luX3BjYi5oDQotLS0gL3Vzci9zcmMvc3lzLm9s ZC9uZXRpbmV0L2luX3BjYi5oCUZyaSBPY3QgMjQgMTI6MDU6MDAgMjAwMw0K KysrIC91c3Ivc3JjL3N5cy9uZXRpbmV0L2luX3BjYi5oCVN1biBPY3QgMjYg MjE6MDM6MTUgMjAwMw0KQEAgLTM0MCw3ICszNDAsNyBAQA0KIAkgICAgc3Ry dWN0IHRocmVhZCAqKTsNCiB2b2lkCWluX3BjYmRldGFjaChzdHJ1Y3QgaW5w Y2IgKik7DQogdm9pZAlpbl9wY2JkaXNjb25uZWN0KHN0cnVjdCBpbnBjYiAq KTsNCi1pbnQJaW5fcGNiaW5zaGFzaChzdHJ1Y3QgaW5wY2IgKik7DQoraW50 CWluX3BjYmluc2hhc2goc3RydWN0IGlucGNiICosIGludCk7DQogc3RydWN0 IGlucGNiICoNCiAJaW5fcGNibG9va3VwX2xvY2FsKHN0cnVjdCBpbnBjYmlu Zm8gKiwNCiAJICAgIHN0cnVjdCBpbl9hZGRyLCB1X2ludCwgaW50KTsNCkBA IC0zNDksNyArMzQ5LDcgQEANCiAJICAgIHN0cnVjdCBpbl9hZGRyLCB1X2lu dCwgaW50LCBzdHJ1Y3QgaWZuZXQgKik7DQogdm9pZAlpbl9wY2Jub3RpZnlh bGwoc3RydWN0IGlucGNiaW5mbyAqcGNiaW5mbywgc3RydWN0IGluX2FkZHIs DQogCSAgICBpbnQsIHN0cnVjdCBpbnBjYiAqKCopKHN0cnVjdCBpbnBjYiAq LCBpbnQpKTsNCi12b2lkCWluX3BjYnJlaGFzaChzdHJ1Y3QgaW5wY2IgKik7 DQordm9pZAlpbl9wY2JyZWhhc2goc3RydWN0IGlucGNiICosIGludCk7DQog aW50CWluX3NldHBlZXJhZGRyKHN0cnVjdCBzb2NrZXQgKnNvLCBzdHJ1Y3Qg c29ja2FkZHIgKipuYW0sIHN0cnVjdCBpbnBjYmluZm8gKnBjYmluZm8pOw0K IGludAlpbl9zZXRzb2NrYWRkcihzdHJ1Y3Qgc29ja2V0ICpzbywgc3RydWN0 IHNvY2thZGRyICoqbmFtLCBzdHJ1Y3QgaW5wY2JpbmZvICpwY2JpbmZvKTs7 DQogc3RydWN0IHNvY2thZGRyICoNCmRpZmYgLXUgLXIgL3Vzci9zcmMvc3lz Lm9sZC9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jIC91c3Ivc3JjL3N5cy9uZXRp bmV0L3RjcF9zeW5jYWNoZS5jDQotLS0gL3Vzci9zcmMvc3lzLm9sZC9uZXRp bmV0L3RjcF9zeW5jYWNoZS5jCUZyaSBPY3QgMjQgMTI6MDU6MDAgMjAwMw0K KysrIC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jCVN1biBP Y3QgMjYgMDI6MjY6NDEgMjAwMw0KQEAgLTYwNSw3ICs2MDUsNyBAQA0KIAl9 DQogI2VuZGlmDQogCWlucC0+aW5wX2xwb3J0ID0gc2MtPnNjX2luYy5pbmNf bHBvcnQ7DQotCWlmIChpbl9wY2JpbnNoYXNoKGlucCkgIT0gMCkgew0KKwlp ZiAoaW5fcGNiaW5zaGFzaChpbnAsIDApICE9IDApIHsNCiAJCS8qDQogCQkg KiBVbmRvIHRoZSBhc3NpZ25tZW50cyBhYm92ZSBpZiB3ZSBmYWlsZWQgdG8N CiAJCSAqIHB1dCB0aGUgUENCIG9uIHRoZSBoYXNoIGxpc3RzLg0KZGlmZiAt dSAtciAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQvdGNwX3VzcnJlcS5jIC91 c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF91c3JyZXEuYw0KLS0tIC91c3Ivc3Jj L3N5cy5vbGQvbmV0aW5ldC90Y3BfdXNycmVxLmMJRnJpIE9jdCAyNCAxMjow NTowMCAyMDAzDQorKysgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3VzcnJl cS5jCU1vbiBPY3QgMjcgMDE6NDM6NTAgMjAwMw0KQEAgLTg4Myw3ICs4ODMs NyBAQA0KIAkJCXJldHVybiBFQUREUklOVVNFOw0KIAl9DQogCWlucC0+aW5w X2xhZGRyID0gbGFkZHI7DQotCWluX3BjYnJlaGFzaChpbnApOw0KKwlpbl9w Y2JyZWhhc2goaW5wLCAxKTsNCiANCiAJLyogQ29tcHV0ZSB3aW5kb3cgc2Nh bGluZyB0byByZXF1ZXN0LiAgKi8NCiAJd2hpbGUgKHRwLT5yZXF1ZXN0X3Jf c2NhbGUgPCBUQ1BfTUFYX1dJTlNISUZUICYmDQpAQCAtOTcyLDcgKzk3Miw3 IEBADQogCWlucC0+aW5wX2Zwb3J0ID0gc2luNi0+c2luNl9wb3J0Ow0KIAlp ZiAoKHNpbjYtPnNpbjZfZmxvd2luZm8gJiBJUFY2X0ZMT1dJTkZPX01BU0sp ICE9IDApDQogCQlpbnAtPmluNnBfZmxvd2luZm8gPSBzaW42LT5zaW42X2Zs b3dpbmZvOw0KLQlpbl9wY2JyZWhhc2goaW5wKTsNCisJaW5fcGNicmVoYXNo KGlucCwgMSk7DQogDQogCS8qIENvbXB1dGUgd2luZG93IHNjYWxpbmcgdG8g cmVxdWVzdC4gICovDQogCXdoaWxlICh0cC0+cmVxdWVzdF9yX3NjYWxlIDwg VENQX01BWF9XSU5TSElGVCAmJg0KZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMu b2xkL25ldGluZXQvdWRwX3VzcnJlcS5jIC91c3Ivc3JjL3N5cy9uZXRpbmV0 L3VkcF91c3JyZXEuYw0KLS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldC91 ZHBfdXNycmVxLmMJRnJpIE9jdCAyNCAxMjowNTowMCAyMDAzDQorKysgL3Vz ci9zcmMvc3lzL25ldGluZXQvdWRwX3VzcnJlcS5jCVN1biBPY3QgMjYgMDI6 MTg6NDEgMjAwMw0KQEAgLTc4NCw3ICs3ODQsNyBAQA0KIAkJaWYgKGlucC0+ aW5wX2xhZGRyLnNfYWRkciA9PSBJTkFERFJfQU5ZICYmDQogCQkgICAgaW5w LT5pbnBfbHBvcnQgPT0gMCkgew0KIAkJCWlucC0+aW5wX2xwb3J0ID0gbHBv cnQ7DQotCQkJaWYgKGluX3BjYmluc2hhc2goaW5wKSAhPSAwKSB7DQorCQkJ aWYgKGluX3BjYmluc2hhc2goaW5wLCAxKSAhPSAwKSB7DQogCQkJCWlucC0+ aW5wX2xwb3J0ID0gMDsNCiAJCQkJZXJyb3IgPSBFQUdBSU47DQogCQkJCWdv dG8gcmVsZWFzZTsNCmRpZmYgLXUgLXIgL3Vzci9zcmMvc3lzLm9sZC9uZXRp bmV0Ni9pbjZfcGNiLmMgL3Vzci9zcmMvc3lzL25ldGluZXQ2L2luNl9wY2Iu Yw0KLS0tIC91c3Ivc3JjL3N5cy5vbGQvbmV0aW5ldDYvaW42X3BjYi5jCUZy aSBPY3QgMjQgMTI6MDQ6NTggMjAwMw0KKysrIC91c3Ivc3JjL3N5cy9uZXRp bmV0Ni9pbjZfcGNiLmMJU3VuIE9jdCAyNiAyMTowNDo1NiAyMDAzDQpAQCAt MjgwLDcgKzI4MCw3IEBADQogCX0NCiAJZWxzZSB7DQogCQlpbnAtPmlucF9s cG9ydCA9IGxwb3J0Ow0KLQkJaWYgKGluX3BjYmluc2hhc2goaW5wKSAhPSAw KSB7DQorCQlpZiAoaW5fcGNiaW5zaGFzaChpbnAsIDEpICE9IDApIHsNCiAJ CQlpbnAtPmluNnBfbGFkZHIgPSBpbjZhZGRyX2FueTsNCiAJCQlpbnAtPmlu cF9scG9ydCA9IDA7DQogCQkJcmV0dXJuIChFQUdBSU4pOw0KQEAgLTQwOSw3 ICs0MDksNyBAQA0KIAkJICAgIChodG9ubChpcDZfZmxvd19zZXErKykgJiBJ UFY2X0ZMT1dMQUJFTF9NQVNLKTsNCiAjZW5kaWYNCiANCi0JaW5fcGNicmVo YXNoKGlucCk7DQorCWluX3BjYnJlaGFzaChpbnAsIDApOw0KIAlyZXR1cm4g KDApOw0KIH0NCiANCkBAIC00MjEsNyArNDIxLDcgQEANCiAJaW5wLT5pbnBf ZnBvcnQgPSAwOw0KIAkvKiBjbGVhciBmbG93aW5mbyAtIGRyYWZ0LWl0b2p1 bi1pcHY2LWZsb3dsYWJlbC1hcGktMDAgKi8NCiAJaW5wLT5pbjZwX2Zsb3dp bmZvICY9IH5JUFY2X0ZMT1dMQUJFTF9NQVNLOw0KLQlpbl9wY2JyZWhhc2go aW5wKTsNCisJaW5fcGNicmVoYXNoKGlucCwgMCk7DQogCWlmIChpbnAtPmlu cF9zb2NrZXQtPnNvX3N0YXRlICYgU1NfTk9GRFJFRikNCiAJCWluNl9wY2Jk ZXRhY2goaW5wKTsNCiB9DQpkaWZmIC11IC1yIC91c3Ivc3JjL3N5cy5vbGQv bmV0aW5ldDYvaW42X3NyYy5jIC91c3Ivc3JjL3N5cy9uZXRpbmV0Ni9pbjZf c3JjLmMNCi0tLSAvdXNyL3NyYy9zeXMub2xkL25ldGluZXQ2L2luNl9zcmMu YwlGcmkgT2N0IDI0IDEyOjA0OjU5IDIwMDMNCisrKyAvdXNyL3NyYy9zeXMv bmV0aW5ldDYvaW42X3NyYy5jCVN1biBPY3QgMjYgMDI6MjA6MTMgMjAwMw0K QEAgLTM5NCw3ICszOTQsNyBAQA0KIAl9DQogDQogCWlucC0+aW5wX2xwb3J0 ID0gbHBvcnQ7DQotCWlmIChpbl9wY2JpbnNoYXNoKGlucCkgIT0gMCkgew0K KwlpZiAoaW5fcGNiaW5zaGFzaChpbnAsIDEpICE9IDApIHsNCiAJCWlucC0+ aW42cF9sYWRkciA9IGluNmFkZHJfYW55Ow0KIAkJaW5wLT5pbnBfbHBvcnQg PSAwOw0KIAkJcmV0dXJuIChFQUdBSU4pOw0K --0-1743396347-1067242013=:2023-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 27 11:01:48 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E457F16A4B3 for ; Mon, 27 Oct 2003 11:01:48 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6261443FFB for ; Mon, 27 Oct 2003 11:01:38 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h9RJ1cFY056659 for ; Mon, 27 Oct 2003 11:01:38 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h9RJ1bAS056654 for freebsd-net@freebsd.org; Mon, 27 Oct 2003 11:01:37 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 27 Oct 2003 11:01:37 -0800 (PST) Message-Id: <200310271901.h9RJ1bAS056654@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2003 19:01:49 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/05/04] kern/37761 net process exits but socket is still ESTABLI 1 problem total. From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 03:40:34 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1475916A4CE for ; Tue, 28 Oct 2003 03:40:34 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C07E843F75 for ; Tue, 28 Oct 2003 03:40:32 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id 7C12C6CF3F; Tue, 28 Oct 2003 12:40:31 +0100 (CET) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 79F9F5A899; Tue, 28 Oct 2003 12:40:04 +0100 (CET) To: Michael Sierchio From: Eric Masson In-Reply-To: <3F9950F6.6000208@tenebras.com> (Michael Sierchio's message of "Fri, 24 Oct 2003 09:19:02 -0700") References: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> <3F9950F6.6000208@tenebras.com> X-Operating-System: FreeBSD 4.9-PRERELEASE i386 Date: Tue, 28 Oct 2003 12:40:04 +0100 Message-ID: <86n0bllhez.fsf@t39bsdems.interne.kisoft-services.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Mailing List FreeBSD Network Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 11:40:34 -0000 >>>>> "Michael" == Michael Sierchio writes: Michael> You should allow for an IP header with options and the ESP Michael> header, which is smaller than 1450. For SKIP I use 1366 as the Michael> advertised MTU, and for IPsec usually 1436, unless I need to Michael> accomodate ESP and AH, in which case it's smaller. Ok, that's fine. Michael> It's a known feature of any sort of IP encapsulation. I understand. I'm no kernel hacker at all, I was just thinking about the ability for the tunnel endpoint to send back an icmp packet type 3 code 4 when the packet is too long to be encapsulated. Is this plain dumb or does it present any interest ? Regards Eric Masson -- comment fait on pour craker un logiciel car j'ai le logiciel et le crack, et quand je lance le crack ca m'ouvre une session dos et c'est tous, y'a t'il quelque chose à écrire dans cette session sous dos ? -+- FV in : Guide du Neuneu Usenet : Aidez-moi ou je cracke -+- From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 05:15:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 315AA16A4CE; Tue, 28 Oct 2003 05:15:00 -0800 (PST) Received: from cheer.mahoroba.org (flets19-227.kamome.or.jp [218.45.19.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A6A743FE0; Tue, 28 Oct 2003 05:14:56 -0800 (PST) (envelope-from ume@mahoroba.org) Received: from mille.mahoroba.org (IDENT:2DsfpExvzajADC+7WO+s7MEpc9vDUSEiMXHEiEsE1eNJ8LzW0t3ryGTbe/XMr4GH@mille.mahoroba.org [IPv6:3ffe:501:185b:8010:202:2dff:fe41:8630]) (user=ume mech=CRAM-MD5 bits=0)h9SDEkJR063790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Oct 2003 22:14:46 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 28 Oct 2003 22:14:46 +0900 Message-ID: From: Hajimu UMEMOTO To: current@FreeBSD.org, net@FreeBSD.org, arch@FreeBSD.org References: <20031028063802.GC10818@canolog.ninthwonder.com> User-Agent: Wanderlust/2.11.0 (Wonderwall) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) X-Operating-System: FreeBSD 4.8-RELEASE-p13 MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: multipart/mixed; boundary="Multipart_Tue_Oct_28_22:14:46_2003-1" X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org Subject: Forward: HEADS UP! Default value of ip6_v6only changed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 13:15:00 -0000 --Multipart_Tue_Oct_28_22:14:46_2003-1 Content-Type: text/plain; charset=US-ASCII Hi, Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks RFC2553/3493, and the change was intentional from security consideration. But, NetBSD changed it off by default. How do you think our default of on? --Multipart_Tue_Oct_28_22:14:46_2003-1 Content-Type: message/rfc822 X-Sieve: CMU Sieve 2.2 Delivered-To: tech-net@netbsd.org Date: Tue, 28 Oct 2003 01:38:02 -0500 From: NetBSD OS PMC To: tech-net@netbsd.org, current-users@netbsd.org Subject: HEADS UP! Default value of ip6_v6only changed Message-ID: <20031028063802.GC10818@canolog.ninthwonder.com> Mail-Followup-To: tech-net@netbsd.org, current-users@netbsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Sender: tech-net-owner@NetBSD.org Precedence: list X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on cheer.mahoroba.org The default value of ip6_v6only (sysctl net.inet6.ip6.v6only) has been changed. The new value brings us closer in line with current RFC-defined behavior and practices. Itojun still has significant concerns about the new default behavior. His concerns have been well-documented in ftp://ftp.itojun.org/pub/paper/draft-cmetz-v6ops-v4mapped-api-harmful-00.txt Best Regards, NetBSD OS PMC (core) -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@bisd.hitachi.co.jp ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Tue_Oct_28_22:14:46_2003-1-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 07:40:23 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B36F16A4CF; Tue, 28 Oct 2003 07:40:23 -0800 (PST) Received: from basie.internet2.edu (basie.internet2.edu [207.75.164.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38E3543F85; Tue, 28 Oct 2003 07:40:22 -0800 (PST) (envelope-from boote@internet2.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id A36353F8; Tue, 28 Oct 2003 10:40:21 -0500 (EST) Received: from internet2.edu (unknown [127.0.0.1]) by basie.internet2.edu (Postfix) with ESMTP id 2B8AC32A; Tue, 28 Oct 2003 10:40:20 -0500 (EST) Message-ID: <3F9E8DE3.61A5D814@internet2.edu> Date: Tue, 28 Oct 2003 08:40:19 -0700 From: "Jeff W. Boote" X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Hajimu UMEMOTO References: <20031028063802.GC10818@canolog.ninthwonder.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by mail.internet2.edu virus scanner cc: arch@FreeBSD.org cc: current@FreeBSD.org cc: net@FreeBSD.org Subject: Re: Forward: HEADS UP! Default value of ip6_v6only changed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 15:40:23 -0000 Hajimu UMEMOTO wrote: > > Hi, > > Our default of net.inet6.ip6.v6only was off in 4.X, and was changed to > on on 5.X to follow NetBSD's practice. This behavior on 5.X breaks > RFC2553/3493, and the change was intentional from security > consideration. But, NetBSD changed it off by default. > How do you think our default of on? As long as it is documented well, and the workaround (setting the IPV6_V6ONLY sockopt "off") is referenced, I don't think it really matters. Application programmers realize they have *some* work to do when porting applications to V6. A single sockopt call is not unreasonable. I think "on" for the security reasons outlined is the right call - it will at least make people think about those issues, and most would not without something bringing it up. (That said, it would be nice if NetBSD would pick a direction and keep it.) jeff From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 11:23:35 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F00C216A4CE for ; Tue, 28 Oct 2003 11:23:35 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id EAFA443F85 for ; Tue, 28 Oct 2003 11:23:34 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 43684 invoked from network); 28 Oct 2003 19:23:33 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 28 Oct 2003 19:23:33 -0000 X-pair-Authenticated: 209.68.2.70 Date: Tue, 28 Oct 2003 13:23:32 -0600 (CST) From: Mike Silbersack To: Bruce M Simpson In-Reply-To: <20031028050103.GA7279@saboteur.dek.spc.org> Message-ID: <20031028131329.J19707@odysseus.silby.com> References: <20031027014854.K2023@odysseus.silby.com> <20031028050103.GA7279@saboteur.dek.spc.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Changes to PCBPORTHASH wrt TCP, review needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 19:23:36 -0000 On Tue, 28 Oct 2003, Bruce M Simpson wrote: > We discussed on IRC that this problem of ephemeral port hash mapping may also > affect udp PCBs, and that it may be having undesirable effects with multiple > concurrent media streams, as RTP/RTCP is a heavy udp socket consumer in a > large installation, and has specific requirements for binding consecutive > odd/even port pairs (more details in RFC 3550 for those who care). > > I will test the patch shortly. I have looked over it and can't find any > immediate problems with it, but further digestion on my part is required. > > BMS Bleh, I found a problem with my suggested change. Suppose that a program works as follows: 1. bind (to an ephemeral port) 2. connect It's very possible that bind will return a port which can't be used because it's already in use for that destination lport-laddr-fport-faddr tuple, so the connect will fail with EADDRINUSE. So, it looks like I can't solve this so simply... looks like I'll have to have the port lookup do IP comparisons as well. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 11:32:11 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B076316A4CF for ; Tue, 28 Oct 2003 11:32:11 -0800 (PST) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E35843FF7 for ; Tue, 28 Oct 2003 11:32:06 -0800 (PST) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id A52B76530D; Tue, 28 Oct 2003 05:01:10 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 93379-05-3; Tue, 28 Oct 2003 05:01:10 +0000 (GMT) Received: from saboteur.dek.spc.org (unknown [81.3.72.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 763E06530A; Tue, 28 Oct 2003 05:01:09 +0000 (GMT) Received: by saboteur.dek.spc.org (Postfix, from userid 1001) id 3D5CE28; Tue, 28 Oct 2003 05:01:04 +0000 (GMT) Date: Tue, 28 Oct 2003 05:01:03 +0000 From: Bruce M Simpson To: Mike Silbersack Message-ID: <20031028050103.GA7279@saboteur.dek.spc.org> Mail-Followup-To: Mike Silbersack , freebsd-net@freebsd.org References: <20031027014854.K2023@odysseus.silby.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031027014854.K2023@odysseus.silby.com> cc: freebsd-net@freebsd.org Subject: Re: Changes to PCBPORTHASH wrt TCP, review needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 19:32:11 -0000 On Mon, Oct 27, 2003 at 02:16:13AM -0600, Mike Silbersack wrote: > One easy way to test this patch is to install http_load, set your > ephemeral port range to something in the range of 30, and have it start > testing a host. It will quickly create TIME_WAIT sockets filling all > ephemeral ports. Without this patch, you will be unable to create > outgoing connections; with this patch, other outgoing connections will be > fine. I can confirm I can replicate this behaviour with 5.1-CURRENT and 5.1-RELEASE with http_load. We discussed on IRC that this problem of ephemeral port hash mapping may also affect udp PCBs, and that it may be having undesirable effects with multiple concurrent media streams, as RTP/RTCP is a heavy udp socket consumer in a large installation, and has specific requirements for binding consecutive odd/even port pairs (more details in RFC 3550 for those who care). I will test the patch shortly. I have looked over it and can't find any immediate problems with it, but further digestion on my part is required. BMS From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 12:30:14 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38A0516A4CE for ; Tue, 28 Oct 2003 12:30:14 -0800 (PST) Received: from mail.inka.de (quechua.inka.de [193.197.184.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8829B43F75 for ; Tue, 28 Oct 2003 12:30:12 -0800 (PST) (envelope-from mailnull@mips.inka.de) Received: from kemoauc.mips.inka.de (uucp@) by mail.inka.de with gbsmtp id 1AEaTi-0001He-00; Tue, 28 Oct 2003 21:30:10 +0100 Received: from kemoauc.mips.inka.de (localhost [127.0.0.1]) by kemoauc.mips.inka.de (8.12.10/8.12.10) with ESMTP id h9SKBA42082123 for ; Tue, 28 Oct 2003 21:11:10 +0100 (CET) (envelope-from mailnull@kemoauc.mips.inka.de) Received: (from mailnull@localhost) by kemoauc.mips.inka.de (8.12.10/8.12.10/Submit) id h9SKB9ig082122 for freebsd-net@freebsd.org; Tue, 28 Oct 2003 21:11:09 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Tue, 28 Oct 2003 20:11:08 +0000 (UTC) Message-ID: References: Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org Subject: Re: em(4) and multicast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 20:30:14 -0000 Christian Weisgerber wrote: > OpenBSD has ported the em(4) driver from FreeBSD. At least on > OpenBSD, em(4) is partially broken: it fails to receive multicast > ethernet frames. This turns out to be a bug in the OpenBSD driver that happened in the porting process. -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 13:17:26 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8188216A4CE for ; Tue, 28 Oct 2003 13:17:26 -0800 (PST) Received: from trueband.net (director.trueband.net [216.163.120.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 6FFAE43FBD for ; Tue, 28 Oct 2003 13:17:24 -0800 (PST) (envelope-from jhall@vandaliamo.net) Received: (qmail 19299 invoked by uid 1006); 28 Oct 2003 21:16:07 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 2.44. Clear:SA:0(2.8/100.0):. Processed in 1.153922 secs); 28 Oct 2003 21:16:07 -0000 X-Spam-Status: No, hits=2.8 required=100.0 X-Spam-Level: ** Received: from unknown (HELO trueband.net) (127.0.0.1) by -v with SMTP; 28 Oct 2003 21:16:05 -0000 Received: (qmail 19223 invoked from network); 28 Oct 2003 21:16:04 -0000 Received: from unknown (HELO admintool.trueband.net) (127.0.0.1) by -v with SMTP; 28 Oct 2003 21:16:04 -0000 Received: from 199.223.158.225 (SquirrelMail authenticated user jhall@vandaliamo.net) by admintool.trueband.net with HTTP; Tue, 28 Oct 2003 21:16:04 -0000 (GMT) Message-ID: <62764.199.223.158.225.1067375764.squirrel@admintool.trueband.net> Date: Tue, 28 Oct 2003 21:16:04 -0000 (GMT) From: jhall@vandaliamo.net To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: mpd, ADSL and pptp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 21:17:26 -0000 I am setting up a FreeBSD server to function as a agteway to the Internet as well as maintain the necessary tunnels to our corporate office. All of this should be accomplished over a DSL connection. I have setup mpd to make the PPPoE connection need to connect to the ADSL provider, and it is working without a problem. I am using ng0 for this connection. What is the best way to start natd after the connection to the DSL provider has been established? I am doing this manually right now for testing since I am looking at error messages, etc. I am currently using the following command to load natd. natd -interface ng0, where ng0 PPPoE connection. After the PPPoE connection is established, and I try to start open a pptp connection to the corporate VPN server, I am seeing the following error message. pptp-0: attached to connection with 111.222.333.444:1723 pptp0-0: outgoing call failed: res=admin prohib err=none. The server I am connecting to is also an mpd server. Following is the configuration file for the server. default: load pptp_StCharles pptp_StCharles: new -i ng1 pptp pptp setipcp ranges 10.129.10.40/32 10.129.10.101/32 set iface route 10.129.20.0/24 load client_standard client_standard: set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle enable multilink set link yes acfcomp protocomp set link no pap chap set link enable chap set link mtu 1460 set link keep-alive 10 60 set ipcp yes vjcomp set ipcp dns 10.129.10.41 set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless Thanks in advance for your assistance. If you need any additional information, please let me know. Jay From owner-freebsd-net@FreeBSD.ORG Tue Oct 28 13:38:01 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7408B16A4D6 for ; Tue, 28 Oct 2003 13:38:01 -0800 (PST) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26D7343FD7 for ; Tue, 28 Oct 2003 13:38:00 -0800 (PST) (envelope-from damian@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smtp3.sentex.ca (8.12.9p2/8.12.9) with ESMTP id h9SLbteW013054; Tue, 28 Oct 2003 16:37:55 -0500 (EST) (envelope-from damian@sentex.net) Received: from pegmatite.sentex.ca (pegmatite.sentex.ca [192.168.42.92]) by lava.sentex.ca (8.12.9p2/8.12.9) with ESMTP id h9SLbxYH060056; Tue, 28 Oct 2003 16:37:59 -0500 (EST) (envelope-from damian@sentex.net) Received: by pegmatite.sentex.ca (Postfix, from userid 1001) id D12571718B; Tue, 28 Oct 2003 16:37:46 -0500 (EST) Date: Tue, 28 Oct 2003 16:37:46 -0500 From: Damian Gerow To: jhall@vandaliamo.net Message-ID: <20031028213746.GX94315@sentex.net> References: <62764.199.223.158.225.1067375764.squirrel@admintool.trueband.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62764.199.223.158.225.1067375764.squirrel@admintool.trueband.net> X-GPG-Key-Id: 0xB841F142 X-GPG-Fingerprint: C7C1 E1D1 EC06 7C86 AF7C 57E6 173D 9CF6 B841 F142 X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.4i X-Virus-Scanned: by amavisd-new cc: freebsd-net@freebsd.org Subject: Re: mpd, ADSL and pptp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2003 21:38:01 -0000 Thus spake jhall@vandaliamo.net (jhall@vandaliamo.net) [28/10/03 16:16]: > I am setting up a FreeBSD server to function as a agteway to the Internet > as well as maintain the necessary tunnels to our corporate office. All of > this should be accomplished over a DSL connection. > > I have setup mpd to make the PPPoE connection need to connect to the ADSL > provider, and it is working without a problem. I am using ng0 for this > connection. > > What is the best way to start natd after the connection to the DSL > provider has been established? I am doing this manually right now for > testing since I am looking at error messages, etc. > > I am currently using the following command to load natd. > > natd -interface ng0, where ng0 PPPoE connection. Look at 'set iface up-script': From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 01:04:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBA6E16A4CF for ; Wed, 29 Oct 2003 01:04:57 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AFC143F75 for ; Wed, 29 Oct 2003 01:04:56 -0800 (PST) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])h9T94mvG017618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2003 10:04:54 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4])ESMTP id h9T94mno086148; Wed, 29 Oct 2003 10:04:48 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id KAA09027; Wed, 29 Oct 2003 10:04:46 +0100 (MET) Message-Id: <200310290904.KAA09027@galaxy.hbg.de.ao-srv.com> In-Reply-To: <86n0bllhez.fsf@t39bsdems.interne.kisoft-services.com> from Eric Masson at "Oct 28, 2003 12:40: 4 pm" To: e-masson@kisoft-services.com (Eric Masson) Date: Wed, 29 Oct 2003 10:04:46 +0100 (MET) From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782517 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 09:04:58 -0000 Eric Masson: >>>>>> "Michael" == Michael Sierchio writes: > > Michael> You should allow for an IP header with options and the ESP > Michael> header, which is smaller than 1450. For SKIP I use 1366 as the > Michael> advertised MTU, and for IPsec usually 1436, unless I need to > Michael> accomodate ESP and AH, in which case it's smaller. > >Ok, that's fine. > > Michael> It's a known feature of any sort of IP encapsulation. > >I understand. > >I'm no kernel hacker at all, I was just thinking about the ability for >the tunnel endpoint to send back an icmp packet type 3 code 4 when the >packet is too long to be encapsulated. Actually this is the case. Or better, it *should* be happening - I don't know if you see the ICMPs or not. Note that this must be done on the local tunnel endpoint, not the remote one. Helge From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 02:05:53 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E9DA16A4CE for ; Wed, 29 Oct 2003 02:05:53 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F6FF43FBD for ; Wed, 29 Oct 2003 02:05:50 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id 24EF36C929; Wed, 29 Oct 2003 11:05:49 +0100 (CET) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 7A89E5B6AF; Wed, 29 Oct 2003 11:05:12 +0100 (CET) To: Helge Oldach From: Eric Masson In-Reply-To: <200310290904.KAA09027@galaxy.hbg.de.ao-srv.com> (Helge Oldach's message of "Wed, 29 Oct 2003 10:04:46 +0100 (MET)") References: <200310290904.KAA09027@galaxy.hbg.de.ao-srv.com> X-Operating-System: FreeBSD 4.9-PRERELEASE i386 Date: Wed, 29 Oct 2003 11:05:11 +0100 Message-ID: <864qxs7414.fsf@t39bsdems.interne.kisoft-services.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 10:05:53 -0000 >>>>> "Helge" == Helge Oldach writes: Hello Helge, Helge> Actually this is the case. I'd like... Helge> Or better, it *should* be happening - Helge> I don't know if you see the ICMPs or not. Nope no "message too long" icmp packet returned to originator (nothing in tcpdump on internal interface nor in FW1 logs) Regards Eric Masson -- > Quant à ma mauvaise quote de mail , désolé, c'est Outlook qui coupe tout > seul à 76. (pour ton répertoire de neuneuX, si tu veux) > (comme les lignes font déjà 76, avec les quotes, forcément, çà dépasse) -+- C in: - Quand les bornes sont franchies -+- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 08:22:24 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D32E116A4CE for ; Wed, 29 Oct 2003 08:22:24 -0800 (PST) Received: from hotmail.com (law12-oe47.law12.hotmail.com [64.4.18.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D75BE43FBF for ; Wed, 29 Oct 2003 08:22:21 -0800 (PST) (envelope-from company2210@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 29 Oct 2003 08:22:21 -0800 Received: from 81.17.78.11 by law12-oe47.law12.hotmail.com with DAV; Wed, 29 Oct 2003 16:22:21 +0000 X-Originating-IP: [81.17.78.11] X-Originating-Email: [company2210@hotmail.com] From: "Company 2210" To: References: <200310290904.KAA09027@galaxy.hbg.de.ao-srv.com> Date: Wed, 29 Oct 2003 16:22:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Message-ID: X-OriginalArrivalTime: 29 Oct 2003 16:22:21.0744 (UTC) FILETIME=[D4866300:01C39E38] Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 16:22:24 -0000 So, what would be a suitable MTU value for an ESP encrypted packet using Blowfish? Thanks ----- Original Message ----- From: "Helge Oldach" To: "Eric Masson" Cc: Sent: Wednesday, October 29, 2003 9:04 AM Subject: Re: ipsec tunnels & packet length issues > Eric Masson: > >>>>>> "Michael" == Michael Sierchio writes: > > > > Michael> You should allow for an IP header with options and the ESP > > Michael> header, which is smaller than 1450. For SKIP I use 1366 as the > > Michael> advertised MTU, and for IPsec usually 1436, unless I need to > > Michael> accomodate ESP and AH, in which case it's smaller. > > > >Ok, that's fine. > > > > Michael> It's a known feature of any sort of IP encapsulation. > > > >I understand. > > > >I'm no kernel hacker at all, I was just thinking about the ability for > >the tunnel endpoint to send back an icmp packet type 3 code 4 when the > >packet is too long to be encapsulated. > > Actually this is the case. Or better, it *should* be happening - I don't > know if you see the ICMPs or not. Note that this must be done on the > local tunnel endpoint, not the remote one. > > Helge > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 12:15:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D67516A4CE; Wed, 29 Oct 2003 12:15:44 -0800 (PST) Received: from srv00.el.com.br (srv00.el.com.br [200.179.165.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D96E43FAF; Wed, 29 Oct 2003 12:15:43 -0800 (PST) (envelope-from npd@el.com.br) Received: from intranet.el.com.br (srv00.el.com.br [200.179.165.123]) by srv00.el.com.br (elsmtp) with SMTP id E7CEF70E4C; Wed, 29 Oct 2003 18:15:39 -0200 (BRST) Received: from 172.72.12.252 (SquirrelMail authenticated user npd) by intranet.el.com.br with HTTP; Wed, 29 Oct 2003 18:15:40 -0200 (BRST) Message-ID: <1545.172.72.12.252.1067458540.squirrel@intranet.el.com.br> Date: Wed, 29 Oct 2003 18:15:40 -0200 (BRST) From: "Nucleo de Pesquisa e Desenvolvimento" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal cc: freebsd-isp@freebsd.org Subject: IPSEC in tunnel mode ( possible? ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 20:15:44 -0000 Hi everyone, I know it is kind an off-topic question but maybe another network admin have already faced the following: client--[__ipsec__]--gw--[__ip__]--internet I, trying to secure a wireless link, want to have my clients using ipsec on the segment between the gateway gw and the machine itself even when the traffic is to the internet and not only to the gateway ( what works fine in transport mode anyway ). The clients are windows machines. Accordingly to Microsoft 252735 tunnel is possible when a windows is acting as a gateway, not our scenario where machines are only clients... Any one could point me to some url or send me keywords I should look for please? If things won´t work with ipsec I´ll do it with MPD... but I still should have ask it here. Thanks in advance ( and sorry for the cross posting ), -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Paiva, Gilson de Domingos Martins mailto:npd@el.com.br Brazil http://www.el.com.br/ E&L Producoes de Software http://www.FreeBSD.org/ FreeBSD: The Power to Serve =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 12:16:52 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CA2C16A4CE; Wed, 29 Oct 2003 12:16:52 -0800 (PST) Received: from p4.ecoms.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC0C743FEA; Wed, 29 Oct 2003 12:16:48 -0800 (PST) (envelope-from michael@roq.com) Received: by p4.ecoms.com (Postfix, from userid 12021) id 2F76726818F; Wed, 29 Oct 2003 16:45:22 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by p4.ecoms.com (Postfix) with ESMTP id 4B773268175 for ; Wed, 29 Oct 2003 16:45:21 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 7DDF856336; Wed, 29 Oct 2003 12:16:41 -0800 (PST) (envelope-from owner-freebsd-isp@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A1C516A4D1; Wed, 29 Oct 2003 12:16:40 -0800 (PST) Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D67516A4CE; Wed, 29 Oct 2003 12:15:44 -0800 (PST) Received: from srv00.el.com.br (srv00.el.com.br [200.179.165.123]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D96E43FAF; Wed, 29 Oct 2003 12:15:43 -0800 (PST) (envelope-from npd@el.com.br) Received: from intranet.el.com.br (srv00.el.com.br [200.179.165.123]) by srv00.el.com.br (elsmtp) with SMTP id E7CEF70E4C; Wed, 29 Oct 2003 18:15:39 -0200 (BRST) Received: from 172.72.12.252 (SquirrelMail authenticated user npd) by intranet.el.com.br with HTTP; Wed, 29 Oct 2003 18:15:40 -0200 (BRST) Message-ID: <1545.172.72.12.252.1067458540.squirrel@intranet.el.com.br> Date: Wed, 29 Oct 2003 18:15:40 -0200 (BRST) From: "Nucleo de Pesquisa e Desenvolvimento" To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-isp@freebsd.org Errors-To: owner-freebsd-isp@freebsd.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p4.ecoms.com X-Spam-Status: No, hits=0.8 required=5.0 tests=PRIORITY_NO_NAME autolearn=no version=2.60 X-Spam-Level: cc: freebsd-isp@freebsd.org Subject: IPSEC in tunnel mode ( possible? ) X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 20:16:52 -0000 Hi everyone, I know it is kind an off-topic question but maybe another network admin have already faced the following: client--[__ipsec__]--gw--[__ip__]--internet I, trying to secure a wireless link, want to have my clients using ipsec on the segment between the gateway gw and the machine itself even when the traffic is to the internet and not only to the gateway ( what works fine in transport mode anyway ). The clients are windows machines. Accordingly to Microsoft 252735 tunnel is possible when a windows is acting as a gateway, not our scenario where machines are only clients... Any one could point me to some url or send me keywords I should look for please? If things won´t work with ipsec I´ll do it with MPD... but I still should have ask it here. Thanks in advance ( and sorry for the cross posting ), -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Paiva, Gilson de Domingos Martins mailto:npd@el.com.br Brazil http://www.el.com.br/ E&L Producoes de Software http://www.FreeBSD.org/ FreeBSD: The Power to Serve =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ freebsd-isp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 13:03:53 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C76E116A4CE for ; Wed, 29 Oct 2003 13:03:53 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14DCF43FBD for ; Wed, 29 Oct 2003 13:03:53 -0800 (PST) (envelope-from larse@ISI.EDU) Received: from isi.edu (nik.isi.edu [128.9.168.58]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id h9TL3ij17888; Wed, 29 Oct 2003 13:03:44 -0800 (PST) Message-ID: <3FA02B30.90805@isi.edu> Date: Wed, 29 Oct 2003 13:03:44 -0800 From: Lars Eggert Organization: USC Information Sciences Institute User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031021 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Masson References: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> In-Reply-To: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070303060601040704090005" cc: Mailing List FreeBSD Network Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 21:03:53 -0000 This is a cryptographically signed message in MIME format. --------------ms070303060601040704090005 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Eric Masson wrote: > > If i reduce lan interface mtu on "Host" to approximately 1450, the > tunnel works fine, so it seems that "Tunnel Endpoint" can't process > correctly packets with a size of 1500 bytes. > > If more information regarding this issue is needed, just ask. > Is this a known issue ? > Except playing with mtu, is there a fix ? See the section on PMTU discovery in draft-touch-ipsec-vpn-06. If the requirements of your setup allow is, IPIP gif tunnels together with IPsec transport mode (as described in the ID) can address this issue. Lars -- Lars Eggert USC Information Sciences Institute --------------ms070303060601040704090005 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJtjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2Vydmlj ZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkG CSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAw LjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZ gpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFp AgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtH XfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1M G7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjCCAzkwggKioAMCAQICAwp2bzANBgkqhkiG9w0BAQQFADCBkjEL MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYD VQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44LjMwMB4XDTAzMDgwMTE3MjkyOVoX DTA0MDczMTE3MjkyOVowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYD VQQDEwtMYXJzIEVnZ2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMb7PuLXnwV+45vwlkgogdSijd5HVqUB14bWvoK0 MjWPnkLPMDMDEezdsMG1BPiZyNeqXlJJtEgdAK8H2Mc9/qLeJUq3CoAeD6Wrjq4QaxJBXgdS KcGDeQAZSDgwUJS9vx9+cXJVfLyOYxJ+CLBcO/eu8PvSi17lk6oeAbrskSGDu/Xi1o2SC4Qm l69k8xcZQEMQDodkIk/U5SJmsCRGGYdy7opHZb58yXI8eiIGp5MlgryFmmgrp1pg3OYzPOR9 zJjn7Pu1vsd97LM5hLnKrmNuYt02jLNSjr8HmpLyWCDZq4Jlfq1YgNYZZ4KOSxipia7Bxjcs nMOsxEWiolkVVT8CAwEAAaNWMFQwKgYFK2UBBAEEITAfAgEAMBowGAIBBAQTTDJ1TXlmZkJO VWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1MAwGA1UdEwEB/wQCMAAwDQYJ KoZIhvcNAQEEBQADgYEANRaPsUtrdJzTW0AMj/EQamqxOkZnzwnPWGryqskMKIf+OKa+eaXp zlBv8CHdffv9hrYpvzWUxk0WW+YJ2LRdd4fFiVGXZCGU60eYeZGf7Z8ORoexylJpvUuKZCE4 aPGY2/QZXDfOs1NE82Bhgltx59dpWfH2K0dxbpHslO8/IbowggM5MIICoqADAgECAgMKdm8w DQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MDAeFw0wMzA4MDExNzI5MjlaFw0wNDA3MzExNzI5MjlaMFQxDzANBgNVBAQTBkVnZ2VydDEN MAsGA1UEKhMETGFyczEUMBIGA1UEAxMLTGFycyBFZ2dlcnQxHDAaBgkqhkiG9w0BCQEWDWxh cnNlQGlzaS5lZHUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDG+z7i158FfuOb 8JZIKIHUoo3eR1alAdeG1r6CtDI1j55CzzAzAxHs3bDBtQT4mcjXql5SSbRIHQCvB9jHPf6i 3iVKtwqAHg+lq46uEGsSQV4HUinBg3kAGUg4MFCUvb8ffnFyVXy8jmMSfgiwXDv3rvD70ote 5ZOqHgG67JEhg7v14taNkguEJpevZPMXGUBDEA6HZCJP1OUiZrAkRhmHcu6KR2W+fMlyPHoi BqeTJYK8hZpoK6daYNzmMzzkfcyY5+z7tb7HfeyzOYS5yq5jbmLdNoyzUo6/B5qS8lgg2auC ZX6tWIDWGWeCjksYqYmuwcY3LJzDrMRFoqJZFVU/AgMBAAGjVjBUMCoGBStlAQQBBCEwHwIB ADAaMBgCAQQEE0wydU15ZmZCTlViTkpKY2RaMnMwGAYDVR0RBBEwD4ENbGFyc2VAaXNpLmVk dTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBADUWj7FLa3Sc01tADI/xEGpqsTpG Z88Jz1hq8qrJDCiH/jimvnml6c5Qb/Ah3X37/Ya2Kb81lMZNFlvmCdi0XXeHxYlRl2QhlOtH mHmRn+2fDkaHscpSab1LimQhOGjxmNv0GVw3zrNTRPNgYYJbcefXaVnx9itHcW6R7JTvPyG6 MYID1TCCA9ECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUx EjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZp Y2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4z MAIDCnZvMAkGBSsOAwIaBQCgggIPMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTAzMTAyOTIxMDM0NFowIwYJKoZIhvcNAQkEMRYEFNh9KUthpceoPP4eZB56 dv55ENMlMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGrBgkrBgEEAYI3EAQxgZ0w gZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh cGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNl czEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAIDCnZvMIGtBgsq hkiG9w0BCRACCzGBnaCBmjCBkjELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2Fw ZTESMBAGA1UEBxMJQ2FwZSBUb3duMQ8wDQYDVQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRp ZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25hbCBGcmVlbWFpbCBSU0EgMjAwMC44 LjMwAgMKdm8wDQYJKoZIhvcNAQEBBQAEggEAv9bQvRQ5YYefTQoNfx4wW0LmKchDFxb8bq15 I6twzwhxltWki6dpswWqSBe7+BHW21EM4CfpxeKMILFsQbatdgOYTXYQVsOKEwuW9q82E81y KTvkR8EBP/dwEE3lV73jH9wZWsvpUJ7sdxv3dmvSbMXrT29JRPxE2XwFTt6fqXBKiasvhqwK j6w6CyRRgxrTLV+fsLxCLa8PdoosF+SOHvcXMpm1hUpDArOKJFIqEaMp/kR+ohzELSVIr80y EjtwRV+U1wn0F546G+AaFlAjCYYE2LlQ4F3YscP+gF/7nUH3OLGu8jMhhnT2O4AwUuze6blr ivUbPmcLOz9r/8zZOwAAAAAAAA== --------------ms070303060601040704090005-- From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 14:15:36 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D52E616A4D1; Wed, 29 Oct 2003 14:15:36 -0800 (PST) Received: from aragorn.summit.net.au (aragorn.summit.net.au [203.221.180.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5FF143FF3; Wed, 29 Oct 2003 14:15:35 -0800 (PST) (envelope-from lachlan@fatpanda.net) Received: from 127.0.0.1 (localhost [127.0.0.1]) by mail.summit.net.au (Postfix) with SMTP id 62B7414D41; Thu, 30 Oct 2003 09:15:30 +1100 (EST) Received: from felix (project.summit.net.au [218.185.87.4]) by aragorn.summit.net.au (Postfix) with SMTP id 7027714CF2; Thu, 30 Oct 2003 09:15:29 +1100 (EST) From: "Lachlan" To: "Nucleo de Pesquisa e Desenvolvimento" , Date: Thu, 30 Oct 2003 09:15:32 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1545.172.72.12.252.1067458540.squirrel@intranet.el.com.br> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable cc: freebsd-isp@freebsd.org Subject: RE: IPSEC in tunnel mode ( possible? ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 22:15:37 -0000 I'm not sure if my guess is correct. But instead of using windows over ipsec, i would use 2 FreeBSD boxes. eg, Client Host -- [ipsec on bsd] -- (( wirless )) -- [ipsec on bsd to decrypt] -- (( internet )) Not sure if that's what you're trying to do, was a little hard to understand. If that is the case, there is a nice article on freebsd diary that covers this pretty well. http://www.freebsddiary.org/ipsec.php Regards, Lachlan -----Original Message----- From: owner-freebsd-isp@freebsd.org [mailto:owner-freebsd-isp@freebsd.org]On Behalf Of Nucleo de Pesquisa e Desenvolvimento Sent: Thursday, October 30, 2003 7:16 AM To: freebsd-net@freebsd.org Cc: freebsd-isp@freebsd.org Subject: IPSEC in tunnel mode ( possible? ) Hi everyone, I know it is kind an off-topic question but maybe another network admi= n have already faced the following: client--[__ipsec__]--gw--[__ip__]--internet I, trying to secure a wireless link, want to have my clients using ipsec on the segment between the gateway gw and the machine itself even when the traffic is to the internet and not only to the gateway ( what works fine in transport mode anyway ). The clients are windows machines. Accordingly to Microsoft 252735 tunnel is possible when a windows is acting as a gateway, not our scenario where machines are only clients... Any one could point me to some url or send me keywords I should look for please? If things won=B4t work with ipsec I=B4ll do it with MPD... bu= t I still should have ask it here. Thanks in advance ( and sorry for the cross posting ), -- =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Paiva, Gilson de Domingos Martins mailto:npd@el.com.br Brazil http://www.el.com.br/ E&L Producoes de Software http://www.FreeBSD.org/ FreeBSD: The Power to Serve =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D- _______________________________________________ freebsd-isp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 14:17:23 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E85A516A4CE; Wed, 29 Oct 2003 14:17:23 -0800 (PST) Received: from p4.ecoms.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF67943FF3; Wed, 29 Oct 2003 14:17:20 -0800 (PST) (envelope-from michael@roq.com) Received: by p4.ecoms.com (Postfix, from userid 12021) id 70854268133; Wed, 29 Oct 2003 18:45:54 -0600 (CST) Received: from mx2.freebsd.org (mx2.freebsd.org [216.136.204.119]) by p4.ecoms.com (Postfix) with ESMTP id 9B3F026812D for ; Wed, 29 Oct 2003 18:45:53 -0600 (CST) Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 072EB562F0; Wed, 29 Oct 2003 14:17:13 -0800 (PST) (envelope-from owner-freebsd-isp@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id E47C916A4EB; Wed, 29 Oct 2003 14:17:10 -0800 (PST) Delivered-To: freebsd-isp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D52E616A4D1; Wed, 29 Oct 2003 14:15:36 -0800 (PST) Received: from aragorn.summit.net.au (aragorn.summit.net.au [203.221.180.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5FF143FF3; Wed, 29 Oct 2003 14:15:35 -0800 (PST) (envelope-from lachlan@fatpanda.net) Received: from 127.0.0.1 (localhost [127.0.0.1]) by mail.summit.net.au (Postfix) with SMTP id 62B7414D41; Thu, 30 Oct 2003 09:15:30 +1100 (EST) Received: from felix (project.summit.net.au [218.185.87.4]) by aragorn.summit.net.au (Postfix) with SMTP id 7027714CF2; Thu, 30 Oct 2003 09:15:29 +1100 (EST) From: "Lachlan" To: "Nucleo de Pesquisa e Desenvolvimento" , Date: Thu, 30 Oct 2003 09:15:32 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1545.172.72.12.252.1067458540.squirrel@intranet.el.com.br> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-isp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-isp@freebsd.org Errors-To: owner-freebsd-isp@freebsd.org X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on p4.ecoms.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: cc: freebsd-isp@freebsd.org Subject: RE: IPSEC in tunnel mode ( possible? ) X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 22:17:24 -0000 I'm not sure if my guess is correct. But instead of using windows over ipsec, i would use 2 FreeBSD boxes. eg, Client Host -- [ipsec on bsd] -- (( wirless )) -- [ipsec on bsd to decrypt] -- (( internet )) Not sure if that's what you're trying to do, was a little hard to understand. If that is the case, there is a nice article on freebsd diary that covers this pretty well. http://www.freebsddiary.org/ipsec.php Regards, Lachlan -----Original Message----- From: owner-freebsd-isp@freebsd.org [mailto:owner-freebsd-isp@freebsd.org]On Behalf Of Nucleo de Pesquisa e Desenvolvimento Sent: Thursday, October 30, 2003 7:16 AM To: freebsd-net@freebsd.org Cc: freebsd-isp@freebsd.org Subject: IPSEC in tunnel mode ( possible? ) Hi everyone, I know it is kind an off-topic question but maybe another network admi= n have already faced the following: client--[__ipsec__]--gw--[__ip__]--internet I, trying to secure a wireless link, want to have my clients using ipsec on the segment between the gateway gw and the machine itself even when the traffic is to the internet and not only to the gateway ( what works fine in transport mode anyway ). The clients are windows machines. Accordingly to Microsoft 252735 tunnel is possible when a windows is acting as a gateway, not our scenario where machines are only clients... Any one could point me to some url or send me keywords I should look for please? If things won=B4t work with ipsec I=B4ll do it with MPD... bu= t I still should have ask it here. Thanks in advance ( and sorry for the cross posting ), -- =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Paiva, Gilson de Domingos Martins mailto:npd@el.com.br Brazil http://www.el.com.br/ E&L Producoes de Software http://www.FreeBSD.org/ FreeBSD: The Power to Serve =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D- _______________________________________________ freebsd-isp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" _______________________________________________ freebsd-isp@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Oct 29 15:41:44 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9A9316A4D6 for ; Wed, 29 Oct 2003 15:41:44 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2626B4402B for ; Wed, 29 Oct 2003 15:40:56 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id KAA739136 for ; Thu, 30 Oct 2003 10:40:42 +1100 (EST) From: paul van den bergen To: freebsd-net@freebsd.org Date: Thu, 30 Oct 2003 10:40:38 +1100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310301040.38438.pvandenbergen@swin.edu.au> Subject: IPv6 hassles. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2003 23:41:47 -0000 Hi all. I am having troubles understanding and implementing an IPv6 network either there is something wrong with my understanding, or there is something wrong with my implementation/brain... here is my understanding of what is IPv6 under freebsd. in /etc/rc.conf ipv6_enabled="yes" turns IPv6 on. on boot, looks for a router to get info on IP address (address discovery) if no router, fe80:: address created. if router that speaks ipv6, either globally unicast or site local (fec0::) addresses created. because I am in the early stages of messing with this, and also because I want to mess with the addresses etc., I am trying to set up 3 networks using site local addresses. I am manually assigning fec0::299/64, fec0::172/64 and fec0::10/64 networks on the appropriate interface using ifconfig vr0 inet6 fec0:0:0:10::/64 anycast ifconfig vr0 inet6 fec0:0:0:10::/64 eui64 questions I have are... why can't I ping6 between fe80:: addresses on the network? why can't I get static routes to work for the fec0:: addresses (or perhaps a better Q would be _how_ do I set up such routes?) this is not a link layer or physical layer problem because the ipv4 stuff works just fine... btw, fec0::10/64 and fec0::172/64 are via wifi and an AP. -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 13:05:13 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFC5816A4CE; Thu, 30 Oct 2003 13:05:13 -0800 (PST) Received: from omoikane.mb.skyweb.ca (209-5-243-50.mb.skyweb.ca [209.5.243.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0179D43FBF; Thu, 30 Oct 2003 13:05:11 -0800 (PST) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id 120B262FD2; Thu, 30 Oct 2003 15:05:10 -0600 (CST) Date: Thu, 30 Oct 2003 15:05:09 -0600 From: Mark Johnston To: security@freebsd.org Message-ID: <20031030210509.GA667@omoikane.mb.skyweb.ca> Mail-Followup-To: security@freebsd.org, net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: net@freebsd.org Subject: Using racoon-negotiated IPSec with ipfw and natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 21:05:14 -0000 [ -netters, please Cc me or security@ with replies. ] I'm running into trouble integrating dynamic racoon-based IPSec into a network with ipfw and natd. I need to be able to allow VPN access from any address from authenticated clients. I've got the dynamic VPN working, with racoon negotiating SAs and installing SPs, but the problem is that I can't tell whether an incoming packet on the internal interface should go through natd or not. The problem looks like this. I have 3 boxes, mobile, gateway, and internal, and I'm trying to ping internal from mobile. - gateway receives an ESP packet from mobile (encapsulating a ping). - gateway decrypts and transmits an ICMP packet to internal with mobile's source address. - internal generates the ICMP response to mobile. - gateway receives the response, runs it through natd, and sends it out in the clear to mobile with gateway's source address. The packet is going out in the clear because after natd rewrites it, its source address is gateway's external interface - not part of the SP. What I want to accomplish, in pseudo-ipfw, is this: pass esp from any to me pass ip from known-sp-sources to 192.168.0.0/24 pass ip from 192.168.0.0/24 to known-sp-destinations divert natd from 192.168.0.0/24 to any deny ip from any to 192.168.0.0/24 pass ip from me to any keep-state All I'm missing is the known-sp definitions. If anyone has any pointers on doing this, please share. If I'm going about it totally bass-ackwards, I'd like to hear that too. :) Thanks, Mark From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 14:43:27 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D84E016A4CE; Thu, 30 Oct 2003 14:43:27 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A30343FE5; Thu, 30 Oct 2003 14:43:26 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (sccrmhc11) with ESMTP id <2003103022432501100k862je>; Thu, 30 Oct 2003 22:43:25 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id h9UMhisb033295; Thu, 30 Oct 2003 14:43:44 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id h9UMhgai033294; Thu, 30 Oct 2003 14:43:42 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Thu, 30 Oct 2003 14:43:42 -0800 From: "Crist J. Clark" To: security@freebsd.org, net@freebsd.org Message-ID: <20031030224342.GA32640@blossom.cjclark.org> References: <20031030210509.GA667@omoikane.mb.skyweb.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031030210509.GA667@omoikane.mb.skyweb.ca> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: Using racoon-negotiated IPSec with ipfw and natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 22:43:28 -0000 On Thu, Oct 30, 2003 at 03:05:09PM -0600, Mark Johnston wrote: > [ -netters, please Cc me or security@ with replies. ] > > I'm running into trouble integrating dynamic racoon-based IPSec into a network > with ipfw and natd. I need to be able to allow VPN access from any address > from authenticated clients. I've got the dynamic VPN working, with racoon > negotiating SAs and installing SPs, but the problem is that I can't tell > whether an incoming packet on the internal interface should go through natd or > not. > > The problem looks like this. I have 3 boxes, mobile, gateway, and internal, > and I'm trying to ping internal from mobile. > > - gateway receives an ESP packet from mobile (encapsulating a ping). > - gateway decrypts and transmits an ICMP packet to internal with mobile's > source address. > - internal generates the ICMP response to mobile. > - gateway receives the response, runs it through natd, and sends it out in the > clear to mobile with gateway's source address. > > The packet is going out in the clear because after natd rewrites it, its source > address is gateway's external interface - not part of the SP. This shouldn't happen. IPsec processing of the outgoing packet happens _before_ it gets passed to ipfw(8) (which hands it to natd(8)) on the external interface. > What I want to > accomplish, in pseudo-ipfw, is this: > > pass esp from any to me > pass ip from known-sp-sources to 192.168.0.0/24 > pass ip from 192.168.0.0/24 to known-sp-destinations > divert natd from 192.168.0.0/24 to any This may be your problem. That rule should be something like, divert natd from 192.168.0.0/24 to any via ${external_if} Is that what you actually have? Are you doing NAT on the internal interface? That would confuse things. > deny ip from any to 192.168.0.0/24 > pass ip from me to any keep-state > > All I'm missing is the known-sp definitions. If anyone has any pointers on > doing this, please share. If I'm going about it totally bass-ackwards, I'd > like to hear that too. :) -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 14:57:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B422716A4CE for ; Thu, 30 Oct 2003 14:57:42 -0800 (PST) Received: from trueband.net (director.trueband.net [216.163.120.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 6605B43F93 for ; Thu, 30 Oct 2003 14:57:41 -0800 (PST) (envelope-from jhall@vandaliamo.net) Received: (qmail 3453 invoked by uid 1006); 30 Oct 2003 22:57:37 -0000 Received: from jhall@vandaliamo.net by rs0 by uid 1003 with qmail-scanner-1.16 (spamassassin: 2.44. Clear:SA:0(-3.4/100.0):. Processed in 0.740187 secs); 30 Oct 2003 22:57:37 -0000 X-Spam-Status: No, hits=-3.4 required=100.0 X-Spam-Level: Received: from unknown (HELO trueband.net) (127.0.0.1) by -v with SMTP; 30 Oct 2003 22:57:36 -0000 Received: (qmail 3367 invoked from network); 30 Oct 2003 22:57:35 -0000 Received: from unknown (HELO vandaliamo.net) (12.170.206.13) by -v with SMTP; 30 Oct 2003 22:57:35 -0000 Message-ID: <3FA18D74.1000704@vandaliamo.net> Date: Thu, 30 Oct 2003 16:15:16 -0600 From: Jay Hall User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Damian Gerow References: <62764.199.223.158.225.1067375764.squirrel@admintool.trueband.net> <20031028213746.GX94315@sentex.net> In-Reply-To: <20031028213746.GX94315@sentex.net> X-Enigmail-Version: 0.71.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: mpd, ADSL and pptp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 22:57:42 -0000 This does work, but after a short period of time (i.e. 5-10 minutes) I received a message stating ping: send to: out of buffer space. At that time, the mpd pptp connection dies, and I cannot reconnect until the machine is rebooted. Are there parameters that can be changed to tune the kernel so this does not happen? My google search did not reveal any answers that fixed the problem. Thanks for all your help. Jay Damian Gerow wrote: >Thus spake jhall@vandaliamo.net (jhall@vandaliamo.net) [28/10/03 16:16]: > > >>I am setting up a FreeBSD server to function as a agteway to the Internet >>as well as maintain the necessary tunnels to our corporate office. All of >>this should be accomplished over a DSL connection. >> >>I have setup mpd to make the PPPoE connection need to connect to the ADSL >>provider, and it is working without a problem. I am using ng0 for this >>connection. >> >>What is the best way to start natd after the connection to the DSL >>provider has been established? I am doing this manually right now for >>testing since I am looking at error messages, etc. >> >>I am currently using the following command to load natd. >> >>natd -interface ng0, where ng0 PPPoE connection. >> >> > >Look at 'set iface up-script': > > > > > > From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 15:30:04 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1AAF16A4CE for ; Thu, 30 Oct 2003 15:30:04 -0800 (PST) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88E1E43FBF for ; Thu, 30 Oct 2003 15:30:01 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (sccrmhc11) with ESMTP id <2003103023300001100k2lgce>; Thu, 30 Oct 2003 23:30:00 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id h9UNUJsb033542; Thu, 30 Oct 2003 15:30:19 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id h9UNUIwc033541; Thu, 30 Oct 2003 15:30:18 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Thu, 30 Oct 2003 15:30:18 -0800 From: "Crist J. Clark" To: Nucleo de Pesquisa e Desenvolvimento Message-ID: <20031030233018.GC32640@blossom.cjclark.org> References: <1545.172.72.12.252.1067458540.squirrel@intranet.el.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1545.172.72.12.252.1067458540.squirrel@intranet.el.com.br> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-net@freebsd.org Subject: Re: IPSEC in tunnel mode ( possible? ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2003 23:30:04 -0000 On Wed, Oct 29, 2003 at 06:15:40PM -0200, Nucleo de Pesquisa e Desenvolvimento wrote: > Hi everyone, > > I know it is kind an off-topic question but maybe another network admin > have already faced the following: > > client--[__ipsec__]--gw--[__ip__]--internet > > I, trying to secure a wireless link, want to have my clients using > ipsec on the segment between the gateway gw and the machine itself even > when the traffic is to the internet and not only to the gateway ( what > works fine in transport mode anyway ). The clients are windows > machines. > Accordingly to Microsoft 252735 tunnel is possible when a windows is > acting as a gateway, not our scenario where machines are only > clients... Sometimes you read something and you just wanna pound someone so, so hard with a clue bat, "Windows 2000 IPSec tunneling is not supported for client remote access VPN use because the IETF IPSec RFCs do not currently provide a remote access solution in the Internet Key Exchange (IKE) protocol for client-to-gateway connections." First, IPsec is a peer-to-peer protocol. There are no clients and servers, only peers. Second, IKE is not part of IPsec. IKE is a nice standard for setting up IPsec SAs, but it is not required and is not the only way to set up SAs. Third, there are plenty of ways to do IKE authentication in a "cleint-to-server-like" fashion. A zillion other vendors have somehow managed to figure this out, M$. > Any one could point me to some url or send me keywords I should look > for please? If things won?t work with ipsec I?ll do it with MPD... but > I still should have ask it here. FWIW, I ended up using mpd for Windows machines this exact same scenario. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 16:34:35 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFD5416A4CE for ; Thu, 30 Oct 2003 16:34:35 -0800 (PST) Received: from stoat.clara.net (du-041-0081.access.clara.net [217.158.117.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9596643F75 for ; Thu, 30 Oct 2003 16:34:33 -0800 (PST) (envelope-from david@carter-hitchin.clara.co.uk) Received: from stoat.clara.net (localhost [127.0.0.1]) by stoat.clara.net (8.12.8p2/8.12.9) with ESMTP id h9V1YuZE000730 for ; Fri, 31 Oct 2003 01:34:57 GMT (envelope-from david@carter-hitchin.clara.co.uk) Received: from localhost (david@localhost)h9V1YtvG000727 for ; Fri, 31 Oct 2003 01:34:56 GMT (envelope-from david@carter-hitchin.clara.co.uk) X-Authentication-Warning: stoat.clara.net: david owned process doing -bs Date: Fri, 31 Oct 2003 01:34:55 +0000 (GMT) From: David Carter-Hitchin X-Sender: david@localhost To: freebsd-net@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: ppp link always dials when started with -auto? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 00:34:35 -0000 Hi All, Hoping someone really clever knows the answer here (I asked on the 'questions' mailing list and I got no response). This problem is really getting to me - I can normally solve problems on my own with some googling and reading the man pages, but this one has me beat. Briefly: 4.8-RELEASE "ppp -auto" always dials Turned off sendmail - same result Booted in single user mode - same result Read /usr/share/examples/ppp, man ppp, ppp faq, searched google. Need to know what or why the ppp link is being brought up. Original message with my config and logs below. I was running 4.9-RC and as an attempt to fix it I regressed to 4.8 (the day before 4.9 was released :-) Many thanks in advance, David ---------- Forwarded message ---------- Date: Sun, 26 Oct 2003 22:19:10 +0000 (GMT) From: David Carter-Hitchin To: freebsd-questions@freebsd.org Subject: ppp link always dials when started with -auto? Hi FreeBSD'ers, I've just upgraded to 4.9-RC (from 4.2) and I'm really happy with everything except ppp. Whenever I start ppp (with ppp -auto pmdemand) it immediately starts to dial - after connecting it briefly sends and receives a minimal amount of data then sits there idly. One other problem I've got with my upgrade is that I'm getting pam errors: Oct 26 20:26:25 stoat login: no modules loaded for `login' service Oct 26 20:26:25 stoat login: pam_open_session: Permission denied (related?) I've read the ppp faq and this question is covered and it says sendmail is the often the culprit. This rang loud bells as I saw that the more recent version of sendmail has depreciated the 'nodns' feature. So I tried rebooting without sendmail running, but still the same problem. I tried killing off a few daemons including inetd, lpd, usbd.. but no joy. I added "log All +tcp/ip" to get the full output, but I don't know enough about this stuff to go further. I initially get the following lines in the log: Oct 26 21:17:32 stoat ppp[466]: tun0: TCP/IP: OUT <0>: fe80::240:95ff:fe44:3e11 ---> ff02::1:ff44:3e11 (72) Oct 26 21:17:32 stoat ppp[466]: tun0: TCP/IP: OUT ICMP: :::135 ---> ff02::1:ff44:3e11 (16/64) I've uploaded the rest of the conversation to: http://www.carter-hitchin.clara.co.uk/logs/ppp.log.gz My setup is an isolated workstation (no LAN, occasional dialup). Here are some outputs: [516]->uname -a FreeBSD stoat.clara.net 4.9-RC FreeBSD 4.9-RC #0: Sat Oct 18 13:56:46 BST 2003 david@stoat.clara.net:/usr/obj/usr/src/sys/STOAT i386 [517]->cat /etc/ppp/ppp.conf default: #set log Phase Chat LCP IPCP CCP tun command set log All ident user-ppp VERSION (built COMPILATIONDATE) set device /dev/cuaa0 set speed 115200 set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ \"\" ATM1 OK \\dATDT\\T TIMEOUT 40 CONNECT" enable dns pmdemand: set timeout 300 # 3 mintue idle timer (the default) set phone XXXXXXXXXXXXXXX set authname XXXXX set authkey XXXXXX add default HISADDR # Add a (sticky) default route set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.255 [68]->cat /etc/resolv.conf domain=stoat nameserver 195.8.69.7 nameserver 195.8.69.12 [69]->cat /etc/hosts ::1 localhost localhost.clara.net 127.0.0.1 localhost localhost.clara.net stoat.clara.net 127.0.0.1 stoat stoat.clara.net 127.0.0.1 carter-hitchin.clara.co.uk I'd really appreciate some help here - I'm stuck in being able to identify precisely what is using the link. Many thanks, David. From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 19:14:21 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49EBB16A4CE for ; Thu, 30 Oct 2003 19:14:21 -0800 (PST) Received: from swin.edu.au (c3p0.cc.swin.edu.au [136.186.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id D681643F3F for ; Thu, 30 Oct 2003 19:14:18 -0800 (PST) (envelope-from pvandenbergen@swin.edu.au) Received: from pvdbergen.caia.swin.edu.au (pvdbergen.caia.swin.edu.au [136.186.229.26]) by swin.edu.au (8.9.3p2-20030918/8.9.3) with ESMTP id OAA907224 for ; Fri, 31 Oct 2003 14:14:16 +1100 (EST) From: paul van den bergen To: freebsd-net@freebsd.org Date: Fri, 31 Oct 2003 14:14:15 +1100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310311414.15989.pvandenbergen@swin.edu.au> Subject: IPv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 03:14:21 -0000 Hi all, I am attempting to set up some static ipv6 routes on my little network. example: box1 - fec0:0:0:1::1 -------- fec0:0:0:1::2 - box 2 (router) - fec0:0:0:2:1 -------- fec0:0:0:2:2 - box 3 I want to reach from box 1 to box 3 no route6d or anything... this is a really simple network. sysctl net.inet6.ip6.forwarding=1, net.inet6.ip6.accept_rtadv=0 on box 2 (the router) sysctl net.inet6.ip6.forwarding=0, net.inet6.ip6.accept_rtadv=1 on boxes 1 and 3 (the hosts). route add -inet6 -net fec0:0:0:2:: -prefixlen 64 -host fec0:0:0:1::2 on box1 box2 can ping6 to box1 and box3 and vise versa. why can't box 1 ping6 box 3? What have I missed? -- Dr Paul van den Bergen Centre for Advanced Internet Architectures caia.swin.edu.au pvandenbergen@swin.edu.au IM:bulwynkl2002 "And some run up hill and down dale, knapping the chucky stones to pieces wi' hammers, like so many road makers run daft. They say it is to see how the world was made." Sir Walter Scott, St. Ronan's Well 1824 From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 20:07:21 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B332816A4CE for ; Thu, 30 Oct 2003 20:07:21 -0800 (PST) Received: from web60301.mail.yahoo.com (web60301.mail.yahoo.com [216.109.118.112]) by mx1.FreeBSD.org (Postfix) with SMTP id BD12E43FE0 for ; Thu, 30 Oct 2003 20:07:20 -0800 (PST) (envelope-from dhogea@yahoo.com) Message-ID: <20031031040720.89645.qmail@web60301.mail.yahoo.com> Received: from [128.226.68.47] by web60301.mail.yahoo.com via HTTP; Thu, 30 Oct 2003 20:07:20 PST Date: Thu, 30 Oct 2003 20:07:20 -0800 (PST) From: "Dorin H." To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Recognized USB cable modem SB4200 but no go X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 04:07:21 -0000 Hi everybody, Has anybody succeeded to configure a cable modem SB4200 (4100) using the USB connection (any FreeBSD release :) ) ? Is there any chance that this USB modem will get support under FreeBSD? (there is already supported by Linux, by CDCEther module...) Any references or pointers are mostly welcomed! Thanks a lot! Regards, /Dorin. PS. The dmesg shows that the system recognize it but it associate the USB generic driver with it; I have not been able to use the ifconfig to make it work. ===== /Dorin. __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 21:20:22 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3663416A4CE for ; Thu, 30 Oct 2003 21:20:22 -0800 (PST) Received: from eth0.b.smtp.sonic.net (eth0.b.smtp.sonic.net [64.142.19.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3080943FAF for ; Thu, 30 Oct 2003 21:20:19 -0800 (PST) (envelope-from bmah@intruder.kitchenlab.org) Received: from intruder.kitchenlab.org (adsl-64-142-31-106.sonic.net [64.142.31.106])h9V5KIuf003440 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 30 Oct 2003 21:20:18 -0800 Received: from intruder.kitchenlab.org (bmah@localhost [127.0.0.1]) h9V5KI1j011235; Thu, 30 Oct 2003 21:20:18 -0800 (PST) (envelope-from bmah@intruder.kitchenlab.org) Message-Id: <200310310520.h9V5KI1j011235@intruder.kitchenlab.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: paul van den bergen In-Reply-To: <200310311414.15989.pvandenbergen@swin.edu.au> References: <200310311414.15989.pvandenbergen@swin.edu.au> Comments: In-reply-to paul van den bergen message dated "Fri, 31 Oct 2003 14:14:15 +1100." From: "Bruce A. Mah" X-Face: g~c`.{#4q0"(V*b#g[i~rXgm*w;:nMfz%_RZLma)UgGN&=j`5vXoU^@n5v4:OO)c["!w)nD/!!~e4Sj7LiT'6*wZ83454H""lb{CC%T37O!!'S$S&D}sem7I[A 2V%N&+ X-Image-Url: http://www.employees.org/~bmah/Images/bmah-cisco-small.gif X-Url: http://www.employees.org/~bmah/ Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1876958278P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 30 Oct 2003 21:20:18 -0800 Sender: bmah@intruder.kitchenlab.org cc: freebsd-net@freebsd.org Subject: Re: IPv6 routing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bmah@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 05:20:22 -0000 --==_Exmh_-1876958278P Content-Type: text/plain; charset=us-ascii If memory serves me right, paul van den bergen wrote: > I am attempting to set up some static ipv6 routes on my little network. > > example: > > box1 - fec0:0:0:1::1 -------- fec0:0:0:1::2 - box 2 (router) - fec0:0:0:2:1 > -------- fec0:0:0:2:2 - box 3 > > I want to reach from box 1 to box 3 > > no route6d or anything... this is a really simple network. > > sysctl net.inet6.ip6.forwarding=1, net.inet6.ip6.accept_rtadv=0 on box 2 (the > > router) > sysctl net.inet6.ip6.forwarding=0, net.inet6.ip6.accept_rtadv=1 on boxes 1 an > d > 3 (the hosts). > > route add -inet6 -net fec0:0:0:2:: -prefixlen 64 -host fec0:0:0:1::2 > on box1 > > box2 can ping6 to box1 and box3 and vise versa. > > why can't box 1 ping6 box 3? What have I missed? Did you add a route on box3 so that it can reach box1? Remember that ping6 requires two-way connectivity. You set net.inet6.ip6.accept_rtadv=1 on the end hosts...do you have rtadvd running on box2 so that they actually acquire the routes? You haven't really provided enough information to debug the problem. How about the output of ifconfig(8) and the routing tables on all three machines? Bruce. --==_Exmh_-1876958278P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (FreeBSD) Comment: Exmh version 2.5+ 20020506 iD8DBQE/ofER2MoxcVugUsMRAoOfAKDttXg7cRcekKngOEkM2/jYzvzqTACg16zz neMy9YXsXQ5zOw+ZJMtR5as= =2viv -----END PGP SIGNATURE----- --==_Exmh_-1876958278P-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 22:01:29 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B78116A4D0 for ; Thu, 30 Oct 2003 22:01:29 -0800 (PST) Received: from weenix.guru.org (weenix.guru.org [24.199.153.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6502543FBD for ; Thu, 30 Oct 2003 22:01:23 -0800 (PST) (envelope-from kmitch@guru.org) Received: from localhost (localhost.guru.org [127.0.0.1]) by weenix.guru.org (Postfix) with ESMTP id 1BD27ACA97 for ; Fri, 31 Oct 2003 01:01:19 -0500 (EST) Received: from weenix.guru.org ([127.0.0.1]) by localhost (weenix.guru.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91472-01 for ; Fri, 31 Oct 2003 01:01:17 -0500 (EST) Received: by weenix.guru.org (Postfix, from userid 3000) id 388C8ACA98; Fri, 31 Oct 2003 01:01:17 -0500 (EST) Date: Fri, 31 Oct 2003 01:01:17 -0500 From: Keith Mitchell To: freebsd-net@freebsd.org Message-ID: <20031031060117.GA77018@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new at guru.org Subject: iMac and FreeBSD performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 06:01:29 -0000 Hi, I'm trying to figure out why my FreeBSD box and my iMac are having trouble communicating at 100 Mbs full-duplex. To briefly describe my LAN setup, I have a 16port linksys 10/100 ethernet switch connected to two FreeBSD systems, an iMac, a PC and some other miscellaneous stuff. Everything works fine except the interaction between the iMac and the FreeBSD machines. What I see is extremely slow transfers (FTP/TFTP at least) from the FreeBSD machines to the iMac. The reverse direction (from the iMac to the FreeBSD machiens work fine). If this isn't bad enough, if I connect the iMac to a 10BT hub instead of the ethernet switch then everything seems to work fine as well. The iMac can talk to all the other equipment without a problem when its connected to the ethernet switch. Likewise the FreeBSD machines can talk to each other without any problems and to all of the other networking equipment.... they just can't talk to the iMac efficiently. I just noticed this problem but I am not sure how long it has existed since I just started having a need to transfer large chunks of dat between the iMac and the FreeBSD machines. I have tried various versions of FreeBSD all with the same affect (4.6, 4.7, 4.9, 5.1). The iMac is currently running 10.3 (which is supposedly roughly equivalent to FreeBSD 5). I also saw the samething with the 10.2 release though. The FreeBSD machines are using Dec21140 based 10/100 ethernet cards and it doesn't seem to matter if I use the GENERIC kernel or a custom kernel with all the extra stuff removed. I have also tried a different Linksys ethernet switch with the same results. I don't have another vendor to try unfortunately. Anyone have any clues on this bizarre problem? -- Keith Mitchell Email: kmitch@guru.org PGP key available upon request From owner-freebsd-net@FreeBSD.ORG Thu Oct 30 22:35:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4239B16A4CE for ; Thu, 30 Oct 2003 22:35:16 -0800 (PST) Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5086C43F93 for ; Thu, 30 Oct 2003 22:35:15 -0800 (PST) (envelope-from barney@pit.databus.com) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.9p2/8.12.9) with ESMTP id h9V6ZEp4072802; Fri, 31 Oct 2003 01:35:14 -0500 (EST) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.9p2/8.12.9/Submit) id h9V6ZENf072801; Fri, 31 Oct 2003 01:35:14 -0500 (EST) (envelope-from barney) Date: Fri, 31 Oct 2003 01:35:14 -0500 From: Barney Wolff To: Keith Mitchell Message-ID: <20031031063514.GA72686@pit.databus.com> References: <20031031060117.GA77018@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031060117.GA77018@weenix.guru.org> User-Agent: Mutt/1.4.1i X-Scanned-By: MIMEDefang 2.37 cc: freebsd-net@freebsd.org Subject: Re: iMac and FreeBSD performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 06:35:16 -0000 On Fri, Oct 31, 2003 at 01:01:17AM -0500, Keith Mitchell wrote: > > What I see is extremely slow transfers (FTP/TFTP at least) from the > FreeBSD machines to the iMac. The reverse direction (from the iMac to > the FreeBSD machiens work fine). If this isn't bad enough, if I connect > the iMac to a 10BT hub instead of the ethernet switch then everything > seems to work fine as well. The iMac can talk to all the other equipment > without a problem when its connected to the ethernet switch. Likewise > the FreeBSD machines can talk to each other without any problems and to > all of the other networking equipment.... they just can't talk to the iMac > efficiently. tcpdump is your friend. Run it in save-to-disk mode, then look at results at leisure. Run at both ends. I'd expect packet loss and retransmissions. The question is why. You can play with tuning parameters at both ends. Receive window size, MTU, (local_)slowstart_flightsize, path_mtu_discovery. MTU is settable by ifconfig, others by sysctl. Send to /dev/null to eliminate disk issues. Swap cables. Swap ports. Good luck. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 00:54:57 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FDBA16A4CE for ; Fri, 31 Oct 2003 00:54:57 -0800 (PST) Received: from stoat.clara.net (du-041-0149.access.clara.net [217.158.117.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFD0543FB1 for ; Fri, 31 Oct 2003 00:54:54 -0800 (PST) (envelope-from david@carter-hitchin.clara.co.uk) Received: from stoat.clara.net (localhost [127.0.0.1]) by stoat.clara.net (8.12.8p2/8.12.9) with ESMTP id h9V9tGZE001509 for ; Fri, 31 Oct 2003 09:55:17 GMT (envelope-from david@carter-hitchin.clara.co.uk) Received: from localhost (david@localhost)h9V9tFCf001506 for ; Fri, 31 Oct 2003 09:55:16 GMT (envelope-from david@carter-hitchin.clara.co.uk) X-Authentication-Warning: stoat.clara.net: david owned process doing -bs Date: Fri, 31 Oct 2003 09:55:14 +0000 (GMT) From: David Carter-Hitchin X-Sender: david@localhost To: freebsd-net@freebsd.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: ppp link always dials when started with -auto? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 08:54:57 -0000 Just a follow up... I forgot to mention that I also did a tcpdump on tun0 as the link comes up - it shows no packets sent or received. From my limited knowledge of ppp negotiation, it looks like the link is being brought up but nothing is being sent over it. I also did a ktrace on ppp that didn't reveal anything which would indicate why ppp is dialling upon initialisation. One other thing is that after the initial dial, if I leave ppp to timeout, then it will not dial again, unless I do something (send mail, browse the web) - I've left it for at least 24 hours. This is strong evidence that the way ppp itself is setup is causing it to dial upon initialisation - is it testing the link? Is that some option somewhere? Many thanks, David On Fri, 31 Oct 2003, David Carter-Hitchin wrote: > Hi All, > > Hoping someone really clever knows the answer here (I asked on the > 'questions' mailing list and I got no response). This problem is really > getting to me - I can normally solve problems on my own with some googling > and reading the man pages, but this one has me beat. > > Briefly: > > 4.8-RELEASE "ppp -auto" always dials > Turned off sendmail - same result > Booted in single user mode - same result > Read /usr/share/examples/ppp, man ppp, ppp faq, searched google. > > Need to know what or why the ppp link is being brought up. Original > message with my config and logs below. I was running 4.9-RC and as an > attempt to fix it I regressed to 4.8 (the day before 4.9 was released :-) > > Many thanks in advance, > David > > > > ---------- Forwarded message ---------- > Date: Sun, 26 Oct 2003 22:19:10 +0000 (GMT) > From: David Carter-Hitchin > To: freebsd-questions@freebsd.org > Subject: ppp link always dials when started with -auto? > > Hi FreeBSD'ers, > > I've just upgraded to 4.9-RC (from 4.2) and I'm really happy with > everything except ppp. > > Whenever I start ppp (with ppp -auto pmdemand) it immediately starts to > dial - after connecting it briefly sends and receives a minimal amount of > data then sits there idly. > > One other problem I've got with my upgrade is that I'm getting pam errors: > > Oct 26 20:26:25 stoat login: no modules loaded for `login' service > Oct 26 20:26:25 stoat login: pam_open_session: Permission denied > > (related?) > > I've read the ppp faq and this question is covered and it says sendmail is > the often the culprit. This rang loud bells as I saw that the more recent > version of sendmail has depreciated the 'nodns' feature. So I tried > rebooting without sendmail running, but still the same problem. I tried > killing off a few daemons including inetd, lpd, usbd.. but no joy. > > I added "log All +tcp/ip" to get the full output, but I don't know enough > about this stuff to go further. I initially get the following lines in > the log: > > Oct 26 21:17:32 stoat ppp[466]: tun0: TCP/IP: OUT > <0>: fe80::240:95ff:fe44:3e11 ---> ff02::1:ff44:3e11 (72) > > Oct 26 21:17:32 stoat ppp[466]: tun0: TCP/IP: OUT ICMP: :::135 ---> > ff02::1:ff44:3e11 (16/64) > > I've uploaded the rest of the conversation to: > > http://www.carter-hitchin.clara.co.uk/logs/ppp.log.gz > > My setup is an isolated workstation (no LAN, occasional dialup). Here are > some outputs: > > [516]->uname -a > FreeBSD stoat.clara.net 4.9-RC FreeBSD 4.9-RC #0: Sat Oct 18 13:56:46 BST > 2003 david@stoat.clara.net:/usr/obj/usr/src/sys/STOAT i386 > > [517]->cat /etc/ppp/ppp.conf > default: > #set log Phase Chat LCP IPCP CCP tun command > set log All > ident user-ppp VERSION (built COMPILATIONDATE) > set device /dev/cuaa0 > set speed 115200 > set dial "ABORT BUSY ABORT NO\\sCARRIER TIMEOUT 5 \ > \"\" ATM1 OK \\dATDT\\T TIMEOUT 40 CONNECT" > enable dns > > pmdemand: > set timeout 300 # 3 mintue idle timer (the > default) > set phone XXXXXXXXXXXXXXX > set authname XXXXX > set authkey XXXXXX > add default HISADDR # Add a (sticky) default route > set ifaddr 10.0.0.1/0 10.0.0.2/0 255.255.255.255 > > > [68]->cat /etc/resolv.conf > domain=stoat > nameserver 195.8.69.7 > nameserver 195.8.69.12 > > [69]->cat /etc/hosts > ::1 localhost localhost.clara.net > 127.0.0.1 localhost localhost.clara.net stoat.clara.net > 127.0.0.1 stoat stoat.clara.net > 127.0.0.1 carter-hitchin.clara.co.uk > > > I'd really appreciate some help here - I'm stuck in being able to > identify precisely what is using the link. > > Many thanks, > David. > > > > > From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 04:28:23 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CD7216A4CE for ; Fri, 31 Oct 2003 04:28:23 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C78343FA3 for ; Fri, 31 Oct 2003 04:28:22 -0800 (PST) (envelope-from mlists@daydreamer.dk) Received: from dpws (unknown [80.161.205.30]) by pasmtp.tele.dk (Postfix) with SMTP id DDFB71EC34D for ; Fri, 31 Oct 2003 13:28:17 +0100 (CET) Message-ID: <00fe01c39faa$837140c0$0301a8c0@dpws> From: "Dennis Pedersen" To: Date: Fri, 31 Oct 2003 13:28:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Subject: mpd reports : LCP: protocol 0x2145 was rejected X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 12:28:23 -0000 Hello, I am trying to get mpd ( Version 3.14) to work on my freebsd ( 4.7-RELEASE FreeBSD 4.7-RELEASE #1: Wed Jan 29 10:02:01 CET 2003) to work with a Servgate SG100. The Servgate needs to connect to the FreeBSD server and a pptp client and i get the error in subject. On google i found that this error has been up earlier (http://groups.google.com/groups?hl=da&lr=&ie=UTF-8&oe=UTF-8&threadm=1037910 248.914.8.camel_vbook%40ns.sol.net&rnum=2&prev=/groups%3Fhl%3Dda%26lr%3D%26i e%3DUTF-8%26oe%3DUTF-8%26q%3DLCP%253A%2Bprotocol%2B0x2145%2Bwas%2Brejected) and in the old artivle it says the other end is broken. Does the erroe 2145 always indikate the other end is broken? - is the some know things i can disable in mpd and might get it working? Regards, Dennis pptp: new -i ng0 pptp pptp set iface disable on-demand set iface enable proxy-arp set iface idle 1800 set bundle enable multilink # enable TCP-Wrapper (hosts_access(5)) to block unfriendly clients # set bundle enable tcp-wrapper # use RADIUS servers # load radius set link yes acfcomp protocomp set link no pap chap set link enable chap set link keep-alive 10 60 set link mtu 1460 set ipcp yes vjcomp set ipcp ranges 192.168.10.1/32 192.168.10.50/32 set ipcp dns 192.168.1.3 set ipcp nbns 192.168.1.4 # # The five lines below enable Microsoft Point-to-Point encryption # (MPPE) using the ng_mppc(8) netgraph node type. # set bundle enable compression set ccp yes mppc set ccp yes mpp-e40 set ccp yes mpp-e128 set ccp yes mpp-stateless [pptp] setting interface ng0 MTU to 1456 bytes [pptp] LCP: rec'd Protocol Reject #2 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #3 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected [pptp] LCP: rec'd Protocol Reject #4 link 0 (Opened) [pptp] LCP: protocol 0x2145 was rejected From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 06:04:16 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E64216A4CE; Fri, 31 Oct 2003 06:04:16 -0800 (PST) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A5EA43FCB; Fri, 31 Oct 2003 06:04:15 -0800 (PST) (envelope-from zec@tel.fer.hr) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id 68EF69B648; Fri, 31 Oct 2003 15:06:03 +0100 (CET) Received: from marko-tp.zavod.tel.fer.hr (marko-tp.zavod.tel.fer.hr [161.53.19.48]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 830749B64D; Fri, 31 Oct 2003 15:06:01 +0100 (CET) From: Marko Zec To: stable@freebsd.org, net@freebsd.org Date: Fri, 31 Oct 2003 15:04:08 +0100 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200310311504.08610.zec@tel.fer.hr> X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL autolearn=no version=2.60 X-Sanitizer: Advosys mail filter Subject: Network stack cloning / virtualization patches for 4.9-RELEASE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 14:04:16 -0000 A new snapshot of network stack cloning patchset against 4.9-RELEASE kernel can be found at the usual place: http://www.tel.fer.hr/zec/vimage/ What's new: - support for independent IP multicast routing / forwarding in each network stack / virtual image; - virtual images can now be deleted more or less reliably; - jails can be (again) created within the virtual images; - several minor bugfixes. Have fun, Marko From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 06:30:35 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6ADC216A4CE for ; Fri, 31 Oct 2003 06:30:35 -0800 (PST) Received: from math.teaser.net (math.teaser.net [213.91.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F7243F85 for ; Fri, 31 Oct 2003 06:30:34 -0800 (PST) (envelope-from e-masson@kisoft-services.com) Received: from t39bsdems.interne.kisoft-services.com (nantes.kisoft-services.com [193.56.60.243]) by math.teaser.net (Postfix) with ESMTP id 0502B6C8A3; Fri, 31 Oct 2003 15:30:33 +0100 (CET) Received: by t39bsdems.interne.kisoft-services.com (Postfix, from userid 1001) id 278CF5B99D; Fri, 31 Oct 2003 15:17:53 +0100 (CET) To: Lars Eggert From: Eric Masson In-Reply-To: <3FA02B30.90805@isi.edu> (Lars Eggert's message of "Wed, 29 Oct 2003 13:03:44 -0800") References: <8665iehd1i.fsf@t39bsdems.interne.kisoft-services.com> <3FA02B30.90805@isi.edu> X-Operating-System: FreeBSD 4.9-PRERELEASE i386 Date: Fri, 31 Oct 2003 15:17:53 +0100 Message-ID: <868yn1qyni.fsf@t39bsdems.interne.kisoft-services.com> User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Portable Code, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit cc: Mailing List FreeBSD Network Subject: Re: ipsec tunnels & packet length issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 14:30:35 -0000 >>>>> "Lars" == Lars Eggert writes: Hello Lars, Lars> See the section on PMTU discovery in draft-touch-ipsec-vpn-06. If Lars> the requirements of your setup allow is, IPIP gif tunnels Lars> together with IPsec transport mode (as described in the ID) can Lars> address this issue. The kind of setup described in your draft should adress the issue, but choice has been to use native ipsec tunnels (maybe this will change in near future). The only workaround I've found is to lower mtu on the fw1 dmz interface to 1436 (thanks to M. Sierchio) Hope your draft will be adopted. Thanks a lot Eric Masson -- B > Ah ben bravo ! a quand l'html dans les entetes ? CB> Hein ? tu lis pas l'iso-8859-1 dans le champ approved ?? Elle répond. Comment veux-tu qu'en plus elle ait le temps de lire ? -+- SJ in : Les joyeuses commères d'Usenet -+- From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 07:45:27 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27B3416A4CE; Fri, 31 Oct 2003 07:45:27 -0800 (PST) Received: from omoikane.mb.skyweb.ca (209-5-243-50.mb.skyweb.ca [209.5.243.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EFC743F3F; Fri, 31 Oct 2003 07:45:26 -0800 (PST) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id E5D2462756; Fri, 31 Oct 2003 09:45:25 -0600 (CST) Date: Fri, 31 Oct 2003 09:45:25 -0600 From: Mark Johnston To: "Crist J. Clark" Message-ID: <20031031154525.GA985@omoikane.mb.skyweb.ca> Mail-Followup-To: "Crist J. Clark" , security@freebsd.org, net@freebsd.org References: <20031030210509.GA667@omoikane.mb.skyweb.ca> <20031030224342.GA32640@blossom.cjclark.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031030224342.GA32640@blossom.cjclark.org> User-Agent: Mutt/1.4.1i cc: net@freebsd.org cc: security@freebsd.org Subject: (long) Re: Using racoon-negotiated IPSec with ipfw and natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 15:45:27 -0000 "Crist J. Clark" wrote: > On Thu, Oct 30, 2003 at 03:05:09PM -0600, Mark Johnston wrote: > > - gateway receives an ESP packet from mobile (encapsulating a ping). > > - gateway decrypts and transmits an ICMP packet to internal with mobile's > > source address. > > - internal generates the ICMP response to mobile. > > - gateway receives the response, runs it through natd, and sends it out in the > > clear to mobile with gateway's source address. > > This shouldn't happen. IPsec processing of the outgoing packet happens > _before_ it gets passed to ipfw(8) (which hands it to natd(8)) on the > external interface. That's odd. To simplify the situation a bit, I'm testing with a static SP/SA set. The SPs in place are: 172.21.0.0/16[any] 192.168.15.0/24[any] any in ipsec esp/tunnel/remoteext-localext/require spid=122 seq=1 pid=12464 refcnt=1 192.168.15.0/24[any] 172.21.0.0/16[any] any out ipsec esp/tunnel/localext-remoteext/require spid=121 seq=0 pid=12464 refcnt=1 (The external IPs are missing but the rest is unchanged.) I can break and fix the connection by adding and removing firewall rules allowing the traffic before the natd divert. > > What I want to > > accomplish, in pseudo-ipfw, is this: > > > > pass esp from any to me > > pass ip from known-sp-sources to 192.168.0.0/24 > > pass ip from 192.168.0.0/24 to known-sp-destinations > > divert natd from 192.168.0.0/24 to any > > This may be your problem. That rule should be something like, > > divert natd from 192.168.0.0/24 to any via ${external_if} > > Is that what you actually have? Are you doing NAT on the internal > interface? That would confuse things. I'm not sure what you mean by "doing NAT". The natd interface (-n) is the external one, but I'm diverting to natd using a recv rule on the internal interface. The natd setup is a bit hairy, because the box has a DMZ interface (dc0) along with external (fxp0) and internal (txp0) NICs, which is bridged (dc0-fxp0) instead of routed to match a legacy config. Here's my current ipfw setup: 00100 allow esp from any to me 00200 allow ah from any to me 00205 allow udp from any to me dst-port 500 00210 allow ip from 192.168.15.0/24 to 172.21.0.0/16 00220 allow ip from 172.21.0.0/16 to 192.168.15.0/24 [ more bidirectional allow rules ] 00300 deny ip from any to 192.168.15.0/24 in recv fxp0 00400 deny ip from any to 192.168.15.0/24 in recv dc0 00500 divert 8669 ip from 192.168.15.0/24 to not me recv txp0 00600 divert 8668 ip from any to me in recv fxp0 00700 divert 8668 ip from any to me in recv dc0 00800 allow ip from 192.168.15.0/24 to any recv txp0 00900 allow ip from any to 192.168.15.0/24 01000 check-state [ some allows and denies for fxp0<->dc0 ] 01800 allow ip from 192.168.15.0/24 to me 01900 allow ip from me to any keep-state 65535 deny ip from any to any Because of the DMZ, I had to tweak the natd setup to use -i 8668 -o 8669 - if I diverted everything to 8668 and didn't use -i and -o, it was interpreting dc0 as "inside", and I couldn't communicate with the DMZ from the LAN. With these rules in place, everything works fine, and I can ping across the IPsec link. If I delete 210 and 220, I start to see the pings on fxp0 destined to the 172.21.x.x address from my external IP. Also, sysctl.conf has some variables related to the config: net.inet.ip.fw.one_pass=0 net.link.ether.bridge_cfg=fxp0,dc0 net.link.ether.bridge=1 net.link.ether.bridge_ipfw=1 net.key.prefered_oldsa=0 Thanks for your help with this. I guess that the trouble is that I don't totally grok the ipfw/natd/ipsec tie-ins. Mark From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 07:47:28 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F56716A4CE for ; Fri, 31 Oct 2003 07:47:28 -0800 (PST) Received: from ns10.hutchtel.net (ds2.hutchtel.net [66.103.161.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EA143F93 for ; Fri, 31 Oct 2003 07:47:27 -0800 (PST) (envelope-from ant@hutchtel.net) Received: from andromeda (6400b4.hutchtel.net [66.103.161.14]) by ns10.hutchtel.net (8.12.8/) with ESMTP id h9VFlPMU1267769; Fri, 31 Oct 2003 09:47:26 -0600 (CST) From: "Anthony Anderberg" To: Keith Mitchell Date: Fri, 31 Oct 2003 09:47:33 -0600 MIME-Version: 1.0 Message-ID: <3FA22FB5.12915.82C50B0@localhost> Priority: normal In-reply-to: <20031031063514.GA72686@pit.databus.com> References: <20031031060117.GA77018@weenix.guru.org> X-mailer: Pegasus Mail for Windows (v4.12a) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body cc: freebsd-net@freebsd.org Subject: Re: iMac and FreeBSD performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ant@hutchtel.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 15:47:28 -0000 > the iMac to a 10BT hub instead of the ethernet switch then everything > seems to work fine as well. The iMac can talk to all the other equipment > without a problem when its connected to the ethernet switch. Likewise Sounds like a duplex mis-match, which is especially common with unmanaged switches. The problem is that the computer and switch don't agree whether their link is full duplex or half duplex. The result is undetected collisions which must be retransmitted via TCP timeouts instead of being retransmitted right away by the NICs. I'd suggest setting the duplex on the switch ports if possible and devices to see if a combination works better, I'm not sure about the Mac but you can get a list of media options on FreeBSD using "ifconfig -m". Best wishes, anthony From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 08:10:03 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB54C16A4CE for ; Fri, 31 Oct 2003 08:10:03 -0800 (PST) Received: from weenix.guru.org (weenix.guru.org [24.199.153.98]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3FFD43FA3 for ; Fri, 31 Oct 2003 08:10:02 -0800 (PST) (envelope-from kmitch@guru.org) Received: from localhost (localhost.guru.org [127.0.0.1]) by weenix.guru.org (Postfix) with ESMTP id D106FACA9C; Fri, 31 Oct 2003 11:10:01 -0500 (EST) Received: from weenix.guru.org ([127.0.0.1]) by localhost (weenix.guru.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00402-02; Fri, 31 Oct 2003 11:09:59 -0500 (EST) Received: from guru.org (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by weenix.guru.org (Postfix) with ESMTP id 96961ACA9B; Fri, 31 Oct 2003 11:09:58 -0500 (EST) Message-ID: <3FA28954.7000705@guru.org> Date: Fri, 31 Oct 2003 11:09:56 -0500 From: Keith Mitchell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ant@hutchtel.net References: <20031031060117.GA77018@weenix.guru.org> <3FA22FB5.12915.82C50B0@localhost> In-Reply-To: <3FA22FB5.12915.82C50B0@localhost> X-Virus-Scanned: by amavisd-new at guru.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: freebsd-net@freebsd.org Subject: Re: iMac and FreeBSD performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 16:10:04 -0000 Anthony Anderberg wrote: >>the iMac to a 10BT hub instead of the ethernet switch then everything >>seems to work fine as well. The iMac can talk to all the other equipment >>without a problem when its connected to the ethernet switch. Likewise >> >> > >Sounds like a duplex mis-match, which is especially >common with unmanaged switches. The problem >is that the computer and switch don't agree whether >their link is full duplex or half duplex. The result is >undetected collisions which must be retransmitted >via TCP timeouts instead of being retransmitted right >away by the NICs. I'd suggest setting the duplex on >the switch ports if possible and devices to see if a >combination works better, I'm not sure about the Mac >but you can get a list of media options on FreeBSD >using "ifconfig -m". > I have tried that but the switch seems retarded :-) I can't force the switch to do anything... If I force the computers to 100/half the switch leds indicate 100/full. And if I force the computer to 100/full the switch detects 100/half... argh. When I set the computers to autodetect then both the computers and the switch seem to agree on 100/full (based on the ifconfig info and the leds on the switch). And they seem to work unless I want the Mac and the freebsd machines to talk to each other. But... Something is definately wrong with the switch... Out of frustration I went out and picked up another ethernet switch from a different vendor (one of the new Nway ones that supports uplink detection too) and with that switch everything works as expected.... I had thought that I ruled out the switch since I tried two different ones with the same result (one was a 5 year old linksys 16 port switch and the other is about a year old mini 5 port linksys switch). Both were linksys switches though :-( The one I bought today that seems to work great is a netgear switch.... Hopefully its not all linksys switches since I was planning on getting one of the Linksys 8 port GE switches (I can get a really good deal on it). I guess i'll just have to try and see :-( What i'd really like would be to get a 10/100/1000 managed switch but they want way too much for them to justify one for a home network :-( Thanks. -- Keith Mitchell Email: kmitch@guru.org PGP key available upon request From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 08:27:58 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C6D1416A4CE for ; Fri, 31 Oct 2003 08:27:58 -0800 (PST) Received: from bilver.wjv.com (user38.net339.fl.sprint-hsd.net [65.40.24.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D5C743FAF for ; Fri, 31 Oct 2003 08:27:57 -0800 (PST) (envelope-from bv@bilver.wjv.com) Received: from bilver.wjv.com (localhost.wjv.com [127.0.0.1]) by bilver.wjv.com (8.12.10/8.12.9) with ESMTP id h9VGRsm2049291 for ; Fri, 31 Oct 2003 11:27:54 -0500 (EST) (envelope-from bv@bilver.wjv.com) Received: (from bv@localhost) by bilver.wjv.com (8.12.10/8.12.9/Submit) id h9VGRsxs049290 for freebsd-net@freebsd.org; Fri, 31 Oct 2003 11:27:54 -0500 (EST) (envelope-from bv) Date: Fri, 31 Oct 2003 11:27:54 -0500 From: Bill Vermillion To: freebsd-net@freebsd.org Message-ID: <20031031162754.GH46420@wjv.com> References: <20031031060117.GA77018@weenix.guru.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031060117.GA77018@weenix.guru.org> Organization: W.J.Vermillion / Orlando - Winter Park ReplyTo: bv@wjv.com User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on bilver.wjv.com Subject: Re: iMac and FreeBSD performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bv@wjv.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 16:27:59 -0000 Even though on Fri, Oct 31, 2003 at 01:01 Keith Mitchell realized that everything he says should be taken cum grano salis, he unhesitatingly continued with this missive: > I'm trying to figure out why my FreeBSD box and my iMac are having > trouble communicating at 100 Mbs full-duplex. > To briefly describe my LAN setup, I have a 16port linksys > 10/100 ethernet switch connected to two FreeBSD systems, an > iMac, a PC and some other miscellaneous stuff. Everything works > fine except the interaction between the iMac and the FreeBSD > machines. > What I see is extremely slow transfers (FTP/TFTP at least) from > the FreeBSD machines to the iMac. The reverse direction (from > the iMac to the FreeBSD machiens work fine). If this isn't bad > enough, if I connect the iMac to a 10BT hub instead of the > ethernet switch then everything seems to work fine as well. > The iMac can talk to all the other equipment without a problem > when its connected to the ethernet switch. Likewise the FreeBSD > machines can talk to each other without any problems and to all > of the other networking equipment.... they just can't talk to > the iMac efficiently. I've seen this as a client has 2 G4s and an xrack in our rack space. All machines go through a Cisco 2948, that goes through a bride on an Etinc BWManager, to a 7120, then to the facility gigabit switch. Transfers between any of the Apple machines are blazingly fast. >From the FBSD machines in the rack to anywhere else speed is fast. But between the BSD and the Apples speed drops to the 10KB ranage at times. >From the outside world the transfers from the BSD machines are limited only by connectivity and I got 6Mb/sec transfers from some SW at AT&T to the local machines recently - as we are on a Level 3 backbone and it's fast. I've also heard via a 3rd party that a person we are associated with at Omneon Video Technologies [omneon.com] that they had the problem there. They reportedly got a patch from Apple on this, but this appears to be something which is not distributed. Last week I was at an SACD listening party given by an engineer friend of mine and they were all engineers, musicians, producers, etc., and all used Macs and ProTools. A well known CD mastering engineer asked me if I knew why is Mac to XP transfers were so slow. So this a problem - not widespread - and not occuring everywhere. It's just some machines at some times. Just throwing this out as it appears not be isolated but not a big enough problem that Apple addressed in a general patch/fix - IF what I was told that what Omneon experienced is true. > Anyone have any clues on this bizarre problem? No. But I'm going to see if I can trace down what I have heard, that may only be rumors. Bill -- Bill Vermillion - bv @ wjv . com From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 11:13:38 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC8C16A4CE; Fri, 31 Oct 2003 11:13:38 -0800 (PST) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8F3E43FA3; Fri, 31 Oct 2003 11:13:37 -0800 (PST) (envelope-from cristjc@comcast.net) Received: from blossom.cjclark.org (12-234-156-182.client.attbi.com[12.234.156.182]) by comcast.net (rwcrmhc11) with ESMTP id <2003103119133701300pcp02e>; Fri, 31 Oct 2003 19:13:37 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.9p2/8.12.8) with ESMTP id h9VJDusb067212; Fri, 31 Oct 2003 11:13:56 -0800 (PST) (envelope-from cristjc@comcast.net) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.9p2/8.12.9/Submit) id h9VJDtam067211; Fri, 31 Oct 2003 11:13:55 -0800 (PST) (envelope-from cristjc@comcast.net) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to cristjc@comcast.net using -f Date: Fri, 31 Oct 2003 11:13:55 -0800 From: "Crist J. Clark" To: security@freebsd.org, net@freebsd.org Message-ID: <20031031191355.GA67124@blossom.cjclark.org> References: <20031030210509.GA667@omoikane.mb.skyweb.ca> <20031030224342.GA32640@blossom.cjclark.org> <20031031154525.GA985@omoikane.mb.skyweb.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031031154525.GA985@omoikane.mb.skyweb.ca> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ Subject: Re: (long) Re: Using racoon-negotiated IPSec with ipfw and natd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cjclark@alum.mit.edu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2003 19:13:39 -0000 On Fri, Oct 31, 2003 at 09:45:25AM -0600, Mark Johnston wrote: > "Crist J. Clark" wrote: > > On Thu, Oct 30, 2003 at 03:05:09PM -0600, Mark Johnston wrote: > > > - gateway receives an ESP packet from mobile (encapsulating a ping). > > > - gateway decrypts and transmits an ICMP packet to internal with mobile's > > > source address. > > > - internal generates the ICMP response to mobile. > > > - gateway receives the response, runs it through natd, and sends it out in the > > > clear to mobile with gateway's source address. > > > > This shouldn't happen. IPsec processing of the outgoing packet happens > > _before_ it gets passed to ipfw(8) (which hands it to natd(8)) on the > > external interface. > > That's odd. To simplify the situation a bit, I'm testing with a static > SP/SA set. The SPs in place are: > > 172.21.0.0/16[any] 192.168.15.0/24[any] any > in ipsec > esp/tunnel/remoteext-localext/require > spid=122 seq=1 pid=12464 > refcnt=1 > 192.168.15.0/24[any] 172.21.0.0/16[any] any > out ipsec > esp/tunnel/localext-remoteext/require > spid=121 seq=0 pid=12464 > refcnt=1 > > (The external IPs are missing but the rest is unchanged.) > > I can break and fix the connection by adding and removing firewall rules > allowing the traffic before the natd divert. > > > > What I want to > > > accomplish, in pseudo-ipfw, is this: > > > > > > pass esp from any to me > > > pass ip from known-sp-sources to 192.168.0.0/24 > > > pass ip from 192.168.0.0/24 to known-sp-destinations > > > divert natd from 192.168.0.0/24 to any > > > > This may be your problem. That rule should be something like, > > > > divert natd from 192.168.0.0/24 to any via ${external_if} > > > > Is that what you actually have? Are you doing NAT on the internal > > interface? That would confuse things. > > I'm not sure what you mean by "doing NAT". The natd interface (-n) is the > external one, but I'm diverting to natd using a recv rule on the internal > interface. Yep, that's the problem. When I ask where you are "doing NAT" I'm saying on which interface the ipfw(8) rules pass packets to natd(8). You're doing NAT all over the place. That's definately what is causing the problem here. For packets entering the system from the network, the processing order is, (network) ---> ipfw ---> IPsec ---> (remainder of IP stack) And outgoing, (system) ---> IPsec ---> ipfw ---> (network) (It's actually a bit more hairy that that, incoming IPsec processed packets actually get reinjected into the stack below ipfw processing, but skip ipfw on the second pass, unless IPSEC_FILTERGIF is set.) Notice I didn't explicitly say where natd(8) happens because ipfw(8) passes packets to natd(8) and that is completely under your control. The problem is that the addresses on the packets has been rewritten before they are being set out the external interface where IPsec processing would happen. > The natd setup is a bit hairy, because the box has a DMZ > interface (dc0) along with external (fxp0) and internal (txp0) NICs, which > is bridged (dc0-fxp0) instead of routed to match a legacy config. Here's > my current ipfw setup: > > 00100 allow esp from any to me > 00200 allow ah from any to me > 00205 allow udp from any to me dst-port 500 > 00210 allow ip from 192.168.15.0/24 to 172.21.0.0/16 > 00220 allow ip from 172.21.0.0/16 to 192.168.15.0/24 > [ more bidirectional allow rules ] > 00300 deny ip from any to 192.168.15.0/24 in recv fxp0 > 00400 deny ip from any to 192.168.15.0/24 in recv dc0 > 00500 divert 8669 ip from 192.168.15.0/24 to not me recv txp0 > 00600 divert 8668 ip from any to me in recv fxp0 > 00700 divert 8668 ip from any to me in recv dc0 > 00800 allow ip from 192.168.15.0/24 to any recv txp0 > 00900 allow ip from any to 192.168.15.0/24 > 01000 check-state > [ some allows and denies for fxp0<->dc0 ] > 01800 allow ip from 192.168.15.0/24 to me > 01900 allow ip from me to any keep-state > 65535 deny ip from any to any > > Because of the DMZ, I had to tweak the natd setup to use -i 8668 -o 8669 > - if I diverted everything to 8668 and didn't use -i and -o, it was > interpreting dc0 as "inside", and I couldn't communicate with the DMZ from > the LAN. Ouch. Mixing bridging, NAT, and IPsec. (I should talk, my bastion host at home has one interface with my coax cable connection, another to my NATed LAN, another to my NATed WLAN which also is all tunneled through IPsec or PPTP since WEP is broken, and finally some PPP dial-up interfaces to call into the office. No bridging there, though! Only bridge on test boxes on the internal LAN.) I don't understand is what breaks if you just do, 500 divert natd ip from 192.168.15.0/24 to any out via fxp0 600 divert natd ip from any to me in via fxp0 And lose 700. Is there a reason to NAT stuff between the internal network and DMZ? > With these rules in place, everything works fine, and I can ping across > the IPsec link. If I delete 210 and 220, I start to see the pings on fxp0 > destined to the 172.21.x.x address from my external IP. Exactly, with those rules, you never hit the 'divert' rules on the internal interface. The packets get processed with their original IP addresses as they go out fxp0, the IPsec policy is applied, and all works well. Without those rules, they hit the divert rule as they come in the internal interface, get the source address rewritten, and then do not match the IPsec policy when they get processed on the way out fxp0. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 20:25:00 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91B6E16A4CE for ; Fri, 31 Oct 2003 20:25:00 -0800 (PST) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 943EB43F75 for ; Fri, 31 Oct 2003 20:24:59 -0800 (PST) (envelope-from silby@silby.com) Received: (qmail 1377 invoked from network); 1 Nov 2003 04:24:58 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 1 Nov 2003 04:24:58 -0000 X-pair-Authenticated: 209.68.2.70 Date: Fri, 31 Oct 2003 22:24:56 -0600 (CST) From: Mike Silbersack To: Bruce M Simpson In-Reply-To: <20031028131329.J19707@odysseus.silby.com> Message-ID: <20031031222225.E54781@odysseus.silby.com> References: <20031027014854.K2023@odysseus.silby.com> <20031028131329.J19707@odysseus.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Changes to PCBPORTHASH wrt TCP, review needed X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 04:25:00 -0000 On Tue, 28 Oct 2003, Mike Silbersack wrote: > It's very possible that bind will return a port which can't be used > because it's already in use for that destination lport-laddr-fport-faddr > tuple, so the connect will fail with EADDRINUSE. > > So, it looks like I can't solve this so simply... looks like I'll have to > have the port lookup do IP comparisons as well. > > Mike "Silby" Silbersack After more thought, I've come to the conclusion that it's not easy to do away with the lport hash, and that changes would only benefit certain applications. So, I've given up on the lport reuse issue and refocused on the problem of time_wait sockets clogging up all local ports under certain situations. I did manage to find a good solution for that problem, and it'll be committed pretty soon. Mike "Silby" Silbersack From owner-freebsd-net@FreeBSD.ORG Fri Oct 31 20:54:07 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CABE16A4CE for ; Fri, 31 Oct 2003 20:54:07 -0800 (PST) Received: from segfault.monkeys.com (segfault.monkeys.com [66.60.159.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7018943F3F for ; Fri, 31 Oct 2003 20:54:06 -0800 (PST) (envelope-from rfg@monkeys.com) Received: from monkeys.com (unknown [127.0.0.1]) by segfault.monkeys.com (Postfix) with ESMTP id 45D3841F5A for ; Fri, 31 Oct 2003 20:54:06 -0800 (PST) To: freebsd-net@freebsd.org Date: Fri, 31 Oct 2003 20:54:06 -0800 Message-ID: <22763.1067662446@monkeys.com> From: "Ronald F. Guilmette" Subject: Help wanted on port scanner X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2003 04:54:07 -0000 Greetings all, I've got a port scanner that I built with my own two little hands. It is built on top of libpcap and also libnet. It works just fine, some of the time. It's what it does the rest of the time that bothers me. This is a simple-minded sort of port scanner that performs essentially the same function as nmap with the -sS option (SYN scan mode). But it doesn't really work all that well and I'm hoping that somebody on this list will be able to give me a hint. In a nutshell, the thing uses a function in libnet to manufacture a TCP SYN packet. Once the packet has been manufactured, I use the `libnet_write_ip' function to send it on its way to the scan target. Prior to any sends however, I fork off a separate process that uses libpcap just to listen for SYN+ACK response packets. This all works fairly well, except that it ONLY seems to work when I insert a delay via: usleep(1); after each packet sent. Otherwise, when I do not have the inter-packet delay in the program, a full port scan of any given target seems to finish almost instaneously, but then -zero- ports show up as "open" on the target. This is extremely perplexing to me. It seems as if the underlying sendto() call being used within the implementation of `libnet_write_ip' is failing to block in cases where the packet to be sent cannot either be immediately sent or else buffered in kernel memory. Obviously if sendto() is known to never block when called for a RAW socket, then that could explain what I am seeing... i.e. the extra inter-packet delays that I artifically inserted (with `usleep') are allowing the OS and the underlying hardware to ``catch up'' with my rate of packet sending. So now, my questions: #1) Is sendto() known to never block on RAW sockets? If so, how come I haven't ever seen it say that anywhere on any of the numerous and sundry man pages I have been looking at? #2) If sendto() does not block when writing to RAW sockets, then is there any other way for me to match the rate at which my little program calls sendto() to the actual rate that packets can be sent out of my ethernet card? (I would prefer it if packets didn't just get discarded willy-nilly, as that makes the results of the port scan dramatically less complete.) #3) I read that there is another way of sending out packets, i.e. just simply writing them to the fd of the device file that is opened in some call to `pcap_open_live'. Would this be a better way to send packets out of my port scanner, i.e. better than trying to use the kernel's apparently unreliable `sendto' function to send them? Oh yea, and by the way, for whatever it's worth, the main platform for my scanner is FreeBSD (only up to 4.7 at the moment - will upgrade soon), but I _really_ do need to have the scanner work on Solaris also. Any help would be appreciated. Regards, rfg P.S. One idea that occured to me was that maybe I should use libpcap to _listen_ for my own outgoing packets, and then only send the next one when/if the last one has actually gotten sent out the interface. Is this a totally brilliant idea or (as I suspect) a totally dumb idea? P.P.S. If you write to me off-list and if your message bounces, please don't feel insulted, and please DO use the contact form on my web site (www.monkeys.com) instead. (I have about half of the planet filtered out at the moment. Damn spammers!) I'm subscribed to freebsd-net now, so really the simplest thing would just be to reply on-list if you have any help or hints for me.