Re: ipsec tunnels & packet length issues

[Eric Masson]

> "Michael" == Michael Sierchio <[EMAIL PROTECTED]> 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 -+-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Forward: HEADS UP! Default value of ip6_v6only changed

[Hajimu UMEMOTO]

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?

--- Begin Message ---
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
[EMAIL PROTECTED]  [EMAIL PROTECTED]  [EMAIL PROTECTED],jp.}FreeBSD.org
http://www.imasy.org/~ume/
--- End Message ---
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Forward: HEADS UP! Default value of ip6_v6only changed

[Jeff W. Boote]

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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Changes to PCBPORTHASH wrt TCP, review needed

[Mike Silbersack]

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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Changes to PCBPORTHASH wrt TCP, review needed

[Bruce M Simpson]

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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: em(4) and multicast

[Christian Weisgerber]

Christian Weisgerber <[EMAIL PROTECTED]> 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  [EMAIL PROTECTED]

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

mpd, ADSL and pptp

[jhall]

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
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: mpd, ADSL and pptp

[Damian Gerow]

Thus spake [EMAIL PROTECTED] ([EMAIL PROTECTED]) [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':


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"