iptables abilities

iptables abilities

[Sven Burgener]

Hello

I'm looking for a way to connect two parties (computers) that both have 
a private IP address.

          (Internet)       (Internet)
      A <------------> X <------------> B

A: 192.168.1.13
B: 192.168.1.99
X: public IP address

In other words, can iptables act as a "relay" between two computers 
which both have a private IP address?

Cheers
Sven

Re: iptables abilities

[Antony Stone]

On Thursday 22 January 2004 12:21 pm, Sven Burgener wrote:

> Hello
>
> I'm looking for a way to connect two parties (computers) that both have
> a private IP address.
>
>           (Internet)       (Internet)
>       A <------------> X <------------> B
>
> A: 192.168.1.13
> B: 192.168.1.99
> X: public IP address
>
> In other words, can iptables act as a "relay" between two computers
> which both have a private IP address?

You need to be able to route packets between A and B in order for netfilter to 
be able to consider whether to allow them or not.   The Internet will not 
route packets with private (RFC 1918) destination addresses.

Therefore you cannot do what you are suggesting with one netfilter box - you 
would need one at each end, near enough to A and B that they are on private 
networks, not routed across the Internet, doing NAT so that all the packets 
which flow across any bit of the Internet have public, routable, source and 
destination IPs.

Antony.

-- 
G- GIT/E d- s+:--(-) a+ C++++$ UL++++$ P+(---)>++ L+++(++++)$ !E W(-) N(-) o? 
w-- O !M V+++(--) !PS !PE Y+ PGP+> t- tv@ b+++ DI++ D--- e++>+++ h++ r@? 5? 
!X- !R K--?

                                                     Please reply to the list;
                                                           please don't CC me.

Re: iptables abilities

[David Cannings]

On Thursday 22 January 2004 12:21 pm, Sven Burgener wrote:
> I'm looking for a way to connect two parties (computers) that both have
> a private IP address.
>
>           (Internet)       (Internet)
>       A <------------> X <------------> B
>
> A: 192.168.1.13
> B: 192.168.1.99
> X: public IP address
>
> In other words, can iptables act as a "relay" between two computers
> which both have a private IP address?

If you want to create a network between these two over the internet, you 
might want some form of VPN.   FreeS/WAN (www.freeswan.org) comes to 
mind.

David

Re: iptables abilities

[Sven Burgener]

Antony Stone wrote:
>>I'm looking for a way to connect two parties (computers) that both have
>>a private IP address.
>>
>>          (Internet)       (Internet)
>>      A <------------> X <------------> B
>>
>>A: 192.168.1.13
>>B: 192.168.1.99
>>X: public IP address

Isnt't there a way that both, A and B initiate a connection to X where 
the two connections are then 'merged'?

Or, could B connect to X whereafter A 'hijacks' the connection between X 
and B? ;-)

Cheers
Sven

Re: iptables abilities

[John A. Sullivan III]

Is there any point at which you could use DNAT/SNAT to change each private
address to a public address? Alternately, can you build a VPN tunnel
between the two and tunnel the private addresses through the tunnel?

> Antony Stone wrote:
>>>I'm looking for a way to connect two parties (computers) that both have
>>>a private IP address.
>>>
>>>          (Internet)       (Internet)
>>>      A <------------> X <------------> B
>>>
>>>A: 192.168.1.13
>>>B: 192.168.1.99
>>>X: public IP address
>
> Isnt't there a way that both, A and B initiate a connection to X where
> the two connections are then 'merged'?
>
> Or, could B connect to X whereafter A 'hijacks' the connection between X
> and B? ;-)
>
> Cheers
> Sven
>
>


-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re: iptables abilities

[Sven Burgener]

Dear John

John A. Sullivan III wrote:
> Is there any point at which you could use DNAT/SNAT to change each private
> address to a public address? Alternately, can you build a VPN tunnel
> between the two and tunnel the private addresses through the tunnel?

Perhaps a VPN tunnel would be the best solution. How would such a thing 
be established though, given that both A and B have private addresses?

The two connections between A <--> X and X <--> B need to somehow be 
interconnected. Can this be done with VPN?

