I'm currently running EoIP between two locations, one of them has dynamic IP (and there's precisely 0% chance to get a static one there). EoIP on the side with static IP has following configuration:
On the other side, where IP is dynamic configuration looks as follow: There're two problems:
1. Local address cannot be a domain - you can type it, but it will be resolved only once. It works properly, for quite some time, for remote address however (wtf?)
2. The bigger problem and the bug hits where WAN IP changes and configuration needs to be updated on remote location. Changing the address changes it on interface only where all IPSec stuff like policy stays with old address. Since elements created in IPSec are dynamic you cannot alter them. This effectively makes impossible to change the IP or e.g. use script to change it. The worst part of that is the only way I've found to change the IP is to completely remove interface and re-add it (which of course creates gigantic mess in other places like firewall).


I performed all tests on 6.37.3, since 6.38 is not production-stable yet. Is anyone has any suggestions?

Bump.

For some things you just need a static IP.
In this case you could think of running a VPN that overcomes this problem and another EoIP on
top of that, but it all becomes very messy.

Well, EoIP is already messy to start with, so maybe it is better to do some network re-design.

@pe1chl: The thing is no VPN offers such flexibility and messing with VPN+EoIP is horrible. I just can't understand why static IP is implemented for remote only? The check is done before connection attempt is made - I don't see problem with doing the same with local IP.
Probably it's not implemented because of this bug - even if you change IP everything stays with old one without any chance of changing it...

There are limits to what the underlying IPsec code can do - it essentially assumes static addresses.
However, you can always write a script that changes the static configuration when your WAN address
has changed.

I wish it is possible! The script wouldn't be a problem, but if you change the local IP on EoIP with IPSec policies aren't updated and they cannot be changed since they're dynamic...

I wish it is possible! The script wouldn't be a problem, but if you change the local IP on EoIP with IPSec policies aren't updated and they cannot be changed since they're dynamic...

Is the IPsec policy automatically generated from EoIP or have you created is manually? I think a script would solve your problem, but will break the connection a few seconds.

Try to disable/enable eoip tunnel after changing local-address.

Is the IPsec policy automatically generated from EoIP or have you created is manually?

Generated.

I think a script would solve your problem, but will break the connection a few seconds.

It's not a huge deal - working with dynamic addressed connections is already a PITA and everyone needs to be aware of compromises

Try to disable/enable eoip tunnel after changing local-address.

6.38 seems to partially fix the problem - before that cycling the interface or even restarting whole router had no effect. Why I'm saying it's fixed partially? Well, there's no way to listen for any events in scripts, so I cannot effectively check for new IP on connection.
Could you maybe sneak peek why implementing remote-address auto-resolve wasn't a problem but local-address has to be fixed and cannot be resolved before connection is initiated?

I agree with you that a nice wishlist item would be to be able to use symbols referring to dynamic addresses in all places
where fixed addresses have to be configured now. When the address changes, that particular item would be automatically
reconfigured. It would trigger the config change e.g. when the DHCP Client receives a new address or when a PPP
link gets a new address.

When the address changes, that particular item would be automatically
reconfigured. It would trigger the config change e.g. when the DHCP Client receives a new address or when a PPP
link gets a new address.

Addresses can change without either of those two events occurring, so you'd still need to check periodically.
Given that, it seems pointless to check on those events. You'd just rely on the periodic check alone.
So, how often are you going to check?

You'd just rely on the periodic check alone.
So, how often are you going to check?

Actually for purpose of tunnels it can be easily bind to the tunnel connection itself, like remote-address now. If the tunnel disconnected ROS should resolve names, create policies and attempt connection like it's doing with remote-address. If connection is still alive (and it's guaranteed by ping check on route) there's no need to update neither of the addresses.