Re: reverse proxy with relayd(8) (but not nginx)

[Alistair Meney]

There's many example configs online, one example like yours is at

https://www.reddit.com/r/openbsd/comments/3qb2c4/some_observations_about_relayd/



On Thu, Jun 29, 2017 at 4:40 PM, Manuel Giraud  wrote:
> Hi,
>
> I'd like to setup a http reverse proxy where http://foo.org/someapp is
> forwarded to 127.0.0.1:8081 and http://foo.org/* is forwarded to
> somewhere else.
>
> AFAIU, it is not possible with httpd(8) so I'm trying to do this with
> relayd(8). There is an example in httpfiler protocol in
> /etc/examples/relayd.conf that does this to block an url:
>
> # Block disallowed sites
> match request label "URL filtered!"
> block request quick url "www.example.com/" value "*"
>
> But, I can't make it to forward to a server and port. Does anyone have
> such a config?
> --
> Manuel Giraud
>

Re: Jumbo frames on Octeon

[Joe Holden]

On 29/06/2017 12:06, Visa Hankala wrote:
> On Tue, Jun 27, 2017 at 07:57:42PM +0100, Joe Holden wrote:
>> It looks like setting the mtu on cnmac interfaces doesn't quite work as
>> expected, whatever the mtu is set to the upper limit appears to be 1510
>> as although it will transmit frames of any arbitary size (e.g 2000
>> bytes), the reply never makes it back (confirmed from an attached box)
>> unless the frame is =< 1510.
> I just committed a patch that lets MTU change happen on the fly
> with cnmac(4).
>
> If you are using release 6.1, you have to temporarily bring down
> the interface, or reboot, when changing MTU on a cnmac(4) interface.
>
Ah excellent, cheers!

Re: ipmi driver broken

[Paul B. Henson]

> From: Ted Unangst
> Sent: Wednesday, June 28, 2017 8:50 PM
> 
> i'm afraid i won't make a very good ipmi maintainer, but i think i applied the
> patch in the right spot.

Cool, thanks; much appreciated.

Re: ipmi driver broken

[Paul B. Henson]

> From: Theo de Raadt
> Sent: Wednesday, June 28, 2017 8:41 PM
> 
> If you want it working, you will need to get it fixed.  On all
> machines, so that we can renable it.

I definitely don't want to be one of those entitled people demanding work
from developers without providing anything that you trounce upon ;). But
that's a bit of a big ask, make it work on all machines? I've got four
different models of supermicro servers that I certainly can do testing on,
although as I said, on these particular servers as far as I can tell (other
than the watchdog) the driver seems to work fine.

> Let me explain how we work.

I understand; really, I'm not asking you guys to invest a significant amount
of effort in improving the driver, or even technically "fixing" any new
issues or problems with it. I was only kindly requesting that you put back a
line that appears to have accidentally been deleted a few revisions ago that
broke it. So unless you're intentionally sabotaging it in preparation for
the ritual sacrifice :)?

It's too bad nobody else finds value in it; it provides sensors that aren't
otherwise available, provides access to the system event log for event data,
allows access to the management interface without needing to go through the
network, and ideally would allow access to the hardware watchdog.
Unfortunately I don't have expertise in low level hardware device driver
development so while I could be a tester I can't be a primary maintainer. So
if you guys end up scrapping it, I will be sad but that's the way it is. But
until then, given it works for me, it doesn't hurt to use it :). Or to ask
for one line to be put back so it would work in the shipped kernel; unless I
suppose said request results in it getting scrapped ;).

Thanks.

New OpenBSD meetUP group at Quebec city

[Franck Rupin]

Hi everyone,

few words to let you know that I recently  opened up an OpenBSD meetUP
group at Quebec city. If anyone of you wants to join us you are very
welcome.

We would like to schedule the first meeting in July.

Here the link to the group: https://www.meetup.com/Quebec-OpenBSD-Meetup/

Greetings,
Franck

reverse proxy with relayd(8) (but not nginx)

[Manuel Giraud]

Hi,

I'd like to setup a http reverse proxy where http://foo.org/someapp is
forwarded to 127.0.0.1:8081 and http://foo.org/* is forwarded to
somewhere else.

AFAIU, it is not possible with httpd(8) so I'm trying to do this with
relayd(8). There is an example in httpfiler protocol in
/etc/examples/relayd.conf that does this to block an url:

# Block disallowed sites
match request label "URL filtered!"
block request quick url "www.example.com/" value "*"

