[K12OSN] easy VPN?

Julius Szelagiewicz julius at turtle.com
Mon Apr 26 20:27:39 UTC 2004

On Mon, 26 Apr 2004, Les Mikesell wrote:

> On Mon, 2004-04-26 at 14:15, Julius Szelagiewicz wrote:
> > 	yes, this makes perfect sense. once the routes were set up on both
> > ends and the route to the inner network on the client was added on the
> > server, everything was hunky-dory. it all works just fine up to a moment
> > when the following shows up in /var/log/messages:
> > Apr 26 17:41:29 ltspl ciped-cb[1831]: peer: going down
> > Apr 26 17:41:29 ltspl ciped-cb[1831]: kxchg: recv: Connection refused
> >
> > the traffic now goes through my main firewall from the outside to the
> > ltspl server end. only one udp port is opened on the firewall. do i need
> > additional ports? what am i missing here? this stuff has to stay on
> > forever, otherwise it is counterproductive. julius
> Your NAT router will have a short timeout interval where it will accept
> UDP packets back to the source.  Even if the port isn't specifically
> firewalled, the address of the inside machine is deleted from the
> dynamic NAT table much faster than a TCP connection would be. If you
> have a public address available, the best approach is to set up a static
> NAT.  You might also be able to set up port-forwarding for your
> UDP port from the NAT router's public address.   Next best is to
> send something through the tunnel often enough from the NAT side
> to keep it from timing out.  Something like 'ping -i 30
> remote_cipe_address'  would probably work.
	all I can say is "doh!". this seems to be a prolonged senior
moment. my sonicwall box is the culprit. of course i have to keep some
traffic going, for some reason i imagined that the cipe connection would
generate enough data exchange. well, i send xon every few minutes to my
handheld terminals, so that the radios stay up - this is the same
principle. thanks, julius

More information about the K12OSN mailing list