IPSec and racoon issue...

[Chris Watson]

So I have been running a stable ipsec tunnel between my MacBook Pro and a
FreeBSD 10-stable server, I just rebuilt world today and raccoon has become
pissy and refuses to start, and as usual with ipsec, debugging it is like
winning gold in the pain olympics. So here's the issue, my working config
has not changed at all. I'm simply running a new FreeBSD 10-stable r276472
world + kernel. I have looked all over at UPDATING, source commits to
stable, google, etc and I can't figure this error out.

Anytime I try to start racoon it looks like it starts but it doesn't. The
only error I can get is to run it with "racoon -F -ddd -f
/usr/local/etc/racoon/racoon.conf", and I get the following

"ERROR: libipsec failed pfkey open (Address family not supported by
protocol family)
racoon: failed to initialize pfkey socket"

Doing a "setkey -F" produces "pfkey_open: Address family not supported by
protocol family"

I saw that ae made some commits to stable during december that touched
ipsec but they looked benign.

Has anyone seen this before? Pointers? A general direction for a clue?

Chris
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

[Tod McQuillin]

On Wed, 31 Dec 2014, Chris Watson wrote:


> Anytime I try to start racoon it looks like it starts but it doesn't. The
> only error I can get is to run it with "racoon -F -ddd -f
> /usr/local/etc/racoon/racoon.conf", and I get the following
>
> "ERROR: libipsec failed pfkey open (Address family not supported by
> protocol family)
> racoon: failed to initialize pfkey socket"
>
> Doing a "setkey -F" produces "pfkey_open: Address family not supported by
> protocol family"

Do you have the following in your kernel config file?

options IPSEC
device crypto
device cryptodev

--
Tod

[Chris Watson]

I did not have "device cryptodev" is that required now? I just added that
and installed a new kernel, I get the same errors.

Chris

[Bjoern A. Zeeb]

> On 01 Jan 2015, at 04:36 , Chris Watson <bsdu...@gmail.com> wrote:
>
> So I have been running a stable ipsec tunnel between my MacBook Pro and a
> FreeBSD 10-stable server, I just rebuilt world today and raccoon has become
> pissy and refuses to start, and as usual with ipsec, debugging it is like
> winning gold in the pain olympics. So here's the issue, my working config
> has not changed at all. I'm simply running a new FreeBSD 10-stable r276472
> world + kernel. I have looked all over at UPDATING, source commits to
> stable, google, etc and I can’t figure this error out.

Do you know the old revision as well, to limit the search time?

> Anytime I try to start racoon it looks like it starts but it doesn't. The
> only error I can get is to run it with "racoon -F -ddd -f
> /usr/local/etc/racoon/racoon.conf", and I get the following
>
> "ERROR: libipsec failed pfkey open (Address family not supported by
> protocol family)
> racoon: failed to initialize pfkey socket"
>
> Doing a "setkey -F" produces "pfkey_open: Address family not supported by

> protocol family”


That smells like a raw socket issue to me. But the only changes there I can remember is that someone changed the source address selection but nothing that would trigger this.

You could turn net.inet.ipsec.debug to 0xff and check that there is nothing in dmesg -a after trying to start racoon, just to rule that out.

Also could you paste the output of `sysctl -a | grep ipsec` and `sysctl -a net.key` just trying to make sure … ;-)


—
Bjoern A. Zeeb Charles Haddon Spurgeon:
"Friendship is one of the sweetest joys of life. Many might have failed
beneath the bitterness of their trial had they not found a friend."

[Chris Watson]

Bjoern,

Well now the puzzle deepens. I noticed about 5 minutes before your email
came through I have NO *ipsec* or *net.key* sysctls.

It's like the crypto subsystem isn't getting pulled in to my kernel
compile, even though its in the config. Whaaaat? I wonder if my src tree is
jacked. But how could the kernel build if it didn't have all the bits that
are in my kernel config? Maybe I pulled a src update in the middle of
someones commit? This is really weird.

Kernel Config of the server in question:

# $FreeBSD: stable/10/sys/amd64/conf/GENERIC 272313 2014-09-30 16:55:19Z bz
$


cpu HAMMER

ident PRIYANKA