But, I can't make it to forward to a server and port. Does anyone have
such a config?
-- 
Manuel Giraud

BGP vpnv4 prefixes in RIB, not in FIB

[brad hendrickse]

Hi folks,

I have a problem with routes learnt from BGP vpnv4 not being inserted into 
the FIB I'd expect. A tcpdump on the OpenBSD box shows we are receiving 
the prefixes (from a Cisco) with the labels intact. The MPE interface is 
configured in rdomain 1 with MPLS label 200. The loopback interface lo1 
was automatically created as mentioned in the 6.1 changelog.


We have this working on OpenBSD 5.4. My colleagues have seen this same 
behaviour since OpenBSD 5.9 explaining why we're still using 5.4. All 
configs and output below is from OpenBSD 6.1.


Any help with this would be much appreciated.

Thank you


/etc/bgpd.conf:
/
# global configuration
AS 65002
router-id 192.168.1.2
holdtime 180
listen on 192.168.1.2
log updates

group "peering AS65520" {
remote-as 65520
neighbor 192.168.1.1 {
descr   "AS 65520"
announce capabilities yes
announce self
announce IPv4 vpn
announce refresh yes
announce restart yes
}
}

rdomain 1 {
descr "200:1"
rd 200:1
import-target rt 200:1
export-target rt 200:1
depend on mpe1
network 10.10.10.2/32
}


/
bash-4.4# bgpctl show summary
Neighbor   ASMsgRcvdMsgSent  OutQ Up/Down 
State/PrfRcvd

AS 6552065520 30 27 0 00:23:23  4


/
bash-4.4# bgpctl show rib
flags: * = Valid, > = Selected, I = via IBGP, A = Announced, S = Stale
origin: i = IGP, e = EGP, ? = Incomplete

flags destination  gateway  lpref   med aspath origin
AI*>  rd 200:1 10.10.10.2/32 rd 0:0 0.0.0.0 100 0 i
*>rd 200:1 100.10.0.0/24 192.168.1.1100 0 65520 ?
*>rd 200:1 155.10.0.0/24 192.168.1.1100 0 65520 ?
*>rd 200:1 200.10.0.0/24 192.168.1.1100 0 65520 ?
*>rd 200:1 210.10.0.0/24 192.168.1.1100 0 65520 ?


The next-hop for 155.10.0.0/24 is pingable
/
bash-4.4# ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.536 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=255 time=0.604 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=255 time=0.587 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.536/0.576/0.604/0.029 ms


/
bash-4.4# bgpctl show fib
flags: * = valid, B = BGP, C = Connected, S = Static, D = Dynamic
   N = BGP Nexthop reachable via this route R = redistributed
   r = reject route, b = blackhole route

flags prio destination  gateway
*S   8 0.0.0.0/010.0.2.1
*C   4 10.0.2.0/24  link#1
*C   0 127.0.0.0/8  link#0
*CN  4 192.168.1.0/30   link#2
*S   8 192.168.2.1/32   192.168.1.1
*1 192.168.2.2/32   192.168.2.2
*S  r8 224.0.0.0/4  127.0.0.1
*S  r8 ::/96::1
*S  r8 ::/104   ::1
*C   0 ::1/128  link#0
*1 ::1/128  ::1
*S  r8 ::127.0.0.0/104  ::1
*S  r8 ::224.0.0.0/100  ::1
*S  r8 ::255.0.0.0/104  ::1
*S  r8 :::0.0.0.0/96::1
*S  r8 2002::/24::1
*S  r8 2002:7f00::/24   ::1
*S  r8 2002:e000::/20   ::1
*S  r8 2002:ff00::/24   ::1
*S  r8 fe80::/10::1
*1 fe80:4::1/128fe80:4::1
*S  r8 fec0::/10::1
*S  r8 ff01::/16::1
*4 ff01:4::/32  ::1
*S  r8 ff02::/16::1
*4 ff02:4::/32  ::1


The tables are coupled
/
bash-4.4# bgpctl show table
Table Description  State
0 Loc-RIB  coupled
1 200:1coupled


I don't expect to be able to ping the destination, but not expecting "No 
route to host"

/
bash-4.4# ping -V 1 155.10.0.1
PING 155.10.0.1 (155.10.0.1): 56 data bytes
ping: sendmsg: No route to host
ping: wrote 155.10.0.1 64 chars, ret=-1
ping: sendmsg: No route to host
ping: wrote 155.10.0.1 64 chars, ret=-1
ping: sendmsg: No route to host


