SAD entry of type tcp-md5
-
With previous versions of pfSense ( < 2.2 ) a SA entry could be manually added to the system SAD using the setkey tool:
Example configuration line:
add [local ip] [destination ip] tcp 0x1000 -A tcp-md5 "MyPassword" ;
This was useful for establishing BGP connectivity with peers using basic encryption.
Is there a new method for doing this in 2.2? - installing ipsec-tools package provides access to the command, but tcp-md5 SAs don't seem to work.
Failure error:
The result of line x: Invalid argument.
-
The BGP package does all of this by its own.
Why do you need to do these yourself? -
Using BIRD for BGP ;D
-
Is there a possibility of enabling 'options TCP_SIGNATURE' in the kernel build to restore previous functionality, or are there deeper issues - ie. incompatibility with the new StrongSwan IPSEC implementation?
-
It is there as functionality.
Not sure what you are refering too!What is wrong with OpenBGP package?
-
ermal,
Thanks for your interest. Testing was done with pfSense 2.1.1 release.
There are numerous differences between these routing daemons, and advantages to each. The important factors to me are:
1. OpenBGP appears to have a bug in 'nexthop' attribute rewriting.
Using a configuration file similar to Reiner030 in thread https://forum.pfsense.org/index.php?topic=57614.0
Command:
bgpctl show ip bgp detail out neighbor [Peer Name]
Shows advertised nexthop as the required(configured) CARP address. Unfortunately, Wireshark captures (and equipment at the other end of the peering connection) show the actual advertisement packets indicate the original(interface) nextop.
As a result, unless the provider is willing to rewrite the nexthop for you, the recommended CARP configuration for dual homing doesn't work. This seemed most troublesome with a provider using Juniper routing equipment.
Configuration files are available upon request.
2. Authentication. OpenBGP is able to deal with authentication information sent from a peer, but does not VALIDATE it, removing most benefits of the mechanism. Using setkey, instead of 'tcp md5sig' configuration within OpenBGP provides the required validation.
3. It was non-trivial to configure OpenBGP in such a way that it wouldn't segfault on a CARP state change. Seemed to be mitigated by only listening on real interface addresses.
3. BIRD provides a uniform CLI interface for BGP and OSPF protocols
4. BIRD supports new protocols such as BFD to reduce failure detection times with peering connections.
5. Route filtering and attribute modification is trivial using procedural (possibly layered) functions as opposed linear filter parsing provided by OpenBGP. I acknowledge this is very subjective.
6. OpenBGP release status. Last official release according to http://www.openbgpd.org/ was in November 2009. Various patches have been developed since, but never officially integrated. Stagnated project.
-
I'm also interested in having```
options TCP_SIGNATUREWhat I think quantumx means by restoring previous functionality is that in 2.1.5 it has it, and you can use setkey to add tcp-md5 auth but not in 2.2 My use case is similar to quantumx but i'm using quagga instead of bird. I need (or at least strongly prefer) to run OSPF and BGP on the same box. I hacked the quagga module a little bit to get it running quagga bgp as well as ospf. But my BGP peer requires md5 auth. I was able to set the TCP signatures with setkeys but on 2.2 it no longer works.
-
For sure that option is in there!
-
Well then… I wonder what else is wrong. Here is more info.
I'm trying to run this:
/usr/local/sbin/setkey -f /var/etc/quagga/tcp-md5sig
where my tcp-md5sig file contains entries like this:
add 11.22.33.44 11.22.33.45 tcp 0x1000 -A tcp-md5 "Secret MD5 Password Text" ;
And I get the error:
The result of line 1: Invalid argument.
To try to see where the problem was, I stood up a FreeBSD 10.1-RC3 instance with the GENERIC kernel config. It was unable to do the setkey until I added:
options IPSEC device crypto options TCP_SIGNATURE
I tried it first with just IPSEC and the crypto device but not the TCP_SIGNATURE option. This kernel gave me the exact same error as i'm seeing in 2.2, so that was why I presumed that my problem was quantumx's problem and that TCP_SIGNATURE was missing.
I also just noticed that 2.2 has two different(?) setkey binaries /sbin/setkey and /usr/local/sbin/setkey. The later says it's from ipsec-tools 0.8.1 the one in /sbin does not indicate where it comes from. Fwiw both display the same error when i try to load my signature file.
My tcp-mdgsig file works on both 2.1.5 and on the FreeBSD 10.1-RC3 instance with the generic kernel + those three lines added to the configuration file.
And as another fun aside. This is in the manpage for setkey for freebsd 10.
BUGS
The setkey utility should report and handle syntax errors better. -
I also just noticed that 2.2 has two different(?) setkey binaries /sbin/setkey and /usr/local/sbin/setkey. The later says it's from ipsec-tools 0.8.1 the one in /sbin does not indicate where it comes from. Fwiw both display the same error when i try to load my signature file.
Not on my system:
[2.2-BETA][root@pfsense.localdomain]/boot/kernel: find / -name setkey /sbin/setkey [2.2-BETA][root@pfsense.localdomain]/boot/kernel: uname -a FreeBSD pfsense.localdomain 10.1-RC3 FreeBSD 10.1-RC3 #45 3eb90bd(releng/10.1)-dirty: Wed Oct 29 08:31:17 CDT 2014 root@pf22-amd64-snap:/usr/obj.amd64/usr/pfSensesrc/src/sys/pfSense_SMP.10 amd64
Was your 2.2 system an upgrade from 2.1.x? Or could some errant package have included ipsec-tools?
Also, TCP_SIGNATURE and IPSEC both show up as a config option in the kernel (use 'strings ./kernel | grep ^options' to verify). Both crypto and cryptodev devices show up as well.
-
Is there a possibility of enabling 'options TCP_SIGNATURE' in the kernel build to restore previous functionality, or are there deeper issues - ie. incompatibility with the new StrongSwan IPSEC implementation?
Hmm, you may be right: from http://marc.info/?l=strongswan-announce&m=133830432204363&w=2:
Hello,
with strongSwan you are not supposed to manipulate the SAD/SPD
with an external command line tool as "setkey" or
"ip xfrm state/policy add" because the IKEv1/IKEv2 daemons will
not become aware of any external SAD/SPD changes. All changes
must be communicated through the strongSwan daemon interfaces.Regards
Andreas
On 29.05.2012 16:23, krishna chaitanya wrote:
HI Team,
I am new to strongswan. We are working on an implementation of IPsec.
I earlier worked with racoon where I used setkey for SAD/SPD manipulation.
In strongswan I had configured the SA's using IPsec.conf file, but is
there a tool where we could manipulate SAD/SPD using shell.Thanks,
KC.Sanapala -
Ok scratch the /usr/local/sbin/setkey it must be left over from upgrade.
I've copied setkey from my 10.1rc3 instance since it does not match the one in /sbin but it has the same results when trying to add the records.
How can I trace the execution to see where things differ? I can't find much info on getting dtrace running.
-
I've been working on this today and have the pfsense build tools setup. The ipsec_improvement.diff seems to touch a lot of stuff around the code around where I'm getting errors. I'm looking on some background on why, what, and from where ipsec_improvement.diff originates.
I see some of the code in the diff is from here but not most of it. Any help tracking down the details for this patch is appreciated.
-
I just got a kernel built and installed without the ipsec_improvement.diff and I can confirm that setkey works in that version. I'll try to find the bug in the diff. but be warned, I have no right to be mucking around in either kernel code, or ipsec code! danger!
-
I was not able to discern the exact point in ipsec_improvement.diff that breaks setkey. It has to do with the implementation of the 'new' key hash db but figuring out exactly what is wrong with the code is beyond my ability.
Today I loaded a kernel without ipsec_improvement.diff on my box that I needed to run setkey on and I can report that the Nov 3 snapshot and my custom kernel allows me to run setkey. and i'm able to do TCP-MD5 auth in quagga BGP to connect to my peer.
Now I can test the original reason I went to 2.2 in the first place. to see how fast multi-threaded PF can nat on my 2750 atom and a 1gbps link under real workload.
-
I've been trying to work with this issue for a few weeks. And I think that the ipsec_improvement patch has a larger problem than just how I want to use it.
My most recent test takes all of my crazy unsupported QuaggaBGPD stuff out of pfsense and tries to have two pfsense boxes use openBGPD to connect to each other using the TCP-MD5 Password config. Which should be a supported and working configuration.
It fails to work with todays snapshot (and for all snapshots since my first reply), but if I build and install a kernel without the ipsec_improvement patch it works.
My BGP configs are simple:
Host A
# This file was created by the package manager. Do not edit! AS 65432 fib-update yes listen on 192.168.70.1 router-id 192.168.70.1 network 192.168.70.0/30 network 192.168.80.0/24 group "group" { remote-as 65431 neighbor 192.168.70.2 { descr "" tcp md5sig password _SH4KOw4I_El6Qjho4Dsd3wL announce all local-address 192.168.70.1 } } deny from any deny to any allow from 192.168.70.2 allow to 192.168.70.2
HostB
# This file was created by the package manager. Do not edit! AS 65431 fib-update yes listen on 192.168.70.2 router-id 192.168.70.2 network 192.168.70.0/30 network 192.168.81.0/24 group "groupa" { remote-as 65432 neighbor 192.168.70.1 { descr "" tcp md5sig password _SH4KOw4I_El6Qjho4Dsd3wL announce all local-address 192.168.70.2 } } deny from any deny to any allow from 192.168.70.1 allow to 192.168.70.1
192.168.70.0/30 is running on em1_vlan3 which in virtualbox em1 is a hostonly network. the 192.168.80.0/24 and 192.168.81.24 are running on em2 on each of the guests.
If you set this up you will see that openBGPD does not work.
If you blank out the password it works.
If you build a kernel with the ipsec_improvement.diff removed from the patchlist and install it the config with a password works.
If you run setkey -D on the working example it dumps the keys from the SAD
also you can try to run setkey -f filename where filename is:
add 192.168.70.1 192.168.70.2 tcp 0x1000 -A tcp-md5 "_SH4KOw4I_El6Qjho4Dsd3wL" ;
before and after and see how it only works on the later. Previously I was focusing on just the setkey stuff, and in this thread ermal asks why setkey, but this demonstrates that the openbgpd package still has issues even if it does not use setkey directly.
I should mention I spent 2 weeks trying to find the problem with the patch but i'm not skilled enough in C or the BSD kernel to pinpoint the problem.
-
I just pushed a fix for this.
Please wait a next coming snapshot and test. -
I built a kernel with the latest from git and it works. I'll update to the snapshot when it is ready.
Thank you.