Hi Sam,
> So I investigated further, and this seems to be be how the tunnels are
>> > brought up on the linux firewall...
>> >
>> >snip<
>>
>> Since you mention an IP address for the "left" reference in your
>> ipsec.conf file, I assume you have a situation with one machine
>> being static, and the other dynamic. As I see it, you'll have no problem
>> re-starting the machine with the dynamic IP to recognize its new IP
>> address; but you may have issues with the static machine, due to the
>> delay Dynamic DNS updates frequently encounter. This all may be
>> happening
>> too fast for the static machine.
>>
Okay, I have been investigating further! :) with now two
scenerios - fixed ip-dynamic ip (adsl-isdn), and also
dynamic-dynamic (isdn-isdn).
with the fixed-dynamic scenario, once the tunnel has been formed
and the line has been dropped, I am required to reboot both
firewalls, and then the tunnel comes back up again. restarting
ipsec is not enough!
with the dynamic-dynamic scenario, things get a little more
complicated, seeing as every time the machine is rebooted the IP
address changes on that side... so here I have to disable the
tunnel on each firewall, reboot each firewall, then re-enable
the tunnel on both firewalls - then a restart of ipsec brings
the tunnel back up. it's a bit laborious!! - but it works :)
>> Ultimately, you will be better off approaching this from the angle of a
>> "RoadWarrior". This configuration is meant for situations in which one
>> machine's IP address changes frequently, but the other does not, and I
>> would highly recommend it if that is indeed your situation.
>>
>> Read about a Road Warrior setup at doc/config.html#roadex.
>>
>> As for some of your other questions:
>>
>> IPSec logs can be found in both /var/log/secure and /var/log/messages.
>> As well, you may want to compare the output of "ipsec auto --status" on
>> both sides of the VPN; see if the connection descriptions match and are
>> correct with the actual setup post-ISDN-restart.
>>
>> To carefully restart the connections use these commands:
>>
>> 1) ipsec auto --down connectionname
>> 2) ipsec auto --delete connectionname
>> 3) ipsec auto --add connectionname
>> 4) ipsec auto --verbose --up connectionname
>>
I tried this. to cut a long story short, again this works fine
the first time the tunnel is created following a boot, but after
that (once the line is dropped) even this doesn't seem to do the
trick - a reboot is required on both sides.
Next I checked the logs, and /var/log/messages on the static
side the firewall shows lots of entries for ipchains on port
520... which I seem to remember from previously trying to set up
VPNs with routers (ended up going for a second IP address per site!)
also I have been reading of lots of potential problems, and one
that has cropped up was the software firewall letting through
traffic for the old IP addresses, but of course the software
firewall does not know anything of the new values for the dynamic names!
so it's a [ipchains] firewall problem maybe? this makes sense -
restarting ipsec is not enough as the [ipchains] firewall
contains rules for the old ip addresses not the new ones,
whereas rebooting the machine will force the firewall to update
it's rules as well - also makes sense with the having to disable
the vpn when rebooting the smoothwall/ipcop in the
dynamic-dynamic scenario.
okay, my logic says I should now be looking at updating ipchains
as well as ipsec - maybe I don't even need to update ipsec after
all as with the correct firewalling info in place it would update itself?
does all this make sense? does the ipchains theory fit in with
what you know of vpn's? if not, what is this traffic to port 520
that is being blocked? it appears on the machines with the
static ip's, but not those with dynamic ip's.
many many thanks for the help!
regards,
Greg Conway.
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:19:58 CEST