Well, you will need to have a way how both peers and contact each other. Otherwise there is no chance to establish the VPN tunnel. For IPFire, one side is enough. Lets assume you have an IPFire box in a data center with a static IP address, the other one can be behind some router with a changing IP address. However, the box in the data center won’t be able to establish the VPN connection.
We do not support aggressive mode at all. With that, you do not really need the VPN. Your PSK will be transmitted in plain text and everyone who can capture all communication will be able to decrypt all your communication. I recommend using certificates, but PSKs are supported, too.
We don’t judge here, but assuming this is EOL for a decade now, you should consider removing this thing as quickly as possible.
Im “Main Mode” (opposite from “Aggressive Mode”) without a static IP or a Dynamic DNS that matches to the HostID IPSec tunnels cannot established becasue IPSec always compare the HostID with the DNS Names to make sure that it talk with the correct peer.
So IPFire not support “Aggressive Mode” because we not set such stupid options.
Yes - one end (my end) is on Static IPs, so remotes can always find the hub end by DNS or static entered IP.
The remote ends are typically stuffed behind a NAT router/fw (common ISP router setup) where both the ISP router WAN is DHCP and most of the time the WAN for the appliance calling in to my FW for connection is also DHCP. (because it’s on the LAN of the ISP box.)
So my equipment will never really be able to initiate any tunnels.
So it sounds like IPfire will do what I need (provided I can work around aggressive mode - which you need not point out the pitfalls – some of these tunnels were configured long long ago (like 10yrs)
So definitely time for an upgrade.
Thanks for the answer. I have a test box to load IPfire to give it a try.
Yes, but depending on your use-case that might not be a problem at all.
Yes, it will be absolutely necessary to upgrade the router on the other end if it only supports aggressive mode. The reason why Arne and I are emphasising this so strongly is because it really really really is a bad idea. IPFire supports loads of modern cryptography option which make a tunnel fast and reliable, even on small hardware. So you won’t have to spend a fortune to keep your data secure.
Well, understand, I don’t have a choice to be going and changing the remote equipment.
Most of them are brand new Juniper SRX300 series units. EVERY Juniper/Netscreen unit I’ve used supports Main-Mode and Aggressive – but my understanding was/is that aggressive most is what’s used when one end is dynamic. Main-mode only works when both ends are static. (feel free to correct me if I’m wrong – I’m going to be researching it now anyway)
While I understand that aggressive mode allows for plain-text auth transmission, Juniper had a tech article rating that vulnerability as “low” as long as quality PSKs and IDs are used.
In any case, from what you describe though, it’s probably worth loading up IPfire and checking to see if it will work.
I have a Juniper SSG140 as a backup plan (actually, it was my original plan, but I use that as a test router on my network for configuring client equipment before shipping it to them so the device is ready to plug into the network) – and the PC based firewalls have a lot of nice features.
Also, I could get an SRX300 series if I wanted… but honestly I kinda hate the interface and the limited set of features.
I was really disappointed to see OPNsense couldn’t handle remote VPNs without needing their IP address.
No, I have heard people saying this before, but it is wrong. Main mode always works.
As far as I understand it, this is referring to the risk of enumeration. Aggressive mode is absolutely broken.
Since these all cost a lot of money, buy a nice IPFire appliance, donate some bucks and go on holiday with what you have left. And it will of course work a lot better.
Once upon a time, (and we’re going back 20yrs) – main mode didn’t work in the same scenario and that’s how aggressive mode came into play.
Agreed on it’s weaknesses.
I already have the SSG140 – and and SRX300 kicking around (but again, the webGUI makes my eyes bleed and Juniper likes to add features but not fix webUI bugs)
Also, I have lots of rack PC’s around - so if I get it working and it’s good – reusing available hardware will let me donate more to IPfire should it work out.
But again, I don’t have say so in changing all the remote ends that may or may not support IKEv2.
On another note having installed IPfire on my test system, is it just a WebUI limitation or does IPfire not easily (or at all) support Ethernet LAG interfaces?
I did the prelim setup and it wasn’t really obvious anywhere.
IKEv2 was specified in 2005. That is 15 years now. I do not want to be the bad again, but if your equipment is that old you should probably consider upgrading it.