>>>>         (Internet)       (Internet)
>>>>     A <------------> X <------------> B
>>>>
>>>>A: 192.168.1.13
>>>>B: 192.168.1.99
>>>>X: public IP address

Cheers
Sven

Re: iptables abilities

[Antony Stone]

On Friday 23 January 2004 8:59 am, Sven Burgener wrote:

> Dear John
>
> John A. Sullivan III wrote:
> > Is there any point at which you could use DNAT/SNAT to change each
> > private address to a public address? Alternately, can you build a VPN
> > tunnel between the two and tunnel the private addresses through the
> > tunnel?
>
> Perhaps a VPN tunnel would be the best solution. How would such a thing
> be established though, given that both A and B have private addresses?
>
> The two connections between A <--> X and X <--> B need to somehow be
> interconnected. Can this be done with VPN?

You can connect anything you like with a VPN, because the whole point about 
the P part of a VPN is that you are in charge of what it will route and what 
it won't - it is your Private network, not part of the open public Internet.

The only reason you can't route private addresses across the Internet is that 
all ISP routers drop packets sent to these address ranges.

You would set up your VPN system to forward these packets, just the same as 
you can set up your own firewalls and routers to forward them if you want to.

A VPN with two RFC1918 ranges at each end is a very common setup.

Regards,

Antony.

-- 
"The joy of X!!??  I've always hated compiling graphical shite.  You have a 10 
line program, and it ends up depending on the entire known universe."

 - Philip Hands

                                                     Please reply to the list;
                                                           please don't CC me.

Re: iptables abilities

[Sven Burgener]

Antony Stone wrote:
> The only reason you can't route private addresses across the Internet is that 
> all ISP routers drop packets sent to these address ranges.

Right.

> You would set up your VPN system to forward these packets, just the same as 
> you can set up your own firewalls and routers to forward them if you want to.
> 
> A VPN with two RFC1918 ranges at each end is a very common setup.

Yes, indeed.

My question, though, is how can a connection be established between two 
parties where one of them has a private address (A) and where you want 
to connect _to_ the server having the private address (A, see below).

The problem is, you can't establish a connection to the private address 
(A), so there has to be a means of 'hijacking' the established session 
(from X, see diagram below).


         (Internet)       (Internet)
     A <------------> X <------------> B

A: 192.168.X.X
B: 192.168.X.X
X: public IP address

The end result is to get from B to A, securely.

Cheers
Sven

Re: iptables abilities

[Antony Stone]

On Friday 23 January 2004 10:23 am, Sven Burgener wrote:

> My question, though, is how can a connection be established between two
> parties where one of them has a private address (A) and where you want
> to connect _to_ the server having the private address (A, see below).
>
> The problem is, you can't establish a connection to the private address
> (A), so there has to be a means of 'hijacking' the established session
> (from X, see diagram below).
>
>          (Internet)       (Internet)
>      A <------------> X <------------> B
>
> A: 192.168.X.X
> B: 192.168.X.X
> X: public IP address
>
> The end result is to get from B to A, securely.

X cannot connect to either of the private addresses A or B, because you show 
both these routes as going across the Internet, and as you correctly say 
yourself, you cannot connect to a private address across the Internet.

In order to connect from A to B across the Internet (let's ignore X for now, I 
think it serves no useful purpose), both A and B must be given public 
(routable) addresses, even if these are provided by some sort of NAT going on 
at the point where A's network and B's network each plug in to the Internet.

In order to connect from A to B securely, you need a secure protocol (HTTPS or 
SSH would be good examples) or a VPN if you want to connect insecure 
protocols (such as HTTP, FTP, POP3, SMTP etc).   Setting up a VPN between A 
and B requires two machines, each with a public address, one at A's point of 
connection to the Internet, and one at B's point of connection - these two 
machines set up a secure tunnel between them (eg using IPsec) and then they 
route packets from A to B (using the 'real' private addresses of A and B) 
through this tunnel.

I think the basic point which has to be made regarding your question is that 
in order to connect between two machines across the Internet, they *both* 
need to have public routable addresses (either directly, or via NAT), 
otherwise your packets will get discarded before they reach their 
destination.

Regards,

Antony.

-- 
This is not a rehearsal.
This is Real Life.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: iptables abilities

[John A. Sullivan III]

