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

To: Daniel Andor <Daniel.Andor,AT,physics,DOT,org>
Subject: Re: concrete udp forwarding question
From: Phil Scarratt <fil,AT,draxsen,DOT,com>
Date: Wed, 25 Jun 2003 11:42:48 +1000
Cc: cipe-l,AT,inka,DOT,de
Organization: Draxsen Technologies
References: <200306231916.11758.da209@cam.ac.uk> <3EF789DB.60305@draxsen.com> <200306241638.32766.da209@cam.ac.uk>

See below...

Daniel Andor wrote:
On Tuesday 24 June 2003 12:14 am, Phil Scarratt wrote:



(This doesn't address the issue of NAT.) :)

You may need to use MachineC instead of the routerNAT to get access to
MachineA with CIPE as you need to add firewall rules/port forwards to
the routerNAT. All the routerNAT really needs to do is allow the port
you select for CIPE to be forwarded from internal lan to internet.
NAT'ing will take care of routing the returning or incoming CIPE packets
from MachineA back to MachineB. If there is no available free port open
on the routerNAT then MachineC is the way - exactly the same applies (ie
just allow the port you select to be forwarded from internal to internet
and NAT will take care of rest. The problem with this of course is that
I presume the default gateway on MachineB is the routerNAT in which case
you will have to tell MachineB that the specific route to MachineA is
via MachineC.

Thanks for the analysis. I'm no network expert, but I think my experiences over the past day confirm what you say.

I now have it working, so for the benefit of others, this setup seems to work:

machineA options:
me              machineA.public.address:1111
key ...
maxerr -1

machineB options:
me               machineB.internal.address:1111
peer            machineA.public.address:1111
key              ...
maxerr -1
ping 10


1) It looks like the NAT router takes care of reverse mapping UDP port 1111 if an outgoing packet is sent. Therefore I don't need to use machineC.

This is one of the functionalities of NAT - it wraps the packet with a publicly accessible source ip so the destination returns it to the correct machine on the public network (ie the routerNAT) which then takes care of sending it to the real source machine (strips the wrap off and looks at who it belongs to). For this reason, it only works for internally initiated communications - to work from the other way ie public machine to internal private machine specific port forwarding needs to be configured on the router (ie port xxxx on my public interface is really for machine x port xxxx on my internal interface).

1b) It didn't work if the two UDP ports (to A and to B) were not the same. This was the case even when I set up udpproxy on machineC, because machineA, after sending a single packet to machineC, kept insisting on sending packets to the routerNAT, even though I had told it to send packets to machineC in the options file.

It would need to be a specific route table rule specifying that machine A's IP address was accessible via machine c.

2) It seems like I need the "ping" option to keep the NAT router forwarding the UDP packets it receives from machineA to machineB. (I have no idea what the time-out on the NAT router is, so I set 10 seconds as not too wasteful if resources.)

Not sure why this is the case. Mine worked fine (same configuration) without the ping. Might have something to do with the routerNAT (mine is a linux box).

3) What purpose does the "me" parameter in machineB options have? -- can I get rid of it somehow?

Tells CIPE on what interface the tunnel is setup - it's the carrier address. Can't be gotten rid of as far as I'm aware.

Hope this makes sense.

Yes, thanks very much.


Daniel Andor wrote:

Hi All,

I can't quite work out how to configure this setup, so I would be very
grateful for some help.

I have a machineA with a static IP, and a machineB behind a NAT router:

machineA <--- internet ---> routerNAT <--- internal LAN ---> machineB

How should I configure this to create a cipe vpn between machineA and B?

I do not have access to routerNAT.
There's another machineC, distinct from the router, which has interfaces
on both the internet *and* the internal LAN.  I have access to this to be
able to run userland programs.

Any help appreciated!

Message sent by the cipe-l,AT,inka,DOT,de mailing list.
Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>

-- Phil Scarratt Draxsen Technologies IT Contractor/Consultant 0403 53 12 71

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