[K12OSN] easy VPN?

Julius Szelagiewicz julius at turtle.com
Mon Apr 26 19:15:15 UTC 2004

On Mon, 26 Apr 2004, Les Mikesell wrote:

> On Mon, 2004-04-26 at 10:58, Julius Szelagiewicz wrote:
> > well, it turns out i need more: i added route pointing to my business
> > server going through the virtual cipe interface. now i can connect to my
> > big server that sists on the same network segment that the CIPE server is
> > on, but i can connect only from the console and the terminals. the pc that
> > sits on eth0 of the remote cipe box has access to the 'net (firewall down
> > for the moment), natting is on, masquerade is on, ip forwarding on. this
> > pc just can't connect to the "other" side of the virtual private cipe
> > connection.  What have i missed here? tia, julius
> You have to set up routes both ways through the cipe interfaces.
> You can add these in the GUI where you set up the interfaces or
> you can edit them into the /etc/cipe/ipup and ipdown scripts. Either
> way they are added/deleted with the ifup/ifdown commands or other
> normal ways of activating and deactivating the interfaces.  Step
> one in testing is to ssh directly from one cipe server to the remote
> cipe interface.  Then do it back from there to your own cipe interface.
> Then repeat with the inside LAN interface addresses. If that works,
> the internal routing is OK on both servers (i.e. you are routing through
> the tunnel correctly to the remote LAN). If you can't go beyond the
> server's own LAN interface, it will be either because the other LAN
> devices aren't routing through the cipe server, the cipe server doesn't
> have routing enabled, or something is firewalled.  I prefer to do normal
> routing so source addresses remain visible but it is also possible to
> masq at the cipe interfaces to reduce the routes things need to know.
	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

More information about the K12OSN mailing list