Since, as it seems, this list is not the appropriate place for asking
ikev2 related questions, could anybody please direct me as to where such
a place would be (mailing list, irc, etc.)?
Thanks again!
On 17/02/2016 11:57 πμ, George Mamalakis wrote:
On 16/02/2016 11:59 πμ, George Mamalakis wrote:
Hi all!
I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to
allow remote access to my local network from various, road-warrior
client "types" (MS Windows, Linux's, BSD's). My example local network
is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4.
I've read various guides on the Internet regarding analogous setups,
but all of them were discussing about MS Windows clients. I'm trying
to test my setup with an OpenBSD 5.8 client but I fail, and next I'd
like to test it with a FreeBSD and a Linux client to see if it works.
My /etc/iked.conf looks like this:
ikev2 passive esp \
from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \
psk mypass \
config address 10.10.10.5
My client's /etc/iked.conf looks like this:
ikev2 active esp \
from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \
psk lala123
which is based on an old email of this list (at around 2012), and as
I explained earlier, it doesn't work. What happens is that when I try
to access 10.0.0.1 from my client, the specific traffic is not
passing from enc0 but is rather passing directly from the egress
interface to its default route. Now, as it seems, this is a
routing/flows issue, but I am unsure as to how to address it.
ipsecctl -sa on both machines looks good (or at least I think it does):
server:
# ipsecctl -sa
FLOWS:
flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid
FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use
flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid
FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require
flow esp out from ::/0 to ::/0 type deny
SAD:
esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256
enc aes-256
esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256
enc aes-256
client:
# ipsecctl -sa
FLOWS:
flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid
FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use
flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid
FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require
flow esp out from ::/0 to ::/0 type deny
SAD:
esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256
enc aes-256
esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256
enc aes-256
As inferred, my client's public IP is 5.6.7.8, and on both machines
ip forwarding is enabled (pf allows all traffic as well).
Any help would be greatly appreciated, and directions towards an
analogous, working, client setup for FreeBSD and Linux would be
equally appreciated.
Thanks all in advance,
George.
I've also tried a different setup (without an internal network) which
works for about a minute or so, and then it stops.
server:
# cat /etc/iked.conf
ikev2 passive esp \
from 10.0.0.0/24 to 0.0.0.0/0 local 1.2.3.4 peer any \
psk mypass
# cat /etc/ipsec.conf
flow esp out from 10.0.0.0/24 to 10.0.0.0/24 type bypass
client:
# cat /etc/iked.conf
ikev2 active esp \
from 0.0.0.0/0 to 10.0.0.0/24 peer 1.2.3.4 \
psk mypass
With this configuration, both client and server are able to access
10.0.0.0/24 (by adding the extra flow in server's /etc/ipsec.conf and
loading it via ipsecctl -f /etc/ipsec.conf), but after a minute or so
the setup stops working. Traffic is reaching the server's enc0
interface and replies are sent to the client via enc0, but the
client's udp port which used to accept packets becomes unreachable
(closes for some reason):
08:00:27:ee:e7:fd 08:00:27:59:7c:d4 0800 178: 1.2.3.4.52586 >
5.6.7.8.58353: udp 136
08:00:27:59:7c:d4 08:00:27:ee:e7:fd 0800 70: 5.6.7.8 > 1.2.3.4: icmp:
5.6.7.8 udp port 58353 unreachable
I'm not sure that running:
# iked -vvd &
on both machines, reveals not additional information, except that the
client checks both incoming and outgoing SA, whereas the server checks
only the incoming:
client:
ikev2_init_ike_sa: "policy1" is already active
ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 54
second(s) ago
pfkey_sa_last_used: last_used 1455636797
ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 54
second(s) ago
ikev2_init_ike_sa: "policy1" is already active
pfkey_sa_last_used: last_used 1455636860
ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 51
second(s) ago
pfkey_sa_last_used: last_used 1455636860
ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 51
second(s) ago
server:
pfkey_sa_last_used: last_used 1455636795
ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 54
second(s) ago
pfkey_sa_last_used: last_used 1455636858
ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 51
second(s) ago
Thanks all for your time and help in advance,
George.
PS. I'm getting the same behaviour even without the additional flow of
/etc/ipsec.conf, so I've ruled it out from a problem candidate.
