Re: Rephrasing my UDP question



(Foreward: Thanks to those who helped flesh out my ideas and guide me.)

I just finished a [very] rough draft of this system. If you're
interested check it out.
http://seacow.rapturesecurity.org/tmp/udp-tcp-udp-0.0.1.tar.bz2

It's likely to be rather buggy. Error checking is very lazy. You'll have
to change the DNS server to point to your own:
udpsa.sin_addr.s_addr = inet_addr("172.16.5.100"); /* DNS Server */

Read the "README" file for details on how to use it.
I just added the following to the README as well.

How it works:
The `client` listens on UDP port 53 on localhost (i.e. DNS) and forwards
DNS requests through TCP port 4242 on localhost which is tunneled through SSH
to TCP port 4242 on the localhost of your shell server. The `server` listsens on
that TCP port 4242 on the localhost of your shell server and then forwards
the DNS requests to your REAL DNS server.
When `server` gets a response from the real DNS server it forwards that packet through
the SSH tunnel to the `client` which forwards it back to the original application
doing the DNS lookup.



On Tue, 06 Dec 2005 22:04:20 -0800, Anthony de Almeida Lopes wrote:

> I'm just really confused as to how these UDP-over-TCP tunnel programs know
> how to send the UDP packet to the original application that sent the
> packet to be tunnled. I noticed that none of them use recvfrom(2) (except
> for debugging) and none of them keep any kind of linked list or anything
> to keep track of the packets.
>
> To be more clear:
> A program (say, mozilla or something) sends a DNS request to localhost:53
> ("nameserver localhost" is in your /etc/resolv.conf"). A program is
> listeing on on localhost:53 and forwards the packet to localhost:4242,
> which is connected to a remote host listening on remotehost:4242. The
> remotehost sends the packet over UDP and awaits a response and when it
> gets one, sends it back over 4242->4242 and the program on the localhost
> sends it back to the original program.
> Ijust do not understand how this works. How do the tunneling programs
> have any idea which programs should received which responses.
>
> For example: http://zarb.org/~gc/html/udp-in-ssh-tunneling.html
> and another program called "udptunnel"
> http://www1.cs.columbia.edu/~lennox/udptunnel/.
>
> My only idea is to use a combination of recvfrom(2) and linked lists to
> keep track of all of this.
>
> Anyone know how this works?
> -Anthony

.



Relevant Pages

  • Re: Oracle listener redirect configure help
    ... server resolve it, is because when the redirect packet hits my host, I ... want my host to resolve the DNS name, instead of having to use the IP ... The server sees the connection, makes the tcp 3 way handshake (passing ...
    (comp.databases.oracle.server)
  • Re: Oracle listener redirect configure help
    ... server resolve it, is because when the redirect packet hits my host, I ... want my host to resolve the DNS name, instead of having to use the IP ... The server sees the connection, makes the tcp 3 way handshake (passing ...
    (comp.databases.oracle.server)
  • Re: How to disable the "implicit mx record" in Exchange
    ... the host with the A record for the actual domain. ... So when Exchange gets a DNS timeout looking up an MX record, ... their own Exchange or other type of mail server under their own domain name, ... DNS UDP traffic max packet size is ...
    (microsoft.public.exchange.admin)
  • Excessive 7062 Errors
    ... I've been reciving a bucket load of 7062 errors on our office's server (SBS ... The DNS server encountered a packet addressed to itself on IP address ... configuration error. ...
    (microsoft.public.windows.server.sbs)
  • Re: Bad packets and invalid domain names Please help
    ... > The 5504 errors are usually from Exchange Server and if so are benign. ... > resolutions through your ISPs DNS, disable forwarders in your DNS and just resolve with the root hints - this can correct the bad ... >> Source DNS ... >> The DNS server encountered a bad packet from X.X.X.X. ...
    (microsoft.public.win2000.dns)

Loading