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 <zhiqiang....@gmail.com> 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 <simplersolut...@gmail.com> 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 <zhiqiang....@gmail.com> 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 >