|
|
On Wednesday 2005-October-05 11:14, Konrad Karl wrote:
> > B is the one that needs the SNAT (not MASQUERADE, which is for
> > dynamic IP's) rules.
> >
> > A=10.100.0.4 ; B=10.100.0.8 ; D=172.16.1.1
> > iptables -vt nat -A POSTROUTING -s $A -d $D -j SNAT --to $B
>
> Yes, but packets with destination addr D have to go from A to B
> first.
Right. But if A can get to B and vice versa this will work:
> > You could also DNAT it. If, say, you wanted to forward B's port 80
> > to D's HTTP daemon also on port 80:
> > iptables -vt nat -A PREROUTING -s $A -p tcp --dport 80 -j DNAT --to
> > $D
No comment about that?
> There is no way that A can initiate a connection to B and vice versa.
Why?
> Both are located in different intranets and are also firewalled.
So are my openvpn peers.
> Without M no connectivity could be established between A and B.
Unless you know how to do it ...
> I have to use TCP for openvpn<>openvpn communication.
Ugly! Why? Don't you control the firewalls? Definitely enable UDP!
If you *don't* control the firewalls you should talk to the
administrator. This so-called security (which I bet is not as tight as
mine) is preventing you from doing what you need to do.
> I am aware that I could run another set of openvpn instances on A and
> B to create a direct VPN link on top of the A<>M<>B VPN but I would
> very much like to avoid this tunnel inside another tunnel
> (performance, overhead etc.)
I would not have suggested such a thing. But now that you mention it,
you could save on performance and overhead by using a null cipher. I'm
not sure how to do that, but I recall that it is possible.
> > > exactly. M is the _only_ means for A and B to communicate to
> > > each other. it is the sole purpose for M to exist. A and B's
> >
> > Then M is a hindrance. It should not exist.
>
> See above.
You're not listening or not understanding.
> > > these connections are both NAT'ed. If it were possible for A's
> > > openvpn to connect to B's openvpn directly (or vice versa), M
> > > would not be needed. (M == mediator ;)
> >
> > Why did you think this was not possible? I have several peer
> > tunnels behind NAT on both ends. As long as at least one end has a
> > relatively static IP it is very easy.
>
> See above :) your situation does not seem to be as restricted as
> mine.
I control the firewalls, although in fact I have not made any
adjustments to get openvpn through from one NAT'ed endpoint to a remote
peer, also NAT'ed.
Here's how it works: Peer A knows to go to the external IP for peer B,
and vice versa. These external IP's are on Linux netfilter firewalls.
The peers are communicating over a single UDP port. The first packet
hits firewall B from peer A, and it drops it. Then peer B starts
sending to firewall A, and suddenly firewall B knows: this is an
"ESTABLISHED" "connection". (UDP has no connection in the TCP sense,
but to netfilter's conntrack driver, it's the same thing.) Firewall A
gets the reply from peer B and knows instantly to NAT it to peer A.
Now, in both logs you see "Peer connection established ..."
Some cheap routers seem to have trouble with NAT of UDP, insisting on
changing the source port. "--float" (or just "float" in a config file)
usually fixes the problem.
> best regards and thanks four your effort.
YW!
> I am sure there must be
> a reasonable way to do what I want. In my point of view M looks
There is, once you understand it. Your idea, internal routing on the
openvpn server, might work too. But why not:
A reaches B through client-to-client on M
A has static route to D using M as gateway
M has static route to D using B as gateway
B does SNAT as detailed above.
Basic IP routing stuff. I still do not think this is as hard as you're
convinced it is.
--
mail to this address is discarded unless "/dev/rob0"
or "not-spam" is in Subject: header
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|