I have a road-warrior VPN server working on my OpenWrt home router (iPhone/iPad can connect back to home using IKEv2 VPN, and access home network resources that way), following this guide:
but I found the firewall stuff very tricky to get right. And, it doesn't use UCI configurations, it uses /etc/ipsec.conf.
I suspect the firewall rules would be a lot easier if the VPN traffic came through a different zone/interface, which seems to be what is recommended in this other configuration page to use UCI-based configs and swanctl:
which might be about the same server-side for road-warrior configs, if I read "headquarters" to be the equivalent of the home router.
However, I'd need to convert the /etc/ipsec.conf based configuration to the swanctl/UCI based configuration. Anybody have an example for doing that?
Or an example of using xfrm-based interfaces for the /etc/ipsec.conf based configuration?
Since you have control over both sides, why not use Wireguard? Lightweight and fast, easy to configure, and super easy to use the standard firewall rules to manage the access. OpenVPN is another option, although it is quite bloated and slow by comparison, and considerably more complex to setup.
I have openvpn set up (from years ago) and don't particularly like it. I liked IPSec/IKEv2 since it was built-in to iOS (no app required), and uses certificates for user authentication.
But now that I'm dabbling in IPv6 (using a 6to4 Hurricane Electric tunnel) I'm finding the tweaks needed for strongswan are getting to be annoying.
I'll take a look at Wireguard. But still interested to hear from anyone about strongswan configuration with /etc/ipsec.conf vs. UCI.
Here's my goal:
Not using passwords for users (use my own privately issued X.509 certificates or generated ssh-style keys)
can simultaneously tunnel IPv4 and IPv6 through the same VPN connection. Or only one or the other if chosen by the client.
clients can connect using public IPv4 or IPv6 to the tunnel endpoint
VPN clients in a firewall zone that has access to WAN & WAN6 public egress (similar to a guest zone), and can craft firewall rules to allow certain access to LAN
iOS, macOS, Windows client support
Bonus points for:
Built-in support on client devices (no app)
Site-to-site VPN (to connect two openwrt routers at different dwellings)
Ability to multicast-bridge bonjour/mdns to VPN client (enable airprint)
I can't help you here as I haven't used strongswan. However, I can say that every point in your goals is satisfied by Wireguard except for the "Built-in support (no app)" part.
Oh, and the other one that WG doesn't cover is this:
Most modern VPN solutions don't support this because they are tunneled/routed (L3) protocols, not L2/TAP bridges. Technically OpenVPN does support TAP, but you cannot use TAP on iOS and Android, so OpenVPN can only be used in TUN mode if you intend to have mobile clients connecting. I don't know if StrongSwan on mobile can use TAP.
You could try using an mdns reflector/repeater to see if it is possible to get your multicast devices to communicate through the tunnel.
Regardless, I would advise against using TAP or an mdns repeater/reflector in general across a VPN connection because it will tend to send quite a lot of extra traffic through the tunnel (i.e. broadcast traffic), reducing the speed/efficiency of the tunnel and consuming more data in the process.
One more thing that I find very handy with openvpn and ipsec/strongswan, but is not part of wireguard, is VPN server-assigned IP addresses (v4 and v6).
Not a big deal for ipv4 addresses (need to use RFC1918 ranges anyway), but for IPv6, that means the client has to know the network range delegated from the VPN server's upstream. That can be stable if I use a tunnel broker but is not stable for the other residence where the ISP directly delegates a prefix.
Or, I need to use NAT6 for the VPN clients and a ULA prefix.
But really, I'd rather not manually assign IP addresses to the VPN clients.
IMO, this isn't really a big deal since you're already setting up unique keys for each client device. It just becomes another part of the basic configuration that each peer needs.
For initial setup, no big deal, but annoying to have to reset all the clients configs if I'm using the global IPv6 addresses without NAT6, and the ISP changes the delegation.
That said, so far I was successful in getting wireguard to run with a dual 4/6 VPN tunnel, whereas with strongswan I couldn't get a dual tunnel to work.
Thanks for the tips.
Nah, I may still go poke at the ipsec/strongswan configs for my curiosity to compare the uci-configs vs. custom configs. That is after all what the title is about
Sadly there are ISPs (particularly in Europe) which assign a different dynamic prefix upon each and every dialin (and after fixed maximum intervals, e.g. 180 days at most). Yes, wireguard (at least wireguard with IPv6 access) is tricky in this context, back when I still had such a VDSL line, I circumvented that by using a static prefix from Hurricane Electric (6-in-4 in addition to native IPv6, merely to get a static IPv6 prefix for VPN uses).
tl;dr: I'm abandoning work on trying to get strongswan/ipsec to use these separate interfaces in the /etc/config/ipsec style.
I spent far too much time today attempting to get the /etc/config/ipsec style of configuration working for an ipsec server on OpenWrt with road-warrior type clients. I never did get it working with the xfrm-based networks. The closest I could get required me to edit a generated config file by hand (which is no good, as my edits get lost on a restart) and left me with no virtual IPs available (I think the connection to the xfrm-based tunnel was incomplete):
Sat Feb 5 23:54:40 2022 daemon.info : 14[IKE] peer requested virtual IP %any
Sat Feb 5 23:54:40 2022 daemon.info : 14[IKE] no virtual IP found for %any requested by 'xxx'
Sat Feb 5 23:54:40 2022 daemon.info : 14[IKE] peer requested virtual IP %any6
Sat Feb 5 23:54:40 2022 daemon.info : 14[IKE] no virtual IP found for %any6 requested by 'xxx'
Sat Feb 5 23:54:40 2022 daemon.info : 14[IKE] no virtual IP found, sending INTERNAL_ADDRESS_FAILURE