#makeoptions DEBUG=-g # Build kernel with gdb(1) debug
symbols

#makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace
support


options SCHED_ULE # ULE scheduler

options PREEMPTION # Enable kernel thread preemption

options INET # InterNETworking

options INET6 # IPv6 communications protocols

options TCP_OFFLOAD # TCP offload

options SCTP # Stream Control Transmission
Protocol

#options FFS # Berkeley Fast Filesystem

#options SOFTUPDATES # Enable FFS soft updates support

#options UFS_ACL # Support for access control lists

#options UFS_DIRHASH # Improve performance on big
directories

#options UFS_GJOURNAL # Enable gjournal-based UFS
journaling

#options QUOTA # Enable disk quotas for UFS

options MD_ROOT # MD is a potential root device

#options NFSCL # New Network Filesystem Client

#options NFSD # New Network Filesystem Server

#options NFSLOCKD # Network Lock Manager

#options NFS_ROOT # NFS usable as /, requires NFSCL

#options MSDOSFS # MSDOS Filesystem

options CD9660 # ISO 9660 Filesystem

options PROCFS # Process filesystem (requires
PSEUDOFS)

options PSEUDOFS # Pseudo-filesystem framework

options GEOM_PART_GPT # GUID Partition Tables.

#options GEOM_RAID # Soft RAID functionality.

options GEOM_LABEL # Provides labelization

options COMPAT_FREEBSD32 # Compatible with i386 binaries

#options COMPAT_FREEBSD4 # Compatible with FreeBSD4

#options COMPAT_FREEBSD5 # Compatible with FreeBSD5

#options COMPAT_FREEBSD6 # Compatible with FreeBSD6

#options COMPAT_FREEBSD7 # Compatible with FreeBSD7

#options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI

options KTRACE # ktrace(1) support

options STACK # stack(9) support

options SYSVSHM # SYSV-style shared memory

options SYSVMSG # SYSV-style message queues

options SYSVSEM # SYSV-style semaphores

options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions

options PRINTF_BUFR_SIZE=128 # Prevent printf output being
interspersed.

options KBD_INSTALL_CDEV # install a CDEV entry in /dev

options HWPMC_HOOKS # Necessary kernel hooks for
hwpmc(4)

options AUDIT # Security event auditing

options CAPABILITY_MODE # Capsicum capability mode

options CAPABILITIES # Capsicum capabilities

options PROCDESC # Support for process descriptors

options MAC # TrustedBSD MAC Framework

#options KDTRACE_FRAME # Ensure frames are compiled in

#options KDTRACE_HOOKS # Kernel DTrace hooks

options DDB_CTF # Kernel ELF linker loads CTF data

options INCLUDE_CONFIG_FILE # Include this file in kernel


options CAPABILITY_MODE # Enable Capsicum sandboxing support

options CAPABILITIES # ""

options PROCDESC # ""



# Debugging support. Always need this:

options KDB # Enable kernel debugger support.

options KDB_TRACE # Print a stack trace for a panic.


# Make an SMP-capable kernel by default

options SMP # Symmetric MultiProcessor Kernel


# CPU frequency control

device cpufreq


# Bus support.

device acpi

options ACPI_DMAR

device pci


# Floppy drives

#device fdc


# ATA controllers

device ahci # AHCI-compatible SATA controllers

device ata # Legacy ATA/SATA controllers

options ATA_STATIC_ID # Static device numbering

#device mvs # Marvell
88SX50XX/88SX60XX/88SX70XX/SoC SATA

#device siis # SiliconImage
SiI3124/SiI3132/SiI3531 SATA


# ATA/SCSI peripherals

device scbus # SCSI bus (required for ATA/SCSI)

device ch # SCSI media changers

device da # Direct Access (disks)

device sa # Sequential Access (tape etc)

device cd # CD

device pass # Passthrough device (direct
ATA/SCSI access)

device ses # Enclosure Services (SES and
SAF-TE)

device ctl # CAM Target Layer


# atkbdc0 controls both the keyboard and the PS/2 mouse

device atkbdc # AT keyboard controller

device atkbd # AT keyboard

#device psm # PS/2 mouse