/
bash-4.4# ifconfig -a
lo0: flags=88049 mtu 32768
index 4 priority 0 llprio 3
groups: lo
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 192.168.2.2 netmask 0x
xnf0: flags=8843 mtu 1500
lladdr 4a:2f:aa:55:45:89
index 1 priority 0 llprio 3
groups: egress
media: Ethernet manual
status: active
inet 10.0.2.38 netmask 0xff00 broadcast 10.0.2.255
xnf1: flags=88843 mtu 1500
lladdr 3a:fe:55:6f:ed:10
index 2 priority 0 llprio 3
media: Ethernet manual
status: active
inet 192.168.1.2 netmask 0xfffc broadcast 

Re: OpenBSD IPSec setup

[Jasper Siepkes]

I know I'm venturing of topic but I can't resist. 

I'll go for OpenBSD with IPSec any day. Only last week OpenVPN had a security
fallout:

https://community.openvpn.net/openvpn/wiki/VulnerabilitiesFixedInOpenVPN243

One of these exploits even has a high probability of being remotely exploitable.


-Jasper

> Op 29 juni 2017 om 12:59 schreef Marko Cupać :
> 
> On Thu, 29 Jun 2017 12:32:01 +0200
> Luescher Claude  wrote:
> 
> > Why are you using ipsec in the 21th century:
> 
> Because it is in OpenBSD base. Because, at least on OpenBSD, it
> integrates great with the rest of networking ecosystem (carp, sasync,
> ospf, pf etc.) Because it pays my bills for more than a decade
> now. Because my users are satisfied. Because my employers are
> satisfied. Because I haven't encountered anything better for
> site-to-site VPNs so far (I also use both OpenVPN and npppd for my road
> warriors' needs).
> 
> I could go on.
> -- 
> Before enlightenment - chop wood, draw water.
> After enlightenment - chop wood, draw water.
> 
> Marko Cupać
> https://www.mimar.rs/

>

[no subject]

[John Ireland]

unsubscribe misc

Re: Jumbo frames on Octeon

[Visa Hankala]

On Tue, Jun 27, 2017 at 07:57:42PM +0100, Joe Holden wrote:
> It looks like setting the mtu on cnmac interfaces doesn't quite work as
> expected, whatever the mtu is set to the upper limit appears to be 1510
> as although it will transmit frames of any arbitary size (e.g 2000
> bytes), the reply never makes it back (confirmed from an attached box)
> unless the frame is =< 1510.

I just committed a patch that lets MTU change happen on the fly
with cnmac(4).

If you are using release 6.1, you have to temporarily bring down
the interface, or reboot, when changing MTU on a cnmac(4) interface.

Re: OpenBSD IPSec setup

[Marko Cupać]

On Thu, 29 Jun 2017 12:32:01 +0200
Luescher Claude  wrote:

> Why are you using ipsec in the 21th century:

Because it is in OpenBSD base. Because, at least on OpenBSD, it
integrates great with the rest of networking ecosystem (carp, sasync,
ospf, pf etc.) Because it pays my bills for more than a decade
now. Because my users are satisfied. Because my employers are
satisfied. Because I haven't encountered anything better for
site-to-site VPNs so far (I also use both OpenVPN and npppd for my road
warriors' needs).

I could go on.
-- 
Before enlightenment - chop wood, draw water.
After  enlightenment - chop wood, draw water.

Marko Cupać
https://www.mimar.rs/

Re: OpenBSD IPSec setup

[Daniel Gracia]

My two-cents:

* IPsec hardware crypto is supported for a lot more platforms than OpenVPN
out of the box, so IPsec uses to be noticeably faster. i.e, and UBNT
Edgerouter Lite will give me about 20Mbps over OpenVPN vs almost 1Gbps
(line rate) over IPsec.
* IPsec code in OpenBSD is audited, OpenVPN is a port.

Regards!


2017-06-29 12:32 GMT+02:00 Luescher Claude :

> Why are you using ipsec in the 21th century:
>
> https://serverfault.com/questions/202917/openvpn-vs-ipsec-
> pros-and-cons-what-to-use
>
> I see no pros here just cons unless you need to setup a vpn with some
> crappy old device which should be just switched out with an obsd box anyway
> :)
>
>
> On 2017-06-29 11:29, Liviu Daia wrote:
>
>> On 29 June 2017, Liviu Daia  wrote:
>> [...]
>>
>>> On the server:
>>>
>>> # iked -d
>>> ikev2_recv: IKE_SA_INIT request from initiator 89.136.163.27:500 to
>>> x.y.z.t:500 policy 'sb1' id 0, 510 bytes
>>> ikev2_msg_send: IKE_SA_INIT response from x.y.z.t:500 to
>>> 89.136.163.27:500 msgid 0, 471 bytes
>>> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to
>>> x.y.z.t:500 policy 'sb1' id 1, 1520 bytes
>>> ikev2_msg_send: IKE_AUTH response from x.y.z.t:500 to 89.136.163.27:500
>>> msgid 1, 1440 bytes
>>> sa_state: VALID -> ESTABLISHED from 89.136.163.27:500 to x.y.z.t:500
>>> policy 'sb1'
>>> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to
>>> x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
>>> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to
>>> x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
>>> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to
>>> x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
>>> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to
>>> x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
>>>
>>> On the home router:
>>>
>>> # iked -d
>>> set_policy: could not find pubkey for /etc/iked/pubkeys/ipv4/x.y.z.t
>>> ikev2_msg_send: IKE_SA_INIT request from 89.136.163.27:500 to
>>> x.y.z.t:500 msgid 0, 510 bytes
>>> ikev2_recv: IKE_SA_INIT response from responder x.y.z.t:500 to
>>> 89.136.163.27:500 policy 'home' id 0, 471 bytes
>>> ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500
>>> msgid 1, 1520 bytes
>>> ikev2_recv: IKE_AUTH response from responder x.y.z.t:500 to
>>> 89.136.163.27:500 policy 'home' id 1, 1440 bytes
>>> ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
>>> ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500
>>> msgid 2, 1520 bytes
>>>
>>> The warning about pubkey doesn't go away if I copy the server's
>>> certificate to /etc/iked/pubkeys/ipv4/x.y.z.t, nor if I install it in
>>> /etc/iked/certs.  And then there's this, which doesn't look normal:
>>>
>>> ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
>>>
>> [...]
>>
>> Ok this post sent me on the right course:
>>
>> http://www.going-flying.com/blog/mikrotik-openbsd-ikev2.html
>>
>> Here's what I did:
>>
>> cd /etc/ssl/vpn/private
>> openssl rsa -in x.y.z.t.key -pubout -out ~/x.y.z.t
>> ... copy ~/x.y.z.t to /etc/iked/pubkeys/ipv4 on the home router.
>>
>> After that the VPN works, I can send packets from a machine at home
>> and I'm seeing them on enc0 on the remote server:
>>
>> # tcpdump -n -i enc0
>>
>> tcpdump: listening on enc0, link-type ENC
>> 05:14:04.103254 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2
>> > 10.0.0.102: icmp: echo request (encap)
>> 05:14:05.134106 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2
>> > 10.0.0.102: icmp: echo request (encap)
>> 05:14:06.137831 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2
>> > 10.0.0.102: icmp: echo request (encap)
>> ...
>>
>> However, I'm now running into what seems to be a firewall problem,
>> an I'm getting no answer.  I do have "pass quick inet proto esp" on both
>> VPN ends.  Any idea where / how to fix this?
>>
>> Also, IPs aren't assigned automatically to the VPN ends.  I can
>> add them to hostname.enc0, but is this the right thing to do?  I tried
>> adding a line
>>
>> config address 10.0.0.102
>>
>> to /etc/iked.conf, but that's rejected as a syntax error.  A clue stick
>> again please?
>>
>> Regards,
>>
>> Liviu Daia
>>
>
>

Re: OpenBSD IPSec setup

[Philipp Buehler]

Am 29.06.2017 12:32 schrieb Luescher Claude:

Why are you using ipsec in the 21th century:

https://serverfault.com/questions/202917/openvpn-vs-ipsec-pros-and-cons-what-to-use


just a week after four CVEs (incl RCE) in openvpn? Great.

--
pb

Re: OpenBSD IPSec setup

[Luescher Claude]

Why are you using ipsec in the 21th century:

https://serverfault.com/questions/202917/openvpn-vs-ipsec-pros-and-cons-what-to-use

I see no pros here just cons unless you need to setup a vpn with some 
crappy old device which should be just switched out with an obsd box 
anyway :)


