[K12OSN] easy VPN?

[Les Mikesell]

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. 

---
  Les Mikesell
   les at futuresource.com