<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: Re: Keeping CIPE link Up
From: Peter van den Heuvel <peter,AT,asylum,DOT,xs4all,DOT,nl>
Date: Sat, 4 Aug 2001 13:34:35 +0200
In-reply-to: <CJELIEBEFNCJAOMOOMNNOECBCCAA.lesmikesell@home.com>

Yo,

> I recently installed a CIPE endpoint behind
> a NAT firewall (where the NAT was not dynamic
> and shouldn't be an issue for CIPE) and saw
> that the box behind the firewall could initiate
> a connection and for some short time the return
> packets would be allowed.  After a few seconds
> of idle time the other end could not start a
> new connection through the tunnel. The firewall
> was only allowing the return UDP packets to pass
> for a short time after one had been sent. This
> doesn't exactly match your description, but it
> may be some similar 'stateful' behavior in the
> firewalls so be sure your netcat tests used the
> same udp ports and had similar timing before
> deciding they are not the problem.
To make things simple:
- Cipe uses UDP.
- UDP is connectionless.
- Address translation on a firewall uses pseudo connections (remembering
  source + destination IP's to be able to send get reply packets back to
  the sender of the request packet).
- These NAT pseudo connections must timeout or else the firewall would
  run out of memory. More, you would not like some random party you did
  communicate with somewhere in the past to open some reverse
communication
  on it's own accord.
- If there is no pseudo connection then the firewall just has no clue
where
  to to send the received UDP packet, even if it was allowed.
- If netcat soes show different, you have discovered am extreme bug in
the
  firewall (or more likely you screwed the test).
- This is complex yet very fundamental routing and firewall stuff.

There's been some buzz about cipe behind a firewall, most doing NAT. I
already gave the reason why it will not work. Now I will give the reason
why you should not want it and why you cannot expect professional admins
to cooperate:
- If there is a firewall, it's there with good reason.
- Various stray tunnels that puncture through the firewall effectively
negate the effort.
- If you are not allowed officially to run your tunnel, there will again
be good reason.
- If you do not understand why your tunnel will not work from behind the
firewall,
  they were right not to allow you any access to that firewall and not
allow you to
  run the tunnel in the first place.
- The only way to get cipe working from behind such a firewall is to
step over to
  the firewall admin and have him do port-forwarding for you (he would
be insane
  to do it and I guess you already know the answer anyway).

I hope this answer is clear and that we can close the topic. If I'm
capable I would like to help anybody who's using cipe to strengthen
security and extend network functionality as I would guess it was
intended for. I simply don't like to support usage of cipe as a firewall
busting tool by ignorant users. Of course you are the exception with
completely legitimate reason, but I hope I made my point of view clear
enough.

CIAO
Peter





<< | Thread Index | >> ]    [ << | Date Index | >> ]