On 2017-06-29 11:29, Liviu Daia wrote:

On 29 June 2017, Liviu Daia  wrote:
[...]

On the server:

# iked -d
ikev2_recv: IKE_SA_INIT request from initiator 89.136.163.27:500 to 
x.y.z.t:500 policy 'sb1' id 0, 510 bytes
ikev2_msg_send: IKE_SA_INIT response from x.y.z.t:500 to 
89.136.163.27:500 msgid 0, 471 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to 
x.y.z.t:500 policy 'sb1' id 1, 1520 bytes
ikev2_msg_send: IKE_AUTH response from x.y.z.t:500 to 
89.136.163.27:500 msgid 1, 1440 bytes
sa_state: VALID -> ESTABLISHED from 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1'
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to 
x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to 
x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to 
x.y.z.t:500 policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to 
x.y.z.t:500 policy 'sb1' id 2, 1520 bytes


On the home router:

# iked -d
set_policy: could not find pubkey for /etc/iked/pubkeys/ipv4/x.y.z.t
ikev2_msg_send: IKE_SA_INIT request from 89.136.163.27:500 to 
x.y.z.t:500 msgid 0, 510 bytes
ikev2_recv: IKE_SA_INIT response from responder x.y.z.t:500 to 
89.136.163.27:500 policy 'home' id 0, 471 bytes
ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 
msgid 1, 1520 bytes
ikev2_recv: IKE_AUTH response from responder x.y.z.t:500 to 
89.136.163.27:500 policy 'home' id 1, 1440 bytes

ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 
msgid 2, 1520 bytes


