|
|
Hi, On Wed, Oct 05, 2005 at 02:22:38PM -0500, /dev/rob0 wrote: > 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? for port 80 alone this would probably work OK but the protocol of the software which is normally running on B is currently not analyzed and forwarding port 80 is not good enough. > > > There is no way that A can initiate a connection to B and vice versa. > > Why? Because the environment is restrictive and the firewalls are out of control (hint: every outgoing connection has to go over a proxy and there are no incoming connections possible), so please believe me, it is impossible. There are even internet providers that hand out private IP adresses to their customers and are NATing them and typically they have a pool of outgoing IP addresses which would complicate things further. I have tried hard to convince you that direct communication between A and B is impossible w/o M and if you dont believe me than I am out of luck :) > > > Both are located in different intranets and are also firewalled. > > So are my openvpn peers. Yes but you seem to be able to control the firewalls. > > > 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! Impossible. > > 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. it is not my fault alone... > > > > > 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 ..." yes, this trick is well known but unfortunately not applicable here. > > 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 Yes > A has static route to D using M as gateway Yes > M has static route to D using B as gateway This exactly is my problem. How do I specify B's address on M? I got the already mentioned errors when I tried to establish a route for D. > B does SNAT as detailed above. Yes > My case is special in that it would not even need M having a tun interface since no VPN packets need to go in and out there (assuming nobody wants to talk to M, e.g ssh to it or similar). All VPN routing is internal to M's openvpn instance only in my case. In fact, having the option to run w/o actual tun or tap interface on M would enable one to run an openvpn server instance on some virtual server machines like those on vserver.de. There you are unable to load modules, access tun/tap etc. Perhaps I will start a new thread about this topic. I just discovered (or re-discovered) the iroute option, perhaps it will enable me to do what I want. best regards again, Konrad ____________________________________________ Openvpn-users mailing list Openvpn-users@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/openvpn-users |