|
|
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.
> > > 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
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.
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.
> 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.
> 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.
> just for clarification: for testing purpose I have tried to set up
> masquerading on M like this:
>
> iptables -t nat -A POSTROUTING -s 10.100.0.0/255.255.255.0 -o eth0 -j
> MASQUERADE
M has confused and distracted you.
--
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
|