Re: racoon behaviour when SA expires
Alex wrote: Hi Chris, SA in IPsec can expire really quick, it depends how often it is required for SPD key negotiation. Once SPD is established, the SA will be required only when a new tunnel key is needed. Try to put a really low delay on both SAD & SPD and turn racoon debug on to see why your SA is not renegotiated. A bit more investigation reveals that the SA is re-established but the SPD entries at the remote get dropped. This would explain the half duplex communication I am seeing with tcpdump (ping repsonses get back as far as the remote racoon machine and the lack of SPD means the machine can't route the packet back through the tunnel). I have tried applying the suggested fix in fbsd4/530, which seems to be a similar problem, but this doesn't make any difference, unfortunately. Turning on debug messages seems to alter timings sufficiently that problems are harder to reproduce exactly and/or slightly different problems are encountered. Looks like I'm going to have to have a more detailed look at the source ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: dummynet and vr(4)/egress broken in 4.11 ?
Are you using ipnat for NAT'ing? If yes, can you post your ipnat rules? Nick -Original Message- From: Jeremie Le Hen [mailto:[EMAIL PROTECTED] Sent: Sunday, January 30, 2005 5:40 PM To: freebsd-net@freebsd.org Subject: Re: dummynet and vr(4)/egress broken in 4.11 ? > I didn't changed my kernel configuration file so much since my last > kernel upgrade, I juste added gif(4), IPSEC_FILTERGIF and vr(4). > I tested using this rule on ingress and egress of both my internal (sis0) > and external interface (vr0) - inverting IPs where needed :-) - here are > the results : > >| ingress | egress | > ---+-+-+ > vr0 (ext) | OK|-| > ---+-+-+ > sis0 (int) | OK| OK| > ---+-+-+ > > I think that it is now very important to tell you that while upgrading > my box to FreeBSD 4.11, I also changed my external interface from a 10 > MBits ep(4) to a 100 MBits vr(4). > > I cannot switch back to ep(4) for the moment since it is not an option > to have downtime, but according to the privous results, I'm pretty > convinced there is a problem with the vr(4) driver (although I don't > know how it can impact DUMMYNET). Maybe the last commit on this > driver in RELENG_4 (sys/pci/if_vr.c, rev 1.26.2.14) is the culprit. Well, in fact I made further investigation : - Only TCP seems to be affected. UDP and ICMP appear to work without packet drop. - Switching back from my vr(4) to my ep(4) did not resolve the problem. Thus, it seems this problem is independant from the network driver (which makes more sense because AFAIK the latters are not involved in DUMMYNET, as they are in ALTQ for example). I can still use pipes on interface ingress, internal interface egress, but it fails when I use a pipe on egress on my external interface _for packet being forwarded and NATed only_. Weirdly I am still able to use a TCP stream from the router itself. I'll give a try to a 4.10 kernel ASAP. Regards, -- Jeremie Le Hen [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Two NIC's connected to same subnet: routing question
Dear folks, I think I got confused with the routing problem we will have when at least two NIC's are connected into the same subnet. The scenario: em0: 192.168.0.1/24 em1: 192.168.0.2/24 We can't simply configure like this, since 192.168.0.0/24 network route exists as soon as either em0 or em1 is up. A workaround for this is that we assign 192.168.0.2/32 for em1, but that has another issue that all traffics will go through em0 for "outgoing", say, outside the current network. A google of the issue has indicated that the "Move ARP out of routing table" work done last April should have resolved this, as "With this change it is possible to have more than one interface in the same IP subnet and layer 2 broadcast domain.". However, what I have found from our mailing list archive says only to assign /32 IP address, or remove routing item from route table, which is essentially identical to the /32 solution. So is there any way to utilize the both NIC's? I think I have been confused :-( Cheers, -- Xin LI http://www.delphij.net/ signature.asc Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?=
RE: Two NIC's connected to same subnet: routing question
You can configure both NIC as /32. You also need proxy arp installed and listen on both NIC. Then the traffic should be able to follow between two NICs. Since Proxy ARP always answers its MAC to clients, so the clients can always send traffic to em1 or em0. Based on client's mac entry in the ARP table, client to client traffic is easily transferred. Other traffic should be able to direct to default gateway. If you know other options, I am interested to hear. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Xin LI Sent: Tuesday, February 01, 2005 10:12 AM To: freebsd-net@freebsd.org Subject: Two NIC's connected to same subnet: routing question Dear folks, I think I got confused with the routing problem we will have when at least two NIC's are connected into the same subnet. The scenario: em0: 192.168.0.1/24 em1: 192.168.0.2/24 We can't simply configure like this, since 192.168.0.0/24 network route exists as soon as either em0 or em1 is up. A workaround for this is that we assign 192.168.0.2/32 for em1, but that has another issue that all traffics will go through em0 for "outgoing", say, outside the current network. A google of the issue has indicated that the "Move ARP out of routing table" work done last April should have resolved this, as "With this change it is possible to have more than one interface in the same IP subnet and layer 2 broadcast domain.". However, what I have found from our mailing list archive says only to assign /32 IP address, or remove routing item from route table, which is essentially identical to the /32 solution. So is there any way to utilize the both NIC's? I think I have been confused :-( Cheers, -- Xin LI http://www.delphij.net/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
multihome routing help
BSD 5.0 3 Nic cards. Card 1 connects to DSL network and assigned route able IP from the ISP Card 2 connects to a private frame-relay network and is assigned 192.168.66.2/22 directly connected interface is 192.168.66.1/22 Card 3 connects lan is assigned 192.168.67.0/24 I have enabled Nat & ipfw on card1 and clients on Lan can use the DSL connection perfectly. I can source traceroute the directly connected 192.168.66.1 sourcing 192.168.66.2 interface. I cannot source traceroute to 192.168.66.1 when sourcing from 192.168.67.1. Based on this it does not appear that forwarding is happening between the two networks, 192.168.66.0/24 & 192.168.67.0/24 ? Seems the only reason that the traffic is passing through is because of the Natd & ipfw divert statments... Can this be done with routing or do I have to use ipfw to forward between both networks? I would prefer just to run the nat & ipfw instance on the DSL interface and run pure routing between the lan interface & the interface which connects to the frame-relay network.. thnx in advance ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
gigabit nic recommendations
What is a good Gb nic for these criterion : * FBSD 4.11 now, 5.X later * prefer 64 bit, 32 bit slots all full. Is there any other advantage to 64 bit? e.g. speed? system load? * I would like not to spend a king's ransom :) * RJ-45 (Cisco 29XX w/ RJ-45 GBIC) If it helps, this is the motherboard : http://www.tyan.com/products/html/tigermpx.html TIA ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: racoon behaviour when SA expires
On Tue, Feb 01, 2005 at 02:19:22PM +, Chris Cowen wrote: > Alex wrote: > >Hi Chris, > > > >SA in IPsec can expire really quick, it depends how often it is required > >for SPD key negotiation. Once SPD is established, the SA will be > >required only when a new tunnel key is needed. Try to put a really low > >delay on both SAD & SPD and turn racoon debug on to see why your SA is > >not renegotiated. > > > > A bit more investigation reveals that the SA is re-established but the > SPD entries at the remote get dropped. This would explain the half duplex > communication I am seeing with tcpdump (ping repsonses get back as far > as the remote racoon machine and the lack of SPD means the machine can't > route the packet back through the tunnel). IIRC, the problem occurs when racoon(8) is set to "create policy" on the fly. What happens is that when the SA gets stale, but before it expires, racoon(8) creates a new SA. But since there is an existing entry in the SPD, a new one is cannot made. When the old SA times out, the its accompanying SPD entry is killed, leaving no SPD entry at all. -- Crist J. Clark | [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
NAT-T Implementation
Now that NAT-T has moved on from Internet Draft to RFC, does anyone out there know if anyone is working on an implementation for FAST_IPSEC or KAME? I believe the isakmpd(8) daemon in ports supports it, but AFAIK, the kernel does not. Short of some really ugly divert(4) or netgraph(4) kludges (that is not a totally idle threat either), are we going to see in-kernel support for that anytime soon? Or is this code out there and I just haven't seen it? -- Crist J. Clark | [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