#device kbdmux # keyboard multiplexer


device vga # VGA video card driver

options VESA # Add support for VESA BIOS
Extensions (VBE)


device splash # Splash screen and screen saver
support


# syscons is the default console driver, resembling an SCO console

device sc

options SC_PIXEL_MODE # add support for the raster text
mode

# vt is the new video console driver

device vt

device vt_vga

device vt_efifb


device agp # support several AGP chipsets


# PCI Ethernet NICs that use the common MII bus controller code.

# NOTE: Be sure to keep the 'device miibus' line in order to use these NICs!

device miibus # MII bus support

device re # RealTek 8139C+/8169/8169S/8110S


# Pseudo devices.

device loop # Network loopback

device random # Entropy device

device padlock_rng # VIA Padlock RNG

device rdrand_rng # Intel Bull Mountain RNG

device ether # Ethernet support

device vlan # 802.1Q VLAN support

device tun # Packet tunnel.

device md # Memory "disks"

device gif # IPv6 and IPv4 tunneling

device faith # IPv6-to-IPv4 relaying
(translation)

device firmware # firmware assist module


# The `bpf' device enables the Berkeley Packet Filter.

# Be aware of the administrative consequences of enabling this!

# Note that 'bpf' is required for DHCP.

device bpf # Berkeley packet filter


# USB support

device uhci # UHCI PCI->USB interface

device ohci # OHCI PCI->USB interface

device ehci # EHCI PCI->USB interface (USB 2.0)

device xhci # XHCI PCI->USB interface (USB 3.0)

device usb # USB Bus (required)

device ukbd # Keyboard

device umass # Disks/Mass storage - Requires
scbus and da


# Sound support

device sound # Generic sound driver (required)

device snd_hda # Intel High Definition Audio


# MMC/SD

#device mmc # MMC/SD bus

#device mmcsd # MMC/SD memory card

#device sdhci # Generic PCI SD Host Controller


# VirtIO support

device virtio # Generic VirtIO bus (required)

device virtio_pci # VirtIO PCI device

device vtnet # VirtIO Ethernet device

device virtio_blk # VirtIO Block device

device virtio_scsi # VirtIO SCSI device

device virtio_balloon # VirtIO Memory Balloon device


# HyperV drivers

device hyperv # HyperV drivers


# Xen HVM Guest Optimizations

# NOTE: XENHVM depends on xenpci. They must be added or removed together.

options XENHVM # Xen HVM kernel infrastructure

device xenpci # Xen HVM Hypervisor services driver


# VMware support

device vmx # VMware VMXNET3 Ethernet


# IPSec support

options IPSEC # Enable IPSec support

device crypto # Use the Crypto framework

device cryptodev

options IPSEC_FILTERTUNNEL # Allowing packet filtering on
tunneled packets

device enc # Support for the encapsulating
interface

[Bjoern A. Zeeb]

> On 02 Jan 2015, at 02:12 , Chris Watson <bsdu...@gmail.com> wrote:
>
> Bjoern,
>
> Well now the puzzle deepens. I noticed about 5 minutes before your email came through I have NO *ipsec* or *net.key* sysctls.
>
> It's like the crypto subsystem isn't getting pulled in to my kernel compile, even though its in the config. Whaaaat? I wonder if my src tree is jacked. But how could the kernel build if it didn't have all the bits that are in my kernel config? Maybe I pulled a src update in the middle of someones commit? This is really weird.
>
> Kernel Config of the server in question:
>
> # $FreeBSD: stable/10/sys/amd64/conf/GENERIC 272313 2014-09-30 16:55:19Z bz $
>
> cpu HAMMER
> ident PRIYANKA
>

> ….

> # IPSec support
> options IPSEC # Enable IPSec support
> device crypto # Use the Crypto framework
> device cryptodev
> options IPSEC_FILTERTUNNEL # Allowing packet filtering on tunneled packets
> device enc # Support for the encapsulating interface

Good. So this is a kernel build/install issue after all.

You sure you did build and installed the right kernel config (did you save this with a different name than GENERIC?); check uname for what you are running.

[Chris Watson]

