Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
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 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 to ! 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 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 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 >>> 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: >
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
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 to ! 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 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 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 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 >>> >>> >>> >> >>
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
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 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 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
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
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 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
