Re: matching ipv6 esp traffic
this has been fixed in openbsd 4.5 On Sun, Apr 12, 2009 at 05:48:54PM +0200, Florian Obser wrote: > Hi, > > I'm trying to secure my wlan access point with ipsec. > > Apparently I cannot match ipv6 esp traffic. This is on 4.4 > > I build a simplified setup with qemu, ipsec-gw and ipsec-client: > > - ipsec-gw > > [r...@ipsec-gw:~]# cat /etc/ipsec.conf > ike passive esp from 10.12.32.235 to 10.12.32.236 > ike passive esp from 2001:db8::1 to 2001:db8::2 > > [r...@ipsec-gw:~]# cat /etc/pf.conf > pass log on enc0 > block in log on em0 > pass out log on em0 > # allow link-local multicast for neighbor solicitation / neighbor > advertisement > pass in on em0 proto icmp6 to FF02::/16 > pass in on em0 proto tcp from any to em0 port ssh > pass in log on em0 proto udp from any to em0 port isakmp > pass in log on em0 proto esp from any to em0 > > [r...@ipsec-gw:~]# ipsecctl -s all > FLOWS: > flow esp in from 10.12.32.236 to 10.12.32.235 peer 10.12.32.236 srcid > 10.12.32.235/32 dstid 10.12.32.236/32 type use > flow esp out from 10.12.32.235 to 10.12.32.236 peer 10.12.32.236 srcid > 10.12.32.235/32 dstid 10.12.32.236/32 type require > flow esp in from 2001:db8::2 to 2001:db8::1 peer 2001:db8::2 srcid > 2001:db8::1/128 dstid 2001:db8::2/128 type use > flow esp out from 2001:db8::1 to 2001:db8::2 peer 2001:db8::2 srcid > 2001:db8::1/128 dstid 2001:db8::2/128 type require > > SAD: > esp tunnel from 2001:db8::1 to 2001:db8::2 spi 0x20d8f195 auth > hmac-sha2-256 enc aes > esp tunnel from 10.12.32.235 to 10.12.32.236 spi 0x6335527f auth > hmac-sha2-256 enc aes > esp tunnel from 10.12.32.236 to 10.12.32.235 spi 0xa90135ff auth > hmac-sha2-256 enc aes > esp tunnel from 2001:db8::2 to 2001:db8::1 spi 0xd9956a4e auth > hmac-sha2-256 enc aes > > - ipsec-client > > [r...@ipsec-client:~]# cat /etc/pf.conf > pass all > > [r...@ipsec-client:~]# cat /etc/ipsec.conf > ike esp from 10.12.32.236 to 10.12.32.235 > ike esp from 2001:db8::2 to 2001:db8::1 > > [r...@ipsec-client:~]# ipsecctl -s all > FLOWS: > flow esp in from 10.12.32.235 to 10.12.32.236 peer 10.12.32.235 srcid > 10.12.32.236/32 dstid 10.12.32.235/32 type use > flow esp out from 10.12.32.236 to 10.12.32.235 peer 10.12.32.235 srcid > 10.12.32.236/32 dstid 10.12.32.235/32 type require > flow esp in from 2001:db8::1 to 2001:db8::2 peer 2001:db8::1 srcid > 2001:db8::2/128 dstid 2001:db8::1/128 type use > flow esp out from 2001:db8::2 to 2001:db8::1 peer 2001:db8::1 srcid > 2001:db8::2/128 dstid 2001:db8::1/128 type require > > SAD: > esp tunnel from 2001:db8::1 to 2001:db8::2 spi 0x20d8f195 auth > hmac-sha2-256 enc aes > esp tunnel from 10.12.32.235 to 10.12.32.236 spi 0x6335527f auth > hmac-sha2-256 enc aes > esp tunnel from 10.12.32.236 to 10.12.32.235 spi 0xa90135ff auth > hmac-sha2-256 enc aes > esp tunnel from 2001:db8::2 to 2001:db8::1 spi 0xd9956a4e auth > hmac-sha2-256 enc aes > > > --- > > loaded rules: > > [r...@ipsec-gw:~/pf]# pfctl -vv -s rules | egrep -v 'Evaluations|Inserted' > @0 pass log on enc0 all flags S/SA keep state > @1 block drop in log on em0 all > @2 pass out log on em0 all flags S/SA keep state > @3 pass in on em0 inet6 proto tcp from any to fe80::5652:ff:fe3d:e648 port > = ssh flags S/SA keep state > @4 pass in on em0 inet6 proto tcp from any to 2001:db8::1 port = ssh flags > S/SA keep state > @5 pass in on em0 inet6 proto ipv6-icmp from any to ff02::/16 keep state > @6 pass in on em0 inet proto tcp from any to 10.12.32.235 port = ssh flags > S/SA keep state > @7 pass in log on em0 inet6 proto udp from any to fe80::5652:ff:fe3d:e648 > port = isakmp keep state > @8 pass in log on em0 inet6 proto udp from any to 2001:db8::1 port = isakmp > keep state > @9 pass in log on em0 inet6 proto esp from any to fe80::5652:ff:fe3d:e648 > keep state > @10 pass in log on em0 inet6 proto esp from any to 2001:db8::1 keep state > @11 pass in log on em0 inet proto udp from any to 10.12.32.235 port = > isakmp keep state > @12 pass in log on em0 inet proto esp from any to 10.12.32.235 keep state > > === > > pinging ipv4 (this is working): > > [r...@ipsec-client:~]# ping -c 1 ipsec-gw > PING ipsec-gw (10.12.32.235): 56 data bytes > 64 bytes from 10.12.32.235: icmp_seq=0 ttl=255 time=0.950 ms > --- ipsec-gw ping statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 0.950/0.950/0.950/0.000 ms > > [r...@ipsec-gw:~]# tcpdump -nlp -i em0 not port ssh > tcpdump: listening on em0, link-type EN10MB > 16:33:44.585647 esp 10.12.32.236 > 10.12.32.235 spi 0xA90135FF seq 11 len > 132 > 16:33:44.585955 esp 10.12.32.235 > 10.12.32.236 spi 0x6335527F seq 11 len > 132 > > > [r...@ipsec-gw:~]# tcpdump -nlp -i enc0 not port ssh > tcpdump: listening on enc0, link-type ENC > 16:33:44.585838 (authentic,confidential): SPI 0xa
Re: net5501 crypto driver
1.15 should just work fine in stable. -m On Tue, Jan 20, 2009 at 12:19:34PM +0100, Christoph Leser wrote: > As described in > http://kerneltrap.org/mailarchive/openbsd-misc/2008/9/22/3364064 > there is a problem with the driver for the AMD Geode LX series processor > security block for openBSD 4.4 ( glxsb.c ). > > This has been fixed in version 1.15 of this file, but this fix has not > been committed to 4.4. stable ( still on 1.14 ). > > Is it ok to use 1.15 with 4.4 stable or do I have to switch to current > inorder to use this patch. > > Regards > > Christoph
Re: isakmpd on 4.3: pf_key_v2_write: writev failed
On Fri, Sep 19, 2008 at 12:33:36AM +0200, Lukas Ratajski wrote: > IPsec tunnel between two computers - a Soekris net5501 running > [...] > key_encrypt: bits 256: The crypto driver for the net5501 does not support 256bit AES. you have to switch to 128bit AES keys or backport revision 1.15 http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/i386/pci/glxsb.c (and replace M_ZERO with a call to bzero()). -m
Re: altq on enc0?
On Wed, Sep 10, 2008 at 10:11:05PM +0200, Toni Mueller wrote: > I've just discovered that this is unsupported. > > How difficult would it be to add support for this? why not just tag the packet on enc0 and altq on the 'real' interface?
Re: IPsec flow portrange problem
AFAIK it's not supported in IKE, so it's not supported in ipsec.conf
On Thu, Sep 04, 2008 at 10:37:25AM +0200, Michael wrote:
> Hi,
>
> I am trying to setup IPsec and also exclude some parts from getting
> processed by IPsec.
>
> In IPSEC.CONF(5) the description says
>
> [...]
> from src [port sport] to dst [port dport]
> [...]
> The optional port modifiers restrict the flows to the specified ports
> [...]
>
> It is possible to supply multiple src and dst adresses if inside {}.
>
> However, I also would like to add a portrange instead of having to
> manually write one entry for every flow, but it seems that it is only
> possible to add one single port.
>
> Is that right? Did someone manage to add a portrange?
>
> I would need something like:
> flow esp proto udp from X.X.X.X to Y.Y.Y.Y port 5000:5050 type bypass
>
>
> Thanks in advance,
> Michael
Re: SOLVED? Re: 4.0 -> 4.1 broke ipsec
On Fri, Sep 28, 2007 at 07:02:28AM +0200, Otto Moerbeek wrote: > On Thu, 27 Sep 2007, Brian A. Seklecki wrote: > > > > Ok, it's running now. The cause was not the move from 4.0 -> 4.1, but > > > the move from a diskful to a diskless setup: The machine mounts its root > > > fs via nfs. > > > > WHAT?!?!?! What the heck kind of security-minded sanity check would > > fail based on the underlying VFS? > > > > Did you eventually get a PR open on this? > > This has to do with a bug in isakmpd, where scanning a dir could skip > files. The bug could only be triggered on nfs mounts. pr 5557 has been fixed in isakmpd/monitor.c rev 1.70 d_type is not passed over NFS, unless you mount with readdir+
Re: pf tag from ipsec in nat rules
yes, that should be possible. if it does not work, then it's a bug. On Mon, Sep 24, 2007 at 03:08:29PM +0200, Markus Wernig wrote: > Hi all > > Can tags from ipsec (defined in ipsec.conf) be referenced in pf nat > rules (OBSD 4.1)? > > The idea is: > ipsec.conf: > ike esp from A to B tag "mytag" > > pf.conf: > nat on $int_if tagged "mytag" -> ($int_if:1) > nat on $int_if from !($int_if) -> ($int_if:0) > > > If I use the "tagged" keyword, the second nat rule is used even for > packets coming out of the ipsec tunnel. Replacing the "tagged" keyword > with the actual IPs works: > nat on $int_if from A to B -> ($int_if:1) > > Shouldn't this be possible with tags? > > thx for any pointer > > /markus
Re: ipsec vpn?
On Thu, Aug 16, 2007 at 06:43:34PM -0700, Steve B wrote: > I made a few changes and did some more testing this evening. > > 1. I changed the /etc/ipsec.conf to bring it in line with the Greenbow > default transforms that Hans-Joerg recommened. > > # cat /etc/ipsec.conf > ike dynamic esp tunnel from any to 192.168.1.0/24 \ > main auth hmac-sha1 enc 3des group modp1024 \ > quick auth hmac-sha1 enc 3des \ > psk abc123 > > 2. I created the basic polciy file: > > # cat /etc/isakmpd/isakmpd.policy > KeyNote-Version: 2 > Authorizer: "POLICY" > > 3. Being lazy I rebooted the server and tried starting isakmpd manually > without the "-K". It would not start. When I tried starting it with "-dLv" I > got the message: > > 180252.969043 Default check_file_secrecy_fd: not loading > /etc/isakmpd/isakmpd.policy - too open permissions > 180252.970281 Default policy_init: cannot read /etc/isakmpd/isakmpd.policy: > Operation not permitted > > So I went back and started it with "-K". wrong. just fix the permissions of the policy file: chmod 600 /etc/isakmpd/isakmpd.policy
Re: Ethernet bridge over IPsec in OpenBSD 4.1
it was broken and you need to apply the patch from revision 1.161 On Tue, Aug 07, 2007 at 07:25:52PM -0700, Justin Lindberg wrote: > I have not been able to get an Ethernet bridge over IPsec to work > in OpenBSD 4.1. I have two machines running as NAT gateways with a > gif tunnel between them protected by IPsec ESP. The internal > interfaces are both bridged to the gif tunnel. I can ping either > gateway from the other over the tunnel, but the bridges are not > learning any MAC addresses from the gif side save that of the other > gateway. When I try to ping a machine on one LAN from the opposite > gateway, the ARP who-is packets from the gateway will be forwarded > by the other gateway's bridge, but the reply packets do not seem to > be properly sent back over the gif interface by the bridge. > > I noticed in the source repository the following comment in > src/sys/net/if_bridge.c, revision 1.161 > > make bridge(4) mark packets with M_PROTO1 if gif(4) needs to use > etherip encapsulation; unbreaks remote ipsec bridges; ok claudio; > additional testing Renaud Allard > > Is this type of bridging broken in OpenBSD 4.1, or am I missing > something? Is there a way to make this work while I am waiting for > 4.2? I had this exact same setup working in a previous version of > OpenBSD. (I can't remember if it was 3.9 or 4.0.)
Re: Bridge over gif on 4.1
On Fri, Apr 13, 2007 at 12:03:18PM +0200, Renaud Allard wrote: > It's just quite annoying that the man page for brconfig says that the > bridge over gif should work and it does not. well, it did work before and should work in 4.1
Re: demystify enc interface
On Thu, Nov 23, 2006 at 02:47:14PM +0100, Camiel Dobbelaar wrote: > I think this tells me that I can see unencrypted/unencapsulated traffic on > enc0. yes. > However, with tcpdump I see this: > > 14:09:27.894326 (authentic,confidential): SPI 0x728aafc9: 86.90.xx.xx > > 62.58.xx.xx: 192.168.2.3.1264 > 192.168.1.7.8194: . [tcp sum ok] ack 139 > win 64431 (DF) (ttl 128, id 45685, len 40) (ttl 118, id 45685, len 60) > > 14:09:27.915205 (authentic,confidential): SPI 0x021e1fcd: 62.58.xx.xx > > 86.90.xx.xx: 192.168.1.131.3389 > 192.168.2.3.1182: . [tcp sum ok] ack > 177 win 65075 (ttl 127, id 59080, len 40) (ttl 64, id 46361, len 60, bad > cksum 0!) > > The encapsulation is included... that's pretty cool and handy, but I'm not > sure if that's what the manpage says. no, the encapsulation is not included, only the _information_ about the encapsulation is (it's special information in the pcap header) > So inbound traffic passes twice: first with encapsulation, and the second > time without. However, outbound traffic only passes _once_, without the > encapsulation. that's an artefact of openbsd's ipsec implementation. de-encapsulation happens in two steps, where the first step removes the esp-layer, while the 2nd step removes the ip-in-ip encapsulation for tunnel mode. > So I think the pf rules for filtering on enc0 should look like this: > # pass encapsulated traffic > pass in quick log on enc0 proto ipencap from $ext_peer_ip to $ext_if > keep state (other.single 3600) > # rules on decrypted traffic > pass in quick on enc0 from 192.168.28.28 to 192.168.42.10 port 993 keep > state > block in quick on enc0 ipsec.conf(5) tells you how to filter on enc(4) > All in all: > - the bpf view is different from the pf view > - the inbound pf view is different from outbound not really. the only difference is that pf sees both decapsulation steps. > Should pf even see the inbound ipencap traffic? Nothing much that can be > done with it, that cannot also be done on the physical interfaces... it would require some special hacks and flags and heuristics in the kernel. i don't know if this would justify the extra code, but perhaps there's a simple solution. > Shouldn't enc just carry the unencrypted/unencapsulated traffic like the > manpage says? That would make it behave far more like a "normal" > interface. it already does. you could argue, that the encapsulation information should only be printed on '-e', but that breaks backward compatibility. -m
Re: OpenBSD's own compiler
On Mon, Jul 31, 2006 at 06:32:45PM -0300, Andris wrote: > * [9fans] The new ridiculous license > http://9fans.net/archive/2003/06/270 interno ships the same compiler code and has a more liberal license http://www.vitanuova.com/inferno/downloads.html
Re: Encryption and Compression with ipsecctl?
1. IPcomp is only used if it results in smaller packets 2. IPcomp on OpenBSD is broken and does not work correctly (some packets are not compressed correctly). -m
Re: Altq on enc(4)
On Fri, Jun 23, 2006 at 01:22:39PM -0400, Jason Dixon wrote: > Does anyone know if enc(4) was ever updated to support altq? enc(4) does only work for for pcap (tcpdump) and filtering (pf) it's not a real interface and does not support altq.
Re: Crypto acceleration (was: Re: VIA C7 hardware AES support in IPSEC(ctl))
yes, the card needs to support all algorithms, crypto_newsession() does this: /* * The algorithm we use here is pretty stupid; just use the * first driver that supports all the algorithms we need. Do * a double-pass over all the drivers, ignoring software ones * at first, to deal with cases of drivers that register after * the software one(s) --- e.g., PCMCIA crypto cards. * * XXX We need more smarts here (in real life too, but that's * XXX another story altogether). */ -m
Re: Xen/OpenBSD Summer of Code project
On Tue, May 30, 2006 at 04:52:35PM +0200, Dries Schellekens wrote: > Peter Blair wrote: > > >That project (if/once completed) would be very useful. I just cringe > >at the thought of running a guestOS of openbsd under linux or Solaris > >;) > > A minor detail: OpenBSD will run on the Xen virtual machine monitor and > not on Linux or Windows (like VMWare). So the Linux instance (or even > multiple of them) will run in parallel to the OpenBSD domain. Christoph has OpenBSD running as DOMU on Xen 2.0, but DOM0 is working, too. There are more things to consider. Contact me for details if you are interested. -m
Re: BSD-licensed Camellia 128-bit block cipher
On Thu, Apr 20, 2006 at 11:44:07AM +0300, Alexey E. Suslikov wrote: > Camellia was certified as the IETF standard cipher (Proposed > Standard) for SSL/TLS cipher suites (RFC4132) and IPsec (RFC4312). but there's no reason to add more ciphers. there are more then enough already.
Re: DPD isakmpd question
On Wed, Feb 15, 2006 at 06:11:41PM -0500, Matthew Closson wrote: > Hello, > > If you enable RFC3706 - Dead Peer Detection in isakmpd.conf, what is the > result of a peer-failing the DPD check. Will it Start over with Phase1 > negotiations again for that ISAKMP peer, or will it simply remove the SA > and cookies and not try to renegotiate. If anyone know off hand, thanks. it will remove the peer and renegotiate if triggered by Connections=
Re: *STUPID* IPSEC Routing Bug - No Default Gateway?!
On Tue, Dec 06, 2005 at 12:14:20AM -0500, Brian A. Seklecki wrote: > OpenBSD requires that gateway A and gateway B have a default route > declared no, you just need a route to the destination, this is a known but and there's no simple fix. however, just create a network route for the peer that points back to the sender. this way you avoid sending out unencrypted traffic if the ipsec tunnels are down. -m
Re: ISAKMPD errors n. 8 and n. 118
On Thu, Nov 10, 2005 at 11:30:58AM +0100, [EMAIL PROTECTED] wrote: > -bash-3.00# ipsecadm show > sadb_dump: satype esp vers 2 len 38 seq 0 pid 0 > errno 8: Exec format error > sa: spi 0x1c5551f1 auth hmac-sha1 enc aes that's a bug in ipsecadm show.
Re: ppp over ssh
recompiling sshd with includes.h:#define USE_PIPES 1 removed would also help. i think it's better to fix ppp(8)
Re: setting mtu on sis
it will work in 3.8 and later. On Tue, Aug 30, 2005 at 12:14:32AM +0200, [EMAIL PROTECTED] wrote: > Hello! > >Can you please confirm if it is possible to set the mtu on cards > using the sis driver (I have a Netgear FA311, based on the DP 83816 > chip)? > >I am trying to change the mtu with: > > # ifconfig sis1 192.168.0.3 netmask 255.255.255.0 mtu 1444 > > but keep getting a > > SIOCSIFMTU: Invalid argument > > error. Thanks in advance for your replies. > > --- > Rob > > > > > Libero Flat, sempre a 4 Mega a 19,95 euro al mese! > Abbonati subito su http://www.libero.it
Re: qemu and tun device
On Tue, Aug 02, 2005 at 05:02:05PM +0200, umaxx wrote: > # ifconfig tun0 create > # ifconfig tun0 10.0.0.1 10.0.0.2 up try ifconfig tun0 10.0.0.1 netmask 255.255.255.0 link0
Re: ipsec bump-in-the-wire transport mode
check brconfig(8) link2 Setting this flag causes all packets to be passed on to ipsec(4) for processing, based on the policies established by the adminis- trator using the ipsecadm(8) command. If appropriate security associations (SAs) exist, they will be used to encrypt or decrypt the packets. Otherwise, any key management daemons such as isakmpd(8) that are running on the bridge will be invoked to es- tablish the necessary SAs. These daemons have to be configured as if they were running on the host whose traffic they are pro- tecting (i.e., they need to have the appropriate authentication and authorization material, such as keys and certificates, to im- personate the protected host(s)). however, AFAIK, it's only working with static IPsec keys. On Wed, Jul 20, 2005 at 01:56:47AM +0200, Juraj Bednar wrote: > Hello, > > I'm fairly new to OpenBSD. I need to create a simple IPSec setup, > which is (as I learned) called "bump-in-the-wire". Basically, I have > OpenBSD box with two ethernet interfaces bridged together. I want to > protect communication with one particular server in _transport_ mode > with IPSec. That means creating a security association and > establishing connection. I was not able to find a good documentation > on how to do this. > > > IP1 <-(openbsd bridge)--> IP2 > ^ ^ >safe ethernetnot safe ethernet > > openbsd bridge does not have an ip address. If it sees that there's a > packet coming to IP2, it quickly establishes an IPSec SA in transport > mode with just this single IP address and sends all the packets > encrypted. So the communication between IP1 and IP2 never goes > unencrypted through unsafe ethernet. It should pass all other traffic > unmodified. > > Is there some example setup or any pointer how could I make this work? > > I found about the terminology and this possibility here: > http://www.thought.net/jason/bridgepaper/node9.html > > but there's no documentation on how to actually do this :(. Simple > googling did not help. > > > Thanks, > > Juraj.
Re: connect() taking 6 seconds?
the TCP client reuses a source port and sends a SYN while the server still has the old TIME_WAIT state, so the server does not send a SYN/ACK. after 6 seconds the client retransmits the SYN and the connect succeeds. so there are 2 problems: 1) the client reuses the port too soon. 2) the server could accept the SYN during TIME_WAIT (it did in the old days, but because tcp clients now use random ISS the server only accepts 50% of SYNs in TIME_WAIT). -m On Mon, Jul 04, 2005 at 04:31:43PM -0400, Adam wrote: > I used http_load to test out lighttpd's performance (both installed > from ports), and noticed that sometimes connect takes 6 seconds: > > $ http_load -parallel 10 -seconds 10 urllist.txt > 1974 fetches, 10 max parallel, 629706 bytes, in 10.0099 seconds > 319 mean bytes/connection > 197.205 fetches/sec, 62908.5 bytes/sec > msecs/connect: 30.4779 mean, 5999.75 max, 0.036 min > msecs/first-response: 1.81685 mean, 88.687 max, 0.127 min > > Just to make sure it wasn't a lighttpd or http_load problem, I tried > the default apache included in openbsd, as well as using ab instead of > http_load. I still get a few slow connects, always very close to 6 > seconds. > > The problem exists on both my laptop running the July 2 snapshot, and a > server running a 3.6 snapshot from back in September. On both machines > I tried running the tests from localhost and over the network, both > with the same results. PF is disabled on both machines, and they are > both running GENERIC kernels. Any ideas what could be causing this? > > Thanks > Adam