> Antony Stone wrote:
>> The only reason you can't route private addresses across the Internet is
>> that
>> all ISP routers drop packets sent to these address ranges.
>
> Right.
>
>> You would set up your VPN system to forward these packets, just the same
>> as
>> you can set up your own firewalls and routers to forward them if you
>> want to.
>>
>> A VPN with two RFC1918 ranges at each end is a very common setup.
>
> Yes, indeed.
>
> My question, though, is how can a connection be established between two
> parties where one of them has a private address (A) and where you want
> to connect _to_ the server having the private address (A, see below).
>
> The problem is, you can't establish a connection to the private address
> (A), so there has to be a means of 'hijacking' the established session
> (from X, see diagram below).
>
>
>          (Internet)       (Internet)
>      A <------------> X <------------> B
>
> A: 192.168.X.X
> B: 192.168.X.X
> X: public IP address
>
> The end result is to get from B to A, securely.
>
> Cheers
> Sven
>

I don't know if it is what you are looking for but Bart Smit of Nexus
Management developed an application to allow Nexus Management to provide
remote control Help Desk to sites where we did not have a VPN connection. 
I do not know many of the details but I think the two stations connect to
each other through a third public server as you have described here.  The
two private computers do not require dedicated public IP addresses.  I
believe port address translation is all that is needed.

I do not know if it can be readily adapted to other services besides
remote control.  I do not know if the application is licensed under GPL or
if it is proprietary and available from Nexus for a fee.  If it is of
interest to you, let me know and I'll find out - John

-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re: iptables abilities

[Antony Stone]

On Friday 23 January 2004 1:33 pm, John A. Sullivan III wrote:

> > The problem is, you can't establish a connection to the private address
> > (A), so there has to be a means of 'hijacking' the established session
> > (from X, see diagram below).
> >
> >          (Internet)       (Internet)
> >      A <------------> X <------------> B
> >
> > A: 192.168.X.X
> > B: 192.168.X.X
> > X: public IP address
> >
> > The end result is to get from B to A, securely.
> >
> > Cheers
> > Sven
>
> I don't know if it is what you are looking for but Bart Smit of Nexus
> Management developed an application to allow Nexus Management to provide
> remote control Help Desk to sites where we did not have a VPN connection.
> I do not know many of the details but I think the two stations connect to
> each other through a third public server as you have described here.  The
> two private computers do not require dedicated public IP addresses.

They may not require *dedicated* public IP addresses, but there still have to 
*be* public IP addresses available at ends A and B of the links, otherwise X 
cannot send reply packets back to them.

So long as A and B have public IPs which they can NAT behind, then there's no 
problem - they can either communicate directly, or if you want to channel the 
link via some other server X on the Internet you could do that easily enough 
with a couple of SSH tunnels back to back.   Given public IPs all sorts of 
opportunities come to mind.

I still say however that if A and B do not have public IPs available to hide 
behind, then they can't communicate with *anything* across the Internet.

Regards,

Antony.


-- 
The words "e pluribus unum" on the Great Seal of the United States are from a 
poem by Virgil entitled "Moretum", which is about cheese and garlic salad 
dressing.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: iptables abilities

[Sven Burgener]

Antony Stone wrote:
> They may not require *dedicated* public IP addresses, but there still have to 
> *be* public IP addresses available at ends A and B of the links, otherwise X 
> cannot send reply packets back to them.
> 
> So long as A and B have public IPs which they can NAT behind, then there's no 
> problem - they can either communicate directly, or if you want to channel the 
> link via some other server X on the Internet you could do that easily enough 
> with a couple of SSH tunnels back to back.   Given public IPs all sorts of 
> opportunities come to mind.
> 
> I still say however that if A and B do not have public IPs available to hide 
> behind, then they can't communicate with *anything* across the Internet.

Yes, I totally get you. Thing is, I am looking for a way to connect to 
some machine which may be hidden behind some NAT/Firewall etc. from a 
server which has a public address.

So, the only solution that comes to mind is: That given ("hidden") 
machine initiates the connection to the public server/address (because 
it can). Next, this established session needs to be somehow 
used/'hijacked' to "get to" the 'hidden' server. Follow me? ;-)

Cheers
Sven