Horribly, embarrassingly, humbly, I have to confess to doing exactly what
you were just about to drop the hammer on me for doing. My memory from last
night is a little fuzzy from NYE. But after thinking about it I think I
used "MYKERNCONF=" instead of "KERNCONF=" while building the kernel. And
sure enough you know exactly what happens then. A GENERIC kernel. It's been
a while since I have done anything that dumb. I didn't even think to check
the kernel. I kept looking at everything else, src, UPDATING, commits, etc.
Now I am going to have to go back to IRC and help 10 others with FreeBSD
issues as penance. Thanks for the gentle clue stick slap in the head
Bjoern!

Chris

[Lyndon Nerenberg]

On Jan 1, 2015, at 6:59 PM, Chris Watson <bsdu...@gmail.com> wrote:

> I didn't even think to check
> the kernel. I kept looking at everything else, src, UPDATING, commits, etc.

sysctl kern.conftxt

is worth memorizing.

[Ian Smith]

On Thu, 1 Jan 2015 19:09:44 -0800, Lyndon Nerenberg wrote:
> On Jan 1, 2015, at 6:59 PM, Chris Watson <bsdu...@gmail.com> wrote:
>
> > I didn't even think to check
> > the kernel. I kept looking at everything else, src, UPDATING, commits, etc.
>
> sysctl kern.conftxt
>
> is worth memorizing.

Off your topic, but to aid memorising this, looking at mine on:
FreeBSD x200.smithi.id.au 9.3-PRERELEASE FreeBSD 9.3-PRERELEASE #0: Fri
Nov 14 18:41:59 EST 2014 ro...@x200.smithi.id.au:/usr/obj/usr/src/sys/GENERIC amd64

options COMPAT_FREEBSD7
options COMPAT_FREEBSD6
options COMPAT_FREEBSD5
options COMPAT_FREEBSD4
options COMPAT_FREEBSD32

Should I be surprised to find no COMPAT_FREEBSD8 ?

cheers, Ian

[Kevin Oberman]

On Thu, Jan 1, 2015 at 8:17 PM, Ian Smith <smi...@nimnet.asn.au> wrote:

> On Thu, 1 Jan 2015 19:09:44 -0800, Lyndon Nerenberg wrote:
> > On Jan 1, 2015, at 6:59 PM, Chris Watson <bsdu...@gmail.com> wrote:
> >
> > > I didn't even think to check
> > > the kernel. I kept looking at everything else, src, UPDATING,
> commits, etc.
> >
> > sysctl kern.conftxt
> >
> > is worth memorizing.
>
> Off your topic, but to aid memorising this, looking at mine on:
> FreeBSD x200.smithi.id.au 9.3-PRERELEASE FreeBSD 9.3-PRERELEASE #0: Fri
> Nov 14 18:41:59 EST 2014 ro...@x200.smithi.id.au:/usr/obj/usr/src/sys/GENERIC
> amd64
>
> options COMPAT_FREEBSD7
> options COMPAT_FREEBSD6
> options COMPAT_FREEBSD5
> options COMPAT_FREEBSD4
> options COMPAT_FREEBSD32
>
> Should I be surprised to find no COMPAT_FREEBSD8 ?
>
> cheers, Ian
>

Thanks to the magic of symbol versioning, I don't think there has a
COMPAT_FREEBSD8 or COMPAT_FREEBSD9. With luck and care, there should never
be one again.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkob...@gmail.com

[Claude Buisson]

On 01/02/2015 05:49, Kevin Oberman wrote:
>
> Thanks to the magic of symbol versioning, I don't think there has a
> COMPAT_FREEBSD8 or COMPAT_FREEBSD9. With luck and care, there should never
> be one again.

Have a look at sys/conf/NOTES in -head, to find:

COMPAT_FREEBSD9
COMPAT_FREEBSD10

added by r273603 on Oct 24

but no COMPAT_FREEBSD8

[Ian Smith]

On Fri, 2 Jan 2015 12:33:33 +0100, Claude Buisson wrote:
> On 01/02/2015 05:49, Kevin Oberman wrote:
> >
> > Thanks to the magic of symbol versioning, I don't think there has a
> > COMPAT_FREEBSD8 or COMPAT_FREEBSD9. With luck and care, there should never
> > be one again.
>
> Have a look at sys/conf/NOTES in -head, to find:
>
> COMPAT_FREEBSD9
> COMPAT_FREEBSD10
>
> added by r273603 on Oct 24
>
> but no COMPAT_FREEBSD8

