GRE(4) is the one to save. GIF(4) might work as well, but my tunnel setting was not correct.
Thanks, Siegfried > On Dec 13, 2018, at 10:15 PM, Zhi-Qiang Lei <zhiqiang....@gmail.com> wrote: > > 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 >> >
