Didn't need routes and now the LDAP service is installed over VPN, thanks again for the feedback.
>>> Erich Titl <erich.titl@xxxxxxxx> 07/09/07 12:05 AM >>>
Peter Njiiri schrieb:
> Again thanks for the feedback. Yes,you are correct with the
> interpretation of the network. The software I'm installing (LDAP client)
> that needs no NAT requires that the destination IP be 192.168.1.2. This
> is because the openVPN is running the LDAP server listening on
Can't you make it listen also on the tun interface 10.8.0.1?
So in this scenarios should I
> 1. use the destination IP as the VPN IP, i.e 10.8.0.1 as it seems using
> 192.168.1.2 doesn't works as the communication back from the LDAP server
> is going through NAT.
You could do some tricky routing.
> 2. Is the 10.8.0.1 address bound to the eth0 IP thus use it as the
> destination IP??
No, it is bound to the tun interface.
> 3. I tried ethernet bridging but it didn't work
What can I say, I don't like bridging.
> Please note that the remote IP the VPN client is referencing is
> configured on a switch behind the firewall which maps the internal nic
> to external access. Is this a problem?
Switches (most of the time) are layer 2, so they should be transparent
> I did a traceroute from the remote client (10.30.7.100) to the openVPN
> internal nic (192.168.1.2) and it shows only one hop to the destination
> (the hop is the destination address 192.168.1.2) whereas a traceroute
> from 192.168.1.2 to 10.30.7.9 shows three hops (hops through
> firewall,remote router then remote destination). When I ping 192.168.1.2
> from 10.30.7.100, I can see tcpdump activity on tun0 on the
> openVPNserver but if I ping 10.30.7.9 from 192.168.1.2 I DO NOT see
> tcpdump activity on tun0 on the client, it's received on eth1 on the
> client interface. Why is happening???
Your routing is incomplete. iproute2 is your friend if needed, else try
to make your LDAP server also listen on the tun interface, for a try
make it listen on all interfaces.