Interesting, thanks guys. Maybe 8 and 9 come to the same thing in this
respect. FWIW, pascal binaries built on 8.2 i386 run fine on 9.3 amd64,
but mine are just maths and file I/O. Not sure why I was surprised ..

cheers, Ian

[Kevin Oberman]

On Fri, Jan 2, 2015 at 4:44 AM, Ian Smith <smi...@nimnet.asn.au> wrote:

> On Fri, 2 Jan 2015 12:33:33 +0100, Claude Buisson wrote:
> > On 01/02/2015 05:49, Kevin Oberman wrote:
> > >
> > > Thanks to the magic of symbol versioning, I don't think there has a
> > > COMPAT_FREEBSD8 or COMPAT_FREEBSD9. With luck and care, there should
> never
> > > be one again.
> >
> > Have a look at sys/conf/NOTES in -head, to find:
> >
> > COMPAT_FREEBSD9
> > COMPAT_FREEBSD10
> >
> > added by r273603 on Oct 24
> >
> > but no COMPAT_FREEBSD8
>
> Interesting, thanks guys. Maybe 8 and 9 come to the same thing in this
> respect. FWIW, pascal binaries built on 8.2 i386 run fine on 9.3 amd64,
> but mine are just maths and file I/O. Not sure why I was surprised ..
>
> cheers, Ian
>

How odd! 10-STABLE has no reference to COMPAT_FREEBSD9.

Very few things should need any COMPAT_FREEBSD options. For a long time on
8 and 9 I only needed COMPAT_FREEBSD for a single port.

I'll try to take a look at why COMPAT_FREEBSD9 and 10 have been added to
head.

--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkob...@gmail.com

[Claude Buisson]

On 01/02/2015 18:59, Kevin Oberman wrote:
> On Fri, Jan 2, 2015 at 4:44 AM, Ian Smith <smi...@nimnet.asn.au> wrote:
>
>> On Fri, 2 Jan 2015 12:33:33 +0100, Claude Buisson wrote:
>> > On 01/02/2015 05:49, Kevin Oberman wrote:
>> > >
>> > > Thanks to the magic of symbol versioning, I don't think there has a
>> > > COMPAT_FREEBSD8 or COMPAT_FREEBSD9. With luck and care, there should
>> never
>> > > be one again.
>> >
>> > Have a look at sys/conf/NOTES in -head, to find:
>> >
>> > COMPAT_FREEBSD9
>> > COMPAT_FREEBSD10
>> >
>> > added by r273603 on Oct 24
>> >
>> > but no COMPAT_FREEBSD8
>>
>> Interesting, thanks guys. Maybe 8 and 9 come to the same thing in this
>> respect. FWIW, pascal binaries built on 8.2 i386 run fine on 9.3 amd64,
>> but mine are just maths and file I/O. Not sure why I was surprised ..
>>
>> cheers, Ian
>>
>
> How odd! 10-STABLE has no reference to COMPAT_FREEBSD9.
>
> Very few things should need any COMPAT_FREEBSD options. For a long time on
> 8 and 9 I only needed COMPAT_FREEBSD for a single port.
>

In my understanding, the COMPAT_FREEBSDxx kernel options are not for ports,
but apply to the kernel syscalls interface and are needed to run old binaries
compiled on previous versions of FreeBSD. This is different from the libraries
versionning.

> I'll try to take a look at why COMPAT_FREEBSD9 and 10 have been added to
> head.
> --
> R. Kevin Oberman, Network Engineer, Retired
> E-mail: rkob...@gmail.com

CBu

[Kevin Oberman]

On Fri, Jan 2, 2015 at 2:21 PM, Claude Buisson <claude....@free.fr>
wrote:

You are correct. Senior moment here confusing the kernel COMPAT_FREEBSD
options with the misc/compat ports. And now I understand why no
COMPAT_FREEBSD9 option is needed in 10 but is in head.

--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkob...@gmail.com