Hi,

I have a very straight forward setup use case that I want to use my
OpenBSD router as a VPN gateway, which will accept IKEv2 road warrior
connections from the Internet and route all traffics through my
router.

I am using a ms-chapv2 authentication and a letsencrypt certificate,
which I can successfully obtain. All my clients are Apple devices
with latest iOS installed. They normally are connected to the Internet
directly without going through this router.

Configuration as below:

user “a” "123456"
user “b” "246810"
user “c” "135791"

set passive 

ikev2 "rw" passive esp \
        from any to 172.20.11.0/24 \
        local any peer any \
        srcid my.fqdn.org \
        eap mschap-v2 \
        config protected-subnet 172.20.10.0/24 \
        config address 172.20.11/0/24 \
        config name-server 172.20.10.1

I use “from any” because I want all traffics to be routed to the
OpenBSD box. And “to 172.20.11.0/24” is the subnet that I use for
VPN allocation. That’s why I also have config address 172.20.11.0/24
in the configuration.

my.fqdn.org is a public IP address which I’ve obtained a domain name
pointing to it.

I have this working flawlessly with all the devices individually.
However, when I tried to connect the 2nd device (user b) while the
1st device (user a) is still connected, the 1st device’s connectivity
will not go through anymore until I disconnect the 2nd device
(user b).

Through some search some of the post recommend I change

“to 172.20.11.0/24” to “to any”

But none of the client can connect anymore.

I further check “ipsecctl -sa” to see what kind of traffic selector
is being established. I noticed that when I connect the 2nd device
(user b), the traffic selector of user (b) replaces that of user (a)
because they’re in the same subnet (172.20.11.0/24) although they have 
different IP addresses assigned.

It looks like in this use case, iked does not narrow down the traffic
selector although it allows multiple addresses to be allocated to
different devices, which kinds of defeats the purpose of the 
“config address” directive.

Is there any way to get around this or it is something that someone
needs to write a patch to fix? (I’m no coder so I am now reverting
to good old IPsec/L2TP for now).

Rgds,

Mike

Reply via email to