Re: OpenBSD 5.8 ikev2 road warrior setup with various clients
Since, as it seems, this list is not the appropriate place for asking ikev2 related questions, could anybody please direct me as to where such a place would be (mailing list, irc, etc.)? Thanks again! On 17/02/2016 11:57 πμ, George Mamalakis wrote: On 16/02/2016 11:59 πμ, George Mamalakis wrote: Hi all! I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to allow remote access to my local network from various, road-warrior client "types" (MS Windows, Linux's, BSD's). My example local network is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4. I've read various guides on the Internet regarding analogous setups, but all of them were discussing about MS Windows clients. I'm trying to test my setup with an OpenBSD 5.8 client but I fail, and next I'd like to test it with a FreeBSD and a Linux client to see if it works. My /etc/iked.conf looks like this: ikev2 passive esp \ from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \ psk mypass \ config address 10.10.10.5 My client's /etc/iked.conf looks like this: ikev2 active esp \ from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \ psk lala123 which is based on an old email of this list (at around 2012), and as I explained earlier, it doesn't work. What happens is that when I try to access 10.0.0.1 from my client, the specific traffic is not passing from enc0 but is rather passing directly from the egress interface to its default route. Now, as it seems, this is a routing/flows issue, but I am unsure as to how to address it. ipsecctl -sa on both machines looks good (or at least I think it does): server: # ipsecctl -sa FLOWS: flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 client: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 As inferred, my client's public IP is 5.6.7.8, and on both machines ip forwarding is enabled (pf allows all traffic as well). Any help would be greatly appreciated, and directions towards an analogous, working, client setup for FreeBSD and Linux would be equally appreciated. Thanks all in advance, George. I've also tried a different setup (without an internal network) which works for about a minute or so, and then it stops. server: # cat /etc/iked.conf ikev2 passive esp \ from 10.0.0.0/24 to 0.0.0.0/0 local 1.2.3.4 peer any \ psk mypass # cat /etc/ipsec.conf flow esp out from 10.0.0.0/24 to 10.0.0.0/24 type bypass client: # cat /etc/iked.conf ikev2 active esp \ from 0.0.0.0/0 to 10.0.0.0/24 peer 1.2.3.4 \ psk mypass With this configuration, both client and server are able to access 10.0.0.0/24 (by adding the extra flow in server's /etc/ipsec.conf and loading it via ipsecctl -f /etc/ipsec.conf), but after a minute or so the setup stops working. Traffic is reaching the server's enc0 interface and replies are sent to the client via enc0, but the client's udp port which used to accept packets becomes unreachable (closes for some reason): 08:00:27:ee:e7:fd 08:00:27:59:7c:d4 0800 178: 1.2.3.4.52586 > 5.6.7.8.58353: udp 136 08:00:27:59:7c:d4 08:00:27:ee:e7:fd 0800 70: 5.6.7.8 > 1.2.3.4: icmp: 5.6.7.8 udp port 58353 unreachable I'm not sure that running: # iked -vvd & on both machines, reveals not additional information, except that the client checks both incoming and outgoing SA, whereas the server checks only the incoming: client: ikev2_init_ike_sa: "policy1" is already active ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636797 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 54 second(s) ago ikev2_init_ike_sa: "policy1" is already active pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 51 second(s) ago pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 51 second(s) ago server: pfkey_sa_last_used: last_used 1455636795 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636858 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 51 second(s) ago Thanks all for your time and help in advance, George. PS. I'm getting
Re: OpenBSD 5.8 ikev2 road warrior setup with various clients
On 16/02/2016 11:59 πμ, George Mamalakis wrote: Hi all! I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to allow remote access to my local network from various, road-warrior client "types" (MS Windows, Linux's, BSD's). My example local network is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4. I've read various guides on the Internet regarding analogous setups, but all of them were discussing about MS Windows clients. I'm trying to test my setup with an OpenBSD 5.8 client but I fail, and next I'd like to test it with a FreeBSD and a Linux client to see if it works. My /etc/iked.conf looks like this: ikev2 passive esp \ from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \ psk mypass \ config address 10.10.10.5 My client's /etc/iked.conf looks like this: ikev2 active esp \ from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \ psk lala123 which is based on an old email of this list (at around 2012), and as I explained earlier, it doesn't work. What happens is that when I try to access 10.0.0.1 from my client, the specific traffic is not passing from enc0 but is rather passing directly from the egress interface to its default route. Now, as it seems, this is a routing/flows issue, but I am unsure as to how to address it. ipsecctl -sa on both machines looks good (or at least I think it does): server: # ipsecctl -sa FLOWS: flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 client: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 As inferred, my client's public IP is 5.6.7.8, and on both machines ip forwarding is enabled (pf allows all traffic as well). Any help would be greatly appreciated, and directions towards an analogous, working, client setup for FreeBSD and Linux would be equally appreciated. Thanks all in advance, George. I've also tried a different setup (without an internal network) which works for about a minute or so, and then it stops. server: # cat /etc/iked.conf ikev2 passive esp \ from 10.0.0.0/24 to 0.0.0.0/0 local 1.2.3.4 peer any \ psk mypass # cat /etc/ipsec.conf flow esp out from 10.0.0.0/24 to 10.0.0.0/24 type bypass client: # cat /etc/iked.conf ikev2 active esp \ from 0.0.0.0/0 to 10.0.0.0/24 peer 1.2.3.4 \ psk mypass With this configuration, both client and server are able to access 10.0.0.0/24 (by adding the extra flow in server's /etc/ipsec.conf and loading it via ipsecctl -f /etc/ipsec.conf), but after a minute or so the setup stops working. Traffic is reaching the server's enc0 interface and replies are sent to the client via enc0, but the client's udp port which used to accept packets becomes unreachable (closes for some reason): 08:00:27:ee:e7:fd 08:00:27:59:7c:d4 0800 178: 1.2.3.4.52586 > 5.6.7.8.58353: udp 136 08:00:27:59:7c:d4 08:00:27:ee:e7:fd 0800 70: 5.6.7.8 > 1.2.3.4: icmp: 5.6.7.8 udp port 58353 unreachable I'm not sure that running: # iked -vvd & on both machines, reveals not additional information, except that the client checks both incoming and outgoing SA, whereas the server checks only the incoming: client: ikev2_init_ike_sa: "policy1" is already active ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636797 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 54 second(s) ago ikev2_init_ike_sa: "policy1" is already active pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: outgoing CHILD SA spi 0x243b7395 last used 51 second(s) ago pfkey_sa_last_used: last_used 1455636860 ikev2_ike_sa_alive: incoming CHILD SA spi 0x2ee69c30 last used 51 second(s) ago server: pfkey_sa_last_used: last_used 1455636795 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 54 second(s) ago pfkey_sa_last_used: last_used 1455636858 ikev2_ike_sa_alive: incoming CHILD SA spi 0x243b7395 last used 51 second(s) ago Thanks all for your time and help in advance, George. PS. I'm getting the same behaviour even without the additional flow of /etc/ipsec.conf, so I've ruled it out from a problem candidate.
OpenBSD 5.8 ikev2 road warrior setup with various clients
Hi all! I'm trying to configure an ikev2 VPN gateway on my OpenBSD 5.8 box to allow remote access to my local network from various, road-warrior client "types" (MS Windows, Linux's, BSD's). My example local network is 10.0.0.0/24 and my public IP (egress) is 1.2.3.4. I've read various guides on the Internet regarding analogous setups, but all of them were discussing about MS Windows clients. I'm trying to test my setup with an OpenBSD 5.8 client but I fail, and next I'd like to test it with a FreeBSD and a Linux client to see if it works. My /etc/iked.conf looks like this: ikev2 passive esp \ from 10.0.0.0/24 to 10.10.10.0/24 local 1.2.3.4 peer any \ psk mypass \ config address 10.10.10.5 My client's /etc/iked.conf looks like this: ikev2 active esp \ from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 \ psk lala123 which is based on an old email of this list (at around 2012), and as I explained earlier, it doesn't work. What happens is that when I try to access 10.0.0.1 from my client, the specific traffic is not passing from enc0 but is rather passing directly from the egress interface to its default route. Now, as it seems, this is a routing/flows issue, but I am unsure as to how to address it. ipsecctl -sa on both machines looks good (or at least I think it does): server: # ipsecctl -sa FLOWS: flow esp in from 10.10.10.0/24 to 10.0.0.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type use flow esp out from 10.0.0.0/24 to 10.10.10.0/24 peer 5.6.7.8 srcid FQDN/1.2.3.4 dstid FQDN/5.6.7.8 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 client: # ipsecctl -sa FLOWS: flow esp in from 10.0.0.0/24 to 10.10.10.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type use flow esp out from 10.10.10.0/24 to 10.0.0.0/24 peer 1.2.3.4 srcid FQDN/5.6.7.8 dstid FQDN/1.2.3.4 type require flow esp out from ::/0 to ::/0 type deny SAD: esp tunnel from 5.6.7.8 to 1.2.3.4 spi 0x3ebcc647 auth hmac-sha2-256 enc aes-256 esp tunnel from 1.2.3.4 to 5.6.7.8 spi 0x736c382f auth hmac-sha2-256 enc aes-256 As inferred, my client's public IP is 5.6.7.8, and on both machines ip forwarding is enabled (pf allows all traffic as well). Any help would be greatly appreciated, and directions towards an analogous, working, client setup for FreeBSD and Linux would be equally appreciated. Thanks all in advance, George.
