|
|
Hi,
On Wed, Oct 05, 2005 at 10:44:24AM -0500, /dev/rob0 wrote:
> On Wednesday 2005-October-05 04:40, Konrad Karl wrote:
> > yes, I know that it may seem wierd what I want to do, but pls
> > look below.
>
> I think I understand now, and I think you're making it too difficult.
I dont think that I am making it too difficult, it already is :)
pls see below.
>
> > > > Machine A wants to access machine D via NAT/MASQUERADE on
> > > > machine B.
> > >
> > > Why NAT?
> >
> > Because machine D (its actually some black box like smart card
> > reader) only wants to communicate with B. (some kind of firewalling
> > internal in D) IP source addresses other than B's other than
> > 192.168.2.1 (in our example) are rejected/filterd within D.
>
> 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.
>
> Isn't that easy? Of course now B is a router and must have forwarding
> enabled ("echo 1 > /proc/sys/net/ipv4/ip_forward"), and nothing in
> filter / FORWARD to block this traffic.
correct. B has to be a router. SNAT and MASQUERADE are basically working
the same way, I just the term MASQUERADE because of being used to it.
>
> 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
>
> > > you just use a route like this on A:
> > > ip route add 172.16.0.0/12 via 10.100.0.8
> >
> > How is this supposed to work?
> > 10.100.0.8 is not directly reachable from A and I am getting
> > the SIOCADDRT: Network is unreachable message.
>
> I don't know! Again you have complicated this by putting 2 client-to-
> server connections where a single peer tunnel would work better.
There is no way that A can initiate a connection to B and vice versa.
Both are located in different intranets and are also firewalled.
Without M no connectivity could be established between A and B.
I have to use TCP for openvpn<>openvpn communication.
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.)
>
> > The routing on A for dest 172.16.0.0/16 is fine. The packets are
> > going out using openvpn's tun interface. If all would work the would
> > find their way to B via openvpn, then get masqueraded and forwarded
> > on B's eth0 , find their way to D via ROUTER and al this should work
> > fine also in the reverse direction because of the masquerading.
>
> Then maybe the SNAT rule is all you need? Are the packets getting to B,
> or being eaten by M?
>
> > > > (on M client-to-client is enabled)
> > >
> > > Client-to-client is a --mode server feature. I am confused. A and B
> > > are each clients of server M and not directly tunnelled? Probably
> >
> > 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 local
>
> Then M is a hindrance. It should not exist.
See above.
>
> > M has direct connection to the official internet via its eth0 and of
> > course A and B openvpn clients are able to connect to M but 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.
[deleted]
best regards and thanks four your effort. I am sure there must be
a reasonable way to do what I want. In my point of view M looks
like a router (there would not even be a need for a tun device on M)
and I need to add some special routes to this internal openvpn
routing engine.
Konrad
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|