Current problem reports assigned to you
Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description --- o [2006/01/30] kern/92552 net A serious bug in most network drivers fro f [2006/02/12] kern/93220 net [inet6] nd6_lookup: failed to add route f 2 problems total. Non-critical problems S Submitted Tracker Resp. Description --- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit o [2006/04/03] kern/95267 net packet drops periodically appear 2 problems total. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPSEC Interop problem with Cisco using multiple SA's
I am having a problem establishing peering between my FreeBSD 6.0
gateway and a Cisco device, using IPSEC. The peering works fine if
there is only one subnet behind the remote gateway, but it fails when
there is more than one subnet. I believe the FreeBSD side is failing
to be as strict with the Security Associations being negotiated.
More details below:
Basic info:
Gateway 1: Cisco 7200VXR
IP: 1.2.3.4
Subnets:10.11.11.0/24
10.22.22.0/24
Gateway 2: FreeBSD 6.0-RELEASE
IP: 4.3.2.1
Subnet: 10.99.99.0/24
Cisco config:
interface GigabitEthernet0/1
ip address 1.2.3.4 255.255.255.0
crypto map IPSEC
crypto map IPSEC local-address GigabitEthernet0/1
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 86000
crypto isakmp key address 4.3.2.1
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
crypto map IPSEC 1 ipsec-isakmp
set peer 4.3.2.1
set transform-set 3DES-MD5
match address remote-lan
ip access-list extended remote-lan
permit ip 10.11.11.0 0.0.0.255 10.99.99.0 0.0.0.255
permit ip 10.22.22.0 0.0.0.255 10.99.99.0 0.0.0.255
ipsec.conf:
spdadd 10.11.11.0/24 10.99.99.0/24 any -P in ipsec \
esp/tunnel/1.2.3.4-4.3.2.1/require;
spdadd 10.22.22.0/24 10.99.99.0/24 any -P in ipsec \
esp/tunnel/1.2.3.4-4.3.2.1/require;
spdadd 10.99.99.0/24 10.11.11.0/24 any -P out ipsec \
esp/tunnel/4.3.2.1-1.2.3.4/require;
spdadd 10.99.99.0/24 10.22.22.0/24 any -P out ipsec \
esp/tunnel/4.3.2.1-1.2.3.4/require;
racoon.conf:
path pre_shared_key "/usr/local/etc/ipsec.keys";
listen
{
isakmp 4.3.2.1;
}
remote 1.2.3.4
{
exchange_mode aggressive,main,base;
my_identifier address 4.3.2.1;
peers_identifier address 1.2.3.4;
verify_identifier off;
proposal_check claim;
proposal
{
encryption_algorithm3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group2;
lifetimetime24 hours;
}
}
sainfo address 10.11.11.0/24 any address 10.99.99.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
sainfo address 10.22.22.0/24 any address 10.99.99.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
sainfo address 10.99.99.0/24 any address 10.11.11.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
sainfo address 10.99.99.0/24 any address 10.22.22.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
ipsec.keys:
1.2.3.4
I believe my configuration is sound, even though it may not match some
of the recipes found on the net.
First test: Inbound traffic
A remote system (10.11.11.88) pings a system (10.99.99.11) behind my
gateway. The result is success. Here is the resulting SA on the Cisco
side:
# show crypto ipsec sa peer 4.3.2.1
interface: GigabitEthernet0/1
Crypto map tag: IPSEC, local addr. 1.2.3.4
protected vrf:
local ident (addr/mask/prot/port): (10.11.11.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.99.99.0/255.255.255.0/0/0)
current_peer: 4.3.2.1:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 173, #pkts encrypt: 173, #pkts digest 173
#pkts decaps: 839, #pkts decrypt: 839, #pkts verify 839
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 101, #recv errors 636
local crypto endpt.: 1.2.3.4, remote crypto endpt.: 4.3.2.1
path mtu 1500, media mtu 1500
current outbound spi: EA6BAC9
inbound esp sas:
spi: 0x307C7433(813462579)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8531, flow_id: 8169, crypto map: IPSEC
sa timing: remaining key lifetime (k/sec): (4445960/3275)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xEA6BAC9(245807817)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 8532, flow_id: 8170, crypto map: IPSEC
sa timing: remaining
Re: Packet loss with traffic shaper and routing
Interesting. I'll try to take a look when I have some free time and then post some comments. Thanks. John-Mark Gurney wrote: [EMAIL PROTECTED] wrote this message on Wed, May 03, 2006 at 22:40 -0300: Anyway, I am very curious about the result of test 2. Why do the pipes have influence on system performance if there is nothing passing through them? It looks like each tick all the pipes are scanned... In dummynet: /* Sweep pipes trying to expire idle flow_queues. */ for (i = 0; i < HASHSIZE; i++) SLIST_FOREACH(pipe, &pipehash[i], next) That bit of code should probably be run less often... ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Packet loss with traffic shaper and routing
I guess traffic stops if you have pipe rules.
In test 1, I did:
${fwcmd} pipe 1 config bw 512Kbit/s
${fwcmd} pipe 2 config bw 512Kbit/s
${fwcmd} add _allow_ all from any to any MAC any 00:11:22:33:44:55 in
${fwcmd} add _allow_ all from any to any MAC 00:11:22:33:44:55 any out
x 1600 times.
That caused lots of interrupts. Traffic was flowing although no shaping
was done.
Then, in test 2, with the same rules above, I just flushed the pipes:
ipfw pipe flush
The traffic was there, and the result is what I said in last post...
"."@babolo.ru wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
Very good. You're right!
I inserted a rule to match all non-layer2 packets on the top of the
ruleset and interrupts dropped 10~20% immediately.
Given that, I went to apply Julian's idea of grouping 'in' and 'out'
pipe rules to reduce the searching on the firewall and that gave me a
little bit more of performance.
As interrupts were still hitting 60% mark, I did some more experiences:
Test 1: I changed all 'pipe' rules to 'allow' rules, so all packets were
allowed and no shaping was done. The pipes were still there, but there
were no rules pointing packets to them.
Result: No difference. Interrupts are the same as before.
Conclusion: It's not the shaping itself that slows the system.
Test 2: With the same ruleset of test 1, I just removed all pipes (ipfw
pipe flush).
As far as I understand traffic stops after pipe flush,
and this is reason for CPU goes down
Result: Interrupts were only 20%!
Conclusion: Lots of pipes bother the system. I didn't figure out why,
but it's not a coincidence. I tested several times to make sure.
[...]
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPSEC Interop problem with Cisco using multiple SA's
I haven't tried this myself, but you may want to try using
"unique:" instead of "require" as the policy level, with
set to a unique policy identifier, which is an integer you
can pick between 1 and 32767 inclusive, for each security policy. This
makes the security policy "claim" the security associations whose
generation it triggers, by marking the SAs with its integer identifier
so that they are not used for any other security policy. I guess Cisco
does this automatically; FreeBSD/KAME does not.
Cheers,
Eugene
David DeSimone wrote:
I am having a problem establishing peering between my FreeBSD 6.0
gateway and a Cisco device, using IPSEC. The peering works fine if
there is only one subnet behind the remote gateway, but it fails when
there is more than one subnet. I believe the FreeBSD side is failing
to be as strict with the Security Associations being negotiated.
More details below:
Basic info:
Gateway 1: Cisco 7200VXR
IP: 1.2.3.4
Subnets:10.11.11.0/24
10.22.22.0/24
Gateway 2: FreeBSD 6.0-RELEASE
IP: 4.3.2.1
Subnet: 10.99.99.0/24
Cisco config:
interface GigabitEthernet0/1
ip address 1.2.3.4 255.255.255.0
crypto map IPSEC
crypto map IPSEC local-address GigabitEthernet0/1
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
lifetime 86000
crypto isakmp key address 4.3.2.1
crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac
crypto map IPSEC 1 ipsec-isakmp
set peer 4.3.2.1
set transform-set 3DES-MD5
match address remote-lan
ip access-list extended remote-lan
permit ip 10.11.11.0 0.0.0.255 10.99.99.0 0.0.0.255
permit ip 10.22.22.0 0.0.0.255 10.99.99.0 0.0.0.255
ipsec.conf:
spdadd 10.11.11.0/24 10.99.99.0/24 any -P in ipsec \
esp/tunnel/1.2.3.4-4.3.2.1/require;
spdadd 10.22.22.0/24 10.99.99.0/24 any -P in ipsec \
esp/tunnel/1.2.3.4-4.3.2.1/require;
spdadd 10.99.99.0/24 10.11.11.0/24 any -P out ipsec \
esp/tunnel/4.3.2.1-1.2.3.4/require;
spdadd 10.99.99.0/24 10.22.22.0/24 any -P out ipsec \
esp/tunnel/4.3.2.1-1.2.3.4/require;
racoon.conf:
path pre_shared_key "/usr/local/etc/ipsec.keys";
listen
{
isakmp 4.3.2.1;
}
remote 1.2.3.4
{
exchange_mode aggressive,main,base;
my_identifier address 4.3.2.1;
peers_identifier address 1.2.3.4;
verify_identifier off;
proposal_check claim;
proposal
{
encryption_algorithm3des;
hash_algorithm md5;
authentication_method pre_shared_key;
dh_group2;
lifetimetime24 hours;
}
}
sainfo address 10.11.11.0/24 any address 10.99.99.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
sainfo address 10.22.22.0/24 any address 10.99.99.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
sainfo address 10.99.99.0/24 any address 10.11.11.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
sainfo address 10.99.99.0/24 any address 10.22.22.0/24 any
{
lifetimetime1 hour;
encryption_algorithm3des;
authentication_algorithmhmac_md5;
compression_algorithm deflate;
}
ipsec.keys:
1.2.3.4
I believe my configuration is sound, even though it may not match some
of the recipes found on the net.
First test: Inbound traffic
A remote system (10.11.11.88) pings a system (10.99.99.11) behind my
gateway. The result is success. Here is the resulting SA on the Cisco
side:
# show crypto ipsec sa peer 4.3.2.1
interface: GigabitEthernet0/1
Crypto map tag: IPSEC, local addr. 1.2.3.4
protected vrf:
local ident (addr/mask/prot/port): (10.11.11.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.99.99.0/255.255.255.0/0/0)
current_peer: 4.3.2.1:500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 173, #pkts encrypt: 173, #pkts digest 173
#pkts decaps: 839, #pkts decrypt: 839, #pkts verify 839
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 101, #recv errors 636
local crypto endpt.: 1.2.3.4, remote crypto endpt.: 4.3.2.1
path mtu 1500, media mtu 1500
current outbound spi: EA6BAC9
inbound esp sas:
spi: 0x307C7433(8
Re: IPSEC Interop problem with Cisco using multiple SA's
Eugene M. Kim <[EMAIL PROTECTED]> wrote: > > I haven't tried this myself, but you may want to try using > "unique:" instead of "require" as the policy level After reading up on this behavior, I gave it a try, replacing all "require" policies with "unique". I found that there was no need to set a policy identifier, as the system apparently chooses a random identifier if none is specified, and so all SPD's create unique SAD's as a result. The result leads to exactly the behavior that I (and Cisco) expect to see, and my mutiple tunnels are now fully operational. Thank you for the help with this! -- David DeSimone == Network Admin == [EMAIL PROTECTED] "It took me fifteen years to discover that I had no talent for writing, but I couldn't give it up because by that time I was too famous. -- Robert Benchley ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vrf support in FreeBSD
Hi Folks, I am curious to know if there is any plans to support multiple routing tables in FreeBSD's official release? There was some discussion on this topic last year, if there is any vrf patch for a latest release of FreeBSD, I would love to give it a try. Any help greatly appreciated. Thanks, Pramod ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vrf support in FreeBSD
Pramod Srinivasan wrote: Hi Folks, I am curious to know if there is any plans to support multiple routing tables in FreeBSD's official release? There was some discussion on this topic last year, if there is any vrf patch for a latest release of FreeBSD, I would love to give it a try. I am doing some small bits of work on this.. how do you want to select which table should be used? (This is more of a 'survey' as I am trying to work out what I should support) Any help greatly appreciated. Thanks, Pramod ___ 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]"
Re: vrf support in FreeBSD
JE> Date: Mon, 08 May 2006 21:54:18 -0700 JE> From: Julian Elischer JE> how do you want to select which table should be used? Ingress interface. Consider: 802.3ad, ECMP, FIB, multi RIBs (e.g., OSPF vs BGP weight), VRF I started working on all of the above late in 2003 on 4.x; the project was shelved due to lack of interest and [other parts of] $job taking priority. I haven't looked at 5.x or 6.x code, but 4.x certainly would have benefited from an architectural overhaul. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita DO NOT send mail to the following addresses: [EMAIL PROTECTED] -*- [EMAIL PROTECTED] -*- [EMAIL PROTECTED] Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: vrf support in FreeBSD
On Tuesday 09 May 2006 06:54, Julian Elischer wrote: > Pramod Srinivasan wrote: > >Hi Folks, > > > >I am curious to know if there is any plans to support multiple routing > >tables in FreeBSD's official release? > > > >There was some discussion on this topic last year, if there is any vrf > >patch for a latest release of FreeBSD, I would love to give it a try. > > I am doing some small bits of work on this.. > Do you have anything to show/test? I am really interested in this and would like to help, however, I have no real kernel knowledge in this area, sorry. > how do you want to select which table should be used? > (This is more of a 'survey' as I am trying to work out what I should > support) > I saw two approaches on this issue - older one (discovered by me sooner - spring 2003) was some MPLS patches made by Luigi Iannone uses per-socket option, somewhat similar to Cisco's method (specifying vrf on command line, however, I have no internal knowledge of IOS). Somewhat later I discovered Marco Zec's vimage patch, which enhances jails for this. This makes routing tables management and understanding simpler - at least for me. I would like to use second one or something similar. Regards, Milan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
