Menu
▾
▴
#417 PPPOE does not change "Local VPN Hostname/IP"
Hi,
I'm using IPCop in a server that starts a PPPOE
connection. When it renews that connection (maybe
because the modem is restarted) the address that
appears in the "Local VPN Hostname/IP" section (in the
VPN menu) does not change.
That leads to an error that prevents to start the VPN
connections. The error that I can see in the IPSEC log is:
----LOG----
May 11 17:01:50 canalsvila ipsec__plutorun: 022
"vilax2canalsx": we have no ipsecN interface for either
end of this connection
---------------
Talking in terms of filesystem, the error comes from
the incorrect value stored in /var/ipcop/vpn/settings:
ENABLED_BLUE=off
ENABLED=on
VPN_IP= x.x.x.x <--- here is the wrong IP
In the VPN_IP value appears the old IP obtained from
the last PPPoE connection, not the new one.
I've tried to solve the problem adding the following
lines at the end of /etc/rc.d/rc.updatered:
...
if [ -e "/var/ipcop/red/active" ]; then
cat /var/ipcop/vpn/settings | head -2 >
/var/ipcop/vpn/settings.tmp
echo "VPN_IP="`cat
/var/ipcop/red/local-ipaddress` >>
/var/ipcop/vpn/settings.tmp
mv -f /var/ipcop/vpn/settings.tmp
/var/ipcop/vpn/settings
chown nobody.nobody /var/ipcop/vpn/settings
...
I hope you can arrange that little problem better than me.
Thanks for your excellent IPCop software. I enjoy it!!
Thanks,
Jaume,
Logged In: YES
user_id=317036
The usual way round this is to get a name from a dynamic dns
provider and place that name in the local vpn hostname/ip
field. I'd be hesitant about having IPCop automatically
update this, because then there's no way for a user to
hardcode a specific IP if they're stuck behind a second
gateway. Maybe it could be made so if the field is left
blank it automatically uses the red IP, but otherwise uses
the one that's been entered. In a lot of ways I'm not really
sure why it wasn't done this way in the first place, but
then I don't really understand the internal workings of the
VPN system.
Logged In: YES
user_id=328434
I've changed the lines in /etc/rc.d/rc.updatered. The lines
above don't work, the following ones work well:
NENIP=`cat /var/ipcop/red/local-ipaddress`
cat /var/ipcop/vpn/n_settings | sed -e
s/NOVA_IP/$NENIP/g > /var/ipcop/vpn/settings
cat /var/ipcop/vpn/n_ipsec.conf | sed -e
s/NOVA_IP/$NENIP/g > /var/ipcop/vpn/ipsec.conf
cat /var/ipcop/vpn/n_ipsec.secrets | sed -e
s/NOVA_IP/$NENIP/g > /var/ipcop/vpn/ipsec.secrets
chown nobody.nobody /var/ipcop/vpn/settings
/var/ipcop/vpn/ipsec.conf /var/ipcop/vpn/ipsec.secrets
Where n_* are skeletons of the original files with the word
NOVA_IP waiting to be substituted by the real IP.
I agree with rkerr that it would be better if there was a
switch that allows the VPN system to automatically catch the
dynamic IP obtained from the RED device. That's specially
ussegul when getting that IP dynamically (e.g., from a PPPoE
connection).
Logged In: YES
user_id=1041094
Hello,
I think entering a dynamic IP somewhere is generally bad idea.
Solution is quite simple: use a dynamic dns provider name.
Your peer must have one to find your RED interface, hein !
I do put vpn.franck.afraid.org
in this field and let ddns support do it's job.
Bye
Logged In: YES
user_id=317036
Thinking about this francks probably right, there's no point
in having IPCop automatically update the VPN IP, because you
still need a way for the remote side of the VPN to find out
the correct IP. That means you've gotta have a dynamic dns
name pointed at IPCop anyway.