After changed my from-to selectors in iked configuration, the gateway is almost
working.
[VPN Server] /etc/iked.conf:
ikev2 quick passive ipcomp esp \
from 0.0.0.0/0 to 192.168.1.0/24 \
local egress \
ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519
\
childsa enc chacha20-poly130 group curve25519 \
dstid "blackjack.local"
[Gateway] /etc/iked.conf:
ikev2 quick active ipcomp esp \
from 192.168.1.0/24 to $some_network \
local egress peer $vpn_server_ip \
ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519
\
childsa enc chacha20-poly130 group curve25519 \
dstid "asgard.local"
This is truly convenient thanks to the transparency. I don’t even have to mind
the route. However, I still have some issues to add more policies:
I have a blacklist contains the networks I don’t want to apply IPSec. When I
was using OpenVPN, it was done by a pf rule:
pass out quick from <lans> to !<skips> route-to tun0
What is the best practice to do the same in /etc/iked.conf?
My intuitive thoughts were:
[Gateway] /etc/iked.conf:
ikev2 quick active ipcomp esp \
from 192.168.1.0/24 to !$network1 \
… thousands of from-to …
from 192.168.1.0/24 to !$network8000 \
local egress peer $vpn_server_ip \
ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519
\
childsa enc chacha20-poly130 group curve25519 \
dstid "asgard.local"
But ! operator and too many flows are causing error.
> On Dec 12, 2018, at 10:37 PM, Zhi-Qiang Lei <[email protected]> wrote:
>
> Hi Aaron,
>
> Thanks! I also tried gif. But the behavior is quite weird. Through the gif
> devices, the gateway and VPN server can ping each other, while the packets on
> gateway enc0 from the client routing to the gif device always got bad
> checksums. I think it is related to the bugs on gif(4) man page?
>
> "There are many tunnelling protocol specifications, defined differently from
> each other. gif may not interoperate with peers which are based on different
> specifications, and are picky about outer header fields. For example, you
> cannot usually use gif to talk with IPsec devices that use IPsec tunnel mode.”
>
> [Gateway] /etc/hostname.gif0:
> 10.0.0.2 10.0.0.1
>
> [VPN server] /etc/hostname.gif0:
> 10.0.0.1 10.0.0.2
>
> Best regards,
> Siegfried
>
>> On Dec 12, 2018, at 7:39 PM, Aaron Mason <[email protected]> wrote:
>>
>> Hi Siegfried
>>
>> (Maintainers of the IPSec stack and ISAKMPD are welcome to tear my answer
>> apart)
>>
>> IPSec tunnels are, for want of a better term, entirely transparent -
>> the underlying OS and its clients have no idea that it exists. In
>> order to route across an IPSec tunnel, use gif(4) to create an
>> IP-to-IP tunnel between the endpoints. IPSec will encrypt all traffic
>> that goes across it - from there it's a matter of setting up the
>> static routes on either side.
>> On Wed, Dec 12, 2018 at 7:40 AM Zhi-Qiang Lei <[email protected]> wrote:
>>>
>>> I’m building a gateway to encrypt some traffics:
>>>
>>> Client —————> Gateway —————> VPN Server —————> Internet
>>> (192.168.1.16) (10.0.0.2)
>>>
>>>
>>> [Gateway] /etc/iked.conf:
>>>
>>> ikev2 quick active ipcomp esp \
>>> from 10.0.0.2 to 0.0.0.0/0 \
>>> local egress peer $vpn_server_ip \
>>> ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group
>>> curve25519 \
>>> childsa enc chacha20-poly130 group curve25519 \
>>> dstid "asgard.local"
>>>
>>> [VPN Server] /etc/iked.conf:
>>>
>>> ikev2 quick passive ipcomp esp \
>>> from 0.0.0.0/0 to 10.0.0.2 \
>>> local egress \
>>> ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group
>>> curve25519 \
>>> childsa enc chacha20-poly130 group curve25519 \
>>> dstid "blackjack.local"
>>>
>>> The SA has been established. When I ping 10.0.0.2 on VPN Server and tcpdump
>>> on gateway enc0 I got:
>>>
>>> # tcpdump -envps 1500 -i enc0 -l
>>> tcpdump: listening on enc0, link-type ENC
>>> 03:48:20.778584 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip >
>>> $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:0)
>>> [icmp cksum ok] (ttl 255, id 60419, len 84) (ttl 50, id 59144, len 104)
>>> 03:48:21.788330 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip >
>>> $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:1)
>>> [icmp cksum ok] (ttl 255, id 1688, len 84) (ttl 50, id 31496, len 104)
>>>
>>> How can I route the packets from the client to the VPN server on the
>>> gateway? When I was using OpenVPN, I did the routing in pf.conf:
>>>
>>> pass in quick from 192.168.1.0/24 to !192.168.1.0/24 route-to tun0
>>> pass out quick on tun0 from 192.168.1.0/24 to any nat-to tun0
>>>
>>> However, there is no tunnel device created after the SA is established on
>>> OpenBSD. Did I miss something to create it?
>>>
>>> Best regards,
>>> Siegfried
>>>
>>>
>>>
>>
>>
>> --
>> Aaron Mason - Programmer, open source addict
>> I've taken my software vows - for beta or for worse
>
