IPSEC Tunnels Initiated Phase 1 from any remote IP
-
In the phase 1 configuration screen, in the general information section, there is setting to specify the remote gateway.
Is there a way to allow an incoming phase 1 request from any remote IP, and then allow the engine to choose the proposal based on the PSK and or a distinguished name instead ?
-
From what I read, VPN is implemented under the hood by Strongswan. From their docs, I read that there is a %any option on the left and right configurations.
Tried %any via the web gui but It errors indicating %any is not a valid IP.
So I wonder if it is possible to add more advanced config via SSH terminal ? Totally green in this area, any advice here welcome. I'll do the leg work.. -
So are you basically wanting the pfsense to be the head-end of an aggressive mode tunnel where the peer has a changing IP? I would also be interested in the correct config on this.
I agree a supported method of editing the config file would be ideal.
*EDIT
My current interpretation of the correct way is below which uses certs. I'm not 100% confident on this, it would be nice if someone could confirm.- Use a fqdn for the remote gateway. Probably same as peer id depending on cert.
- Authentication Method set to Mutual RSA
- Negotiation mode set to Aggressive
- Peer identifier set to Distinguised name
- Advanced Options - Responder only
-
Yes, I want the pfsense box to be a responder only to particular tunnels. The remote peers (I will have a few of them) with the changing IP will be the initiators. I cant even use DDNS in my particular scenario.
I'm not sure aggressive mode is needed to make this work…I don't want to use certificates in my case, and I'm hoping that I can do it just with PSK's.
Do you know much about the config of pfsense via a terminal rather than the web GUI ?
I've read that the gui settings are all in a XML file somewhere. But what I need to understand is how the various subsystems like Strongswan then use that information. I would assume the relative information is copied the .config files from the XML by the pfsense engine ????When I get a moment, I'm hoping to stand up a test box and have a look around via the terminal, but some starting understanding of the "behind the scenes" logic would help cut down on the guess work.
-
Yeah aggressive mode is probably not needed, I misunderstood what it does.
I have only poked around a bit at the strongswan config files while troubleshooting, so can't help much there.
I'd be interested to see if setting the remote gateway to a generic fqdn and then setting the tunnel on responder only mode would work.
-
I looked into this and found this post:
https://forum.pfsense.org/index.php?topic=84021.msg572523#msg572523You can use 0.0.0.0 as the remote gateway.
I was able to use it successfully in my test environment.
-
Yes you are correct. Stood up a test server and 0.0.0.0 works. If you inspect the ipsec.config file used by Strongswan the right value is 0.0.0.0 so pfSense does not parse it in any way. Yet there is no mention of 0.0.0.0 in the Strongswan docs (from what I could find)
In my situation I also needed to be able to have multiple tunnels configured, all allowing the incoming connection from any source IP. However I discovered that multiple tunnels cant all have 0.0.0.0 or % any. First the Web Gui will complain that 0.0.0.0 is in use in another Phase 1 config, and the Web Gui wont allow %any.
But even if I add the 0.0.0.0 or %any directly into the config.xml via the Diagnostics->Edit File method I get not luck. I see that the values actually make it all the way to the ipsec.config file after the VPN service is rebooted, but not all Tunnels will connect. Strongswan's lookup process during the Phase 1 incoming connection will match on the first Tunnel config in the list, then a Phase 2 will initiate but fail if the incoming connection is not actually for that first tunnel config.
I was hoping that the lookup process uses more than the peer and local IP addresses, but I don't think it does.
In my situation I've had to fall back to DDNS to make all this work.