Bug #10638
closed
ipsec VTI interface not setting tunnel parameters when phase1 Remote Gateway is 0.0.0.0
Added by Tim Carre about 4 years ago.
Updated about 4 years ago.
Description
Hello everyone,
I am very interested in the Route-Based IPsec VPN and all the possibilities in dynamic routing made possible by the VTI interfaces.
What I need to do is to make a connection (ikev2) between a "mobile client" (dynamic IP address) and a fixed IPsec server. The client is a Juniper SRX300 here.
I know this type of phase2 tunnel is not possible with a phase 1 "Mobile Client" setup. But I am able to established a a routed IPsec VPN with a classical phase 1 referencing a Remote Gateway of "0.0.0.0". The selection is made with local and peer identifiers matching a "hostname" (FQDN) or a username (aaa@bbb).
If the Remote Gateway is set to "0.0.0.0" flows are working from the Juniper to the pfSense (4.4.5 or 4.5.0-DEVEL) but not the other way around.
When I set the Remote Gateway to the public IP of the SRX connection (what I don't want to do because the IP can change) all seem to work well.
It seems that in the former configuration the command "ifconfig ipsecXXXX tunnel pfsense_ip srx_ip" is not executed.
Wouldn't it be possible to pass the "srx_ip" at connection time ?
Regards,
Tim
- Category set to IPsec
- Status changed from New to Not a Bug
- Priority changed from High to Normal
No, the IP address must be present when the interface is created. You end up in a catch-22 where the tunnel wouldn't work without the interface present but you can't create the interface properly without knowing the remote endpoint.
Use a dynamic DNS hostname instead of 0.0.0.0 for the remote and that should be able to work.
Jim Pingle wrote:
No, the IP address must be present when the interface is created. You end up in a catch-22 where the tunnel wouldn't work without the interface present but you can't create the interface properly without knowing the remote endpoint.
Use a dynamic DNS hostname instead of 0.0.0.0 for the remote and that should be able to work.
Thanks for the quick response.
I have been able to set up the "ifconfig ipsecXXXX tunnel" from CLI after the interface creation and even the tunnel setup (indeed the tunnel is in established state but the forwarding is wrong because the tunnel is not set, the interface flag "RUNNING" is not present and interface can not be used).
So it seems like that command can be triggered anytime you want.
Dynamic DNS is too risky and depends and other services, etc. Not really production safe in that case.
Tim Carre wrote:
Jim Pingle wrote:
No, the IP address must be present when the interface is created. You end up in a catch-22 where the tunnel wouldn't work without the interface present but you can't create the interface properly without knowing the remote endpoint.
Use a dynamic DNS hostname instead of 0.0.0.0 for the remote and that should be able to work.
Thanks for the quick response.
I have been able to set up the "ifconfig ipsecXXXX tunnel" from CLI after the interface creation and even the tunnel setup (indeed the tunnel is in established state but the forwarding is wrong because the tunnel is not set, the interface flag "RUNNING" is not present and interface can not be used).
So it seems like that command can be triggered anytime you want.
Dynamic DNS is too risky and depends and other services, etc. Not really production safe in that case.
You can create Site-to-Site VPN and set 0.0.0.0 as remote gateway address, see #7095 and #7410
You can create Site-to-Site VPN and set 0.0.0.0 as remote gateway address, see #7095 and #7410
Yes that is what we do but we would need VTI on top of it to make dynamic routing possible.
Is it pfsense or strongwan managing those interfaces ?
- Related to Bug #12723: Disallow remote gateway of ``0.0.0.0`` for VTI mode added
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Viktor Gurov