@jon You did an outstanding job here, and a useful one for all the people coming from the Mac ecosystem to IPFire. I can’t stress enough how much I want to congratulate you.
By the way, this works also in Mojave
For reference, this is what I am using, It would be wonderful if @jon or @trymes would give a feedback
@cfusco - your config, with ECP256 and ECP384 selected, is definitely a lot better than what @jon is using with MODP1024.
This did not work. Not sure what I am doing wrong!
If I look at the log it looks like the path is from outside (myInternetIP) to inside (192.168.65.111):
Aug 12 19:24:04 ipfire charon: 09[NET] sending packet: from <myInternetIP>[500] to 192.168.65.111[500] (345 bytes)
Aug 12 19:24:04 ipfire charon: 08[NET] received packet: from 192.168.65.111[4500] to <myInternetIP>[4500] (540 bytes)
. . .
Aug 12 19:24:04 ipfire charon: 13[ENC] unknown attribute type INTERNAL_DNS_DOMAIN
. . .
Aug 12 19:24:04 ipfire charon: 13[CFG] looking for peer configs matching <myInternetIP>[192.168.65.1]...192.168.65.111[JMBP6]
Aug 12 19:24:04 ipfire charon: 13[CFG] no matching peer config found
Aug 12 19:24:04 ipfire charon: 13[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Aug 12 19:24:04 ipfire charon: 13[IKE] peer supports MOBIKE
Aug 12 19:24:04 ipfire charon: 13[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
I wonder if it is related to the Host Certificate "Subject Alternative Name"? Should I add an internal IP address here?
I’m sorry, but I’m sure you have a good reason for wanting to establish a VPN from a device on blue to the router, but it’s far beyond me to understand it. For testing, maybe, but there are so many extra variables that it doesn’t make sense to me, and in actual usage, the encryption on the WiFi connection ought to be enough. If it isn’t, then you shouldn’t be using WiFi, IMHO.
It may be possible to make this work, but I expect that it will not. Also, don’t forget that devices or subnets need to be added in Blue Access, and a firewall rule needs to be created for blue to access green.
Beyond that, I suspect an disconnect between the certificate address/name and the address you are connecting to. Even if you are able to make it work, you may very well break connections incoming to red in the process.
What’s the whole point of connecting via IPSec from a host on blue?
Just testing. I can easily test my iPhone IPsec via cellular (LTE), but I don’t have a way to test my iMac or MacBook via IPsec. So the hope was do a VPN from blue to green.
No other reason…
@jon
In /network preferences/server address/ did you put a DNS entry or an IP address (such as 192.168.65.1)? I put an IP address to keep the traffic inside the LAN because if I put the DNS entry for my server, it does not take the private address but the public one. If it goes through the WAN side it doesn’t work and I see logs like the one you have shown.
It works. I did this to restrict all the traffic from the blue zone with a firewall rule. If I VPN, then I get an IP in the green network and I can get to the WAN side. Not that I need to do it, but I wanted to see if I could add an extra layer of protection on the WIFI. Apparently, it is possible.
Interesting @cfusco. Seems unnecessary, seeing as all devices on blue are blocked by default, but interesting all the same.
@jon: are you not able to use your phone as a hotspot? That would allow you to connect devices to the internet via WiFi through your phone’s data connection, which might work.
Totally unnecessary. I just wanted to see if it would work.
IP addresses.
On IPFire → Primary DNS: 192.168.65.1
• menu Network > DHCP Server
-and-
On the Mac → DNS Servers: 192.168.65.1
• menu System Preferences > Network > Wi-Fi > Advanced > DNS
No Hotspot. The cell company decided this was a big $$ add-on! I’ll need to check if I can subscribe / unsubscribe to the hotspot. Maybe I can subscribe for a month and then unsubscribe.
Ahh - Got it! Thank you!
I changed the Server Address from my dynamic DNS FQDN to a local IP address and it connected! Yay!
I was changing the Remote ID info
It does not fully work since local DNS is missing. And there are other things that seem very broken.
BUT it does allow me to do some “Connect” testing! So that will do for now.
Thank you to all for your comments and help!
not yet. Probably this weekend when less people are using the internet.
Are you experiencing issues? What do you see?
If someone needs IPSec Split-Tunneling (tested for macOS) so that the traffic is split between Roadwarrior’s local network and the ipfire/office-network (by default the whole traffic is routed through ipfire/office’s network, which is not always desired):
Just edit /etc/strongswan.d/charon/attr.conf
on ipfire and add the attribute:
25 = myoffice.local
Then restart ipfire’s ipsec:
#ipsec restart
You can also narrow your “Local Subnet” from 0.0.0.0
to e.g.: 192.168.64.0/24
(for example myoffice.local
subnet is 192.168.64.0/24
) instead of 0.0.0.0/0
.
See original article here: StrongSwan, IKEv2, Split DNS and iOS
And discussion here:
IPSec on macOS and split tunneling - #14 by cgil
Also it would be great to have this feature in IPSec’s WebUI since setting “DNS Server” doesn’t enable directly split-tunneling…at least for me.
Yes - IPsec still works A-OK! I tested with my iPhone and I did some simple tests and all works as expected.
Core 160 working nice as well
Maybe not the best quote. Anyway I’m having an issue that may very well is caused by how a RoadWarrior connection is intended to work.
I refer to wiki.ipfire.org - Global Configuration
The specific problem is that I can’t get Roon to work. (Hope you’re familiar with Roon).
So locally I can stream from Roon to my iPad (Roon shows up as an endpoint). However this doesn’t work at all under VPN on my iPad. I can easily access Roon, and play to other endpoints on same network.
I think the reason for this is that Roon doesn’t see my iPad being on same subnet as the Roon core, and hence won’t allow streaming to my iPad over VPN.
Is this correct understood?
I tried to edit global settings to my local 192.168.50.0/24, but that didn’t work at all.
So is there a way I can configure iPfire to solve this problem?
I tried something indicated in this article, but no success 192.168.0.0/23 which I think ought to work, but doesn’t.
And if there is absolutely no way, even a very creative one, what could I ask from the Roon team to change in their SW, in order to make this work.
(Of cause they can’t allow me to stream to anywhere I like, so I need to convince the team of an almost bulletproof solution).