The warning about pubkey doesn't go away if I copy the server's
certificate to /etc/iked/pubkeys/ipv4/x.y.z.t, nor if I install it in
/etc/iked/certs.  And then there's this, which doesn't look normal:

ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG

[...]

Ok this post sent me on the right course:

http://www.going-flying.com/blog/mikrotik-openbsd-ikev2.html

Here's what I did:

cd /etc/ssl/vpn/private
openssl rsa -in x.y.z.t.key -pubout -out ~/x.y.z.t
... copy ~/x.y.z.t to /etc/iked/pubkeys/ipv4 on the home 
router.


After that the VPN works, I can send packets from a machine at home
and I'm seeing them on enc0 on the remote server:

# tcpdump -n -i enc0

tcpdump: listening on enc0, link-type ENC
05:14:04.103254 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2
> 10.0.0.102: icmp: echo request (encap)
05:14:05.134106 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2
> 10.0.0.102: icmp: echo request (encap)
05:14:06.137831 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2
> 10.0.0.102: icmp: echo request (encap)
...

However, I'm now running into what seems to be a firewall problem,
an I'm getting no answer.  I do have "pass quick inet proto esp" on 
both

VPN ends.  Any idea where / how to fix this?

Also, IPs aren't assigned automatically to the VPN ends.  I can
add them to hostname.enc0, but is this the right thing to do?  I tried
adding a line

config address 10.0.0.102

to /etc/iked.conf, but that's rejected as a syntax error.  A clue stick
again please?

Regards,

Liviu Daia

Re: OpenBSD IPSec setup

[Liviu Daia]

On 29 June 2017, Liviu Daia  wrote:
[...]
> On the server:
> 
> # iked -d
> ikev2_recv: IKE_SA_INIT request from initiator 89.136.163.27:500 to 
> x.y.z.t:500 policy 'sb1' id 0, 510 bytes
> ikev2_msg_send: IKE_SA_INIT response from x.y.z.t:500 to 89.136.163.27:500 
> msgid 0, 471 bytes
> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
> policy 'sb1' id 1, 1520 bytes
> ikev2_msg_send: IKE_AUTH response from x.y.z.t:500 to 89.136.163.27:500 msgid 
> 1, 1440 bytes
> sa_state: VALID -> ESTABLISHED from 89.136.163.27:500 to x.y.z.t:500 policy 
> 'sb1'
> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
> policy 'sb1' id 2, 1520 bytes
> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
> policy 'sb1' id 2, 1520 bytes
> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
> policy 'sb1' id 2, 1520 bytes
> ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
> policy 'sb1' id 2, 1520 bytes
> 
> On the home router:
> 
> # iked -d
> set_policy: could not find pubkey for /etc/iked/pubkeys/ipv4/x.y.z.t
> ikev2_msg_send: IKE_SA_INIT request from 89.136.163.27:500 to x.y.z.t:500 
> msgid 0, 510 bytes
> ikev2_recv: IKE_SA_INIT response from responder x.y.z.t:500 to 
> 89.136.163.27:500 policy 'home' id 0, 471 bytes
> ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 msgid 
> 1, 1520 bytes
> ikev2_recv: IKE_AUTH response from responder x.y.z.t:500 to 89.136.163.27:500 
> policy 'home' id 1, 1440 bytes
> ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
> ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 msgid 
> 2, 1520 bytes
> 
> The warning about pubkey doesn't go away if I copy the server's
> certificate to /etc/iked/pubkeys/ipv4/x.y.z.t, nor if I install it in
> /etc/iked/certs.  And then there's this, which doesn't look normal:
> 
> ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
[...]