Re: iptables abilities

[Antony Stone]

On Friday 23 January 2004 4:39 pm, Sven Burgener wrote:

> Antony Stone wrote:
> >
> > I still say however that if A and B do not have public IPs available to
> > hide behind, then they can't communicate with *anything* across the
> > Internet.
>
> Yes, I totally get you. Thing is, I am looking for a way to connect to
> some machine which may be hidden behind some NAT/Firewall etc. from a
> server which has a public address.
>
> So, the only solution that comes to mind is: That given ("hidden")
> machine initiates the connection to the public server/address (because
> it can). Next, this established session needs to be somehow
> used/'hijacked' to "get to" the 'hidden' server. Follow me? ;-)

Oh, right, yes.

In that case, netcat.

Antony.

-- 
The first fifty percent of an engineering project takes ninety percent of the 
time, and the remaining fifty percent takes another ninety percent of the 
time.

                                                     Please reply to the list;
                                                           please don't CC me.

RE: iptables abilities

[bmcdowell]

Are you by any chance referring to the phenomenon where everyone in the
world uses 192.168.1.0/24 as their internal subnet?  Wherein even if you
can get the two private subnets linked together routing fails to happen?

If so, I don't think there's a solution.  Or not a good one at any rate.
If you could guarantee unique addresses at each end, you might be able
to pull something off with a bridge.  Or, perhaps you could use some
NAT-magic to add 100 to the foreign IP's while in transit.  (By that I
mean make .1 equal to .101 on the other network.)  Still though, this is
a bad idea.  One out-of-scope IP would kill a setup of this type.  And,
since changing one subnet or the other is probably the first idea people
get when faced with this, I'd guess you can't control the scopes.

Or, maybe I misunderstood.


Bob

-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Sven Burgener
Sent: Friday, January 23, 2004 4:24 AM
To: netfilter@lists.netfilter.org
Subject: Re: iptables abilities


Antony Stone wrote:
> The only reason you can't route private addresses across the Internet
is that 
> all ISP routers drop packets sent to these address ranges.

Right.

> You would set up your VPN system to forward these packets, just the
same as 
> you can set up your own firewalls and routers to forward them if you
want to.
> 
> A VPN with two RFC1918 ranges at each end is a very common setup.

Yes, indeed.

My question, though, is how can a connection be established between two 
parties where one of them has a private address (A) and where you want 
to connect _to_ the server having the private address (A, see below).

The problem is, you can't establish a connection to the private address 
(A), so there has to be a means of 'hijacking' the established session 
(from X, see diagram below).


         (Internet)       (Internet)
     A <------------> X <------------> B

A: 192.168.X.X
B: 192.168.X.X
X: public IP address

The end result is to get from B to A, securely.

Cheers
Sven

Re: iptables abilities

[Antony Stone]

On Friday 23 January 2004 7:48 pm, bmcdowell@coxhealthplans.com wrote:

> Are you by any chance referring to the phenomenon where everyone in the
> world uses 192.168.1.0/24 as their internal subnet?  Wherein even if you
> can get the two private subnets linked together routing fails to happen?
>
> If so, I don't think there's a solution.  Or not a good one at any rate.
> If you could guarantee unique addresses at each end, you might be able
> to pull something off with a bridge.  Or, perhaps you could use some
> NAT-magic to add 100 to the foreign IP's while in transit.  (By that I
> mean make .1 equal to .101 on the other network.)  Still though, this is
> a bad idea.  One out-of-scope IP would kill a setup of this type.  And,
> since changing one subnet or the other is probably the first idea people
> get when faced with this, I'd guess you can't control the scopes.
>
> Or, maybe I misunderstood.

I don't think Sven's problem is *quite* as bad as this (although I too could 
be mistaken and not realised that 192.168.X.X in his original diagram could 
in fact mean the same subnets in use at both ends....).

However, I agree with you that when this does turn out to be the case, there 
is no solution which works cleanly other than renumbering at least one of the 
networks (or splitting them into different subnet ranges).

I think we'll find out once he's looked into netcat to see if it will meet his 
needs.

Regards,

Antony.

-- 
Ramdisk is not an installation procedure.

                                                     Please reply to the list;
                                                           please don't CC me.