> 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
on it's own accord.
- If there is no pseudo connection then the firewall just has no clue
to to send the received UDP packet, even if it was allowed.
- If netcat soes show different, you have discovered am extreme bug in
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
- 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
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
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