Ok this post sent me on the right course:

http://www.going-flying.com/blog/mikrotik-openbsd-ikev2.html

Here's what I did:

cd /etc/ssl/vpn/private
openssl rsa -in x.y.z.t.key -pubout -out ~/x.y.z.t
... copy ~/x.y.z.t to /etc/iked/pubkeys/ipv4 on the home router.

After that the VPN works, I can send packets from a machine at home
and I'm seeing them on enc0 on the remote server:

# tcpdump -n -i enc0
   
tcpdump: listening on enc0, link-type ENC
05:14:04.103254 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2 > 
10.0.0.102: icmp: echo request (encap)
05:14:05.134106 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2 > 
10.0.0.102: icmp: echo request (encap)
05:14:06.137831 (authentic,confidential): SPI 0xd51e3910: 192.168.7.2 > 
10.0.0.102: icmp: echo request (encap)
...

However, I'm now running into what seems to be a firewall problem,
an I'm getting no answer.  I do have "pass quick inet proto esp" on both
VPN ends.  Any idea where / how to fix this?

Also, IPs aren't assigned automatically to the VPN ends.  I can
add them to hostname.enc0, but is this the right thing to do?  I tried
adding a line

config address 10.0.0.102

to /etc/iked.conf, but that's rejected as a syntax error.  A clue stick
again please?

Regards,

Liviu Daia

Re: OpenBSD IPSec setup

[Liviu Daia]

On 28 June 2017, Rupert Gallagher  wrote:
> You need a server-signed certificate.

Ok, let me redo this from scratch:

(1) On the server:

ikectl ca vpn create
ikectl ca vpn install
ikectl ca vpn certificate x.y.z.t create
ikectl ca vpn certificate x.y.z.t install
ikectl ca vpn certificate 10.0.0.1 create
ikectl ca vpn certificate 10.0.0.1 export

... copy 10.0.0.1.tgz to the home router

(2) On the home router:

tar -C /etc/iked -xzpf 10.0.0.1.tgz

Nothing seems to have changed:

On the server:

# iked -d
ikev2_recv: IKE_SA_INIT request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 0, 510 bytes
ikev2_msg_send: IKE_SA_INIT response from x.y.z.t:500 to 89.136.163.27:500 
msgid 0, 471 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 1, 1520 bytes
ikev2_msg_send: IKE_AUTH response from x.y.z.t:500 to 89.136.163.27:500 msgid 
1, 1440 bytes
sa_state: VALID -> ESTABLISHED from 89.136.163.27:500 to x.y.z.t:500 policy 
'sb1'
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes
ikev2_recv: IKE_AUTH request from initiator 89.136.163.27:500 to x.y.z.t:500 
policy 'sb1' id 2, 1520 bytes

On the home router:

# iked -d
set_policy: could not find pubkey for /etc/iked/pubkeys/ipv4/x.y.z.t
ikev2_msg_send: IKE_SA_INIT request from 89.136.163.27:500 to x.y.z.t:500 msgid 
0, 510 bytes
ikev2_recv: IKE_SA_INIT response from responder x.y.z.t:500 to 
89.136.163.27:500 policy 'home' id 0, 471 bytes
ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 msgid 1, 
1520 bytes
ikev2_recv: IKE_AUTH response from responder x.y.z.t:500 to 89.136.163.27:500 
policy 'home' id 1, 1440 bytes
ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG
ikev2_msg_send: IKE_AUTH request from 89.136.163.27:500 to x.y.z.t:500 msgid 2, 
1520 bytes

The warning about pubkey doesn't go away if I copy the server's
certificate to /etc/iked/pubkeys/ipv4/x.y.z.t, nor if I install it in
/etc/iked/certs.  And then there's this, which doesn't look normal:

ikev2_ike_auth_recv: unexpected auth method RSA_SIG, was expecting SIG

I'm using 6.1 release on the server, and the current snapshot on the
home router:

OpenBSD sb1.x.net 6.1 GENERIC#10 amd64
OpenBSD router.x.net 6.1 GENERIC.MP#44 amd64

Regards,

Liviu Daia