hello everyone,
i think i have reached a point of burnout here.. and i need someone to follow through my steps, see where i am faulting
please please....
here is the story:
home network:
-subnet 192.168.0.0/24,
-gateway (@ the modem/router) 192.168.0.1
-slackserv@home linux slackware with openvpn daemon running as server too 192.168.0.6
-slackclient@home 192.168.0.19 a linux slackware random client
-winxp@home 192.168.0.3
office network
-subnet 192.168.1.0/24
-gateway (@ a windows 2008 server box) 192.168.1.2
-gateway (@ modem/router) 192.168.1.1 (is not used as a gateway at the moment but could)
-winxp@work with openvpn daemon running as vpn client 192.168.1.107
-slack@work a slackware box i recently installed at work 192.168.1.10
vpn network
-subnet 192.168.144.0/24
-vpn server 192.168.144.1, on iface 192.168.0.6 at home's network
-vpn client winxp@work (among others) 192.168.144.10, on iface 192.168.1.107 at works network.
i basically want all pcs from the home network to be able to see all pcs at work..and vice versa..
i have managed (finally!) to get the client-side computers (work network) to see the server side computers.... but i still can't get the opposite to work..
for the purposes of starting from somewhere, ssh'ing from slackclient@home towards slack@work would be wonderful..
Theoretically speaking, the way i understand networks, the following should apply:
the gateway@home should incorporate static routes to redirect traffic with destination 192.168.144.0/24 (vpn) and -more importantly-192.168.1.0/24 (work) subnets to the vpn server gateway slackserv@home.
this way, any pc at the home subnet, will be able to ping/ssh etc. addresses directly in the work subnet.
once packets reach the slackserv@home, iptables will have to accept traffic with destination to vpn and work subnets. Since the vpn server will do the redirecting (by using the routing table - correct me if im wrong in this), the input chain is the one that should allow traffic that originates from the home subnet and is destined for the work subnet). note that prerouting chain is left empty.
so a rule like,
Code:
#placed at the input chain
$IPT -A tcp_inbound -p TCP -s $HOMENET -d $WORKNET -i $INET_IFACE -j ACCEPT
should do there trick....
then packets destined for work subnet, are delivered to the tun interface, following routing table rule
Code:
192.168.1.0 192.168.144.2 255.255.255.0 UG 0 0 0 tun0
(a rule that the vpn daemon generated, in boot up)
is there a postrouting directive that i should add to the iptables chain like snat or smth?
finally they leave the vpn server and reach the vpn client winxp@work..
if the tun interface at the client is NOT firewalled, packets should quickly follow the clients routing table and be redirected to the ethernet adapter, and from there on, get delivered to the pc@work with the corresponding ip address...
well if that is the theory, practice doesn't work for me :P
even without running any firewall on slackserv@home, slackclient@home, winxp@work and gateway@work... i still cant get access to the slack@work from
slackclient@home....aarrrgghh
i followed the openvpn HOW TO
http://www.openvpn.net/index.php/ope...wto.html#scope word by word...
-so i added a file at the client-config-dir with filename the common name of the vpn client and contents
Quote:
|
iroute 192.168.1.0 255.255.255.0
|
-i went back to the server configuration and added the path to this file (in the client) as
Quote:
client-config-dir /etc/openvpn/clients
route 192.168.1.0 255.255.255.0
|
i checked that ip_foward is enabled at the slackserv@home (vpn server)..
finally all firewalls are down..
and if i do traceroute from slackclient@home towards slack@work i get the following
Quote:
nass@stardust:~$ traceroute 192.168.1.10
traceroute to 192.168.1.10 (192.168.1.10), 30 hops max, 38 byte packets
1 siemens (192.168.0.1) 3.344 ms 1.103 ms 0.962 ms
2 stargaze.nebula.org (192.168.0.6) 4.631 ms 1.320 ms 1.096 ms
3 * * *
4 * *
|
during vpn negotiations things seem to start normally
Quote:
Mon Nov 2 02:52:56 2009 <ip@work>:19264 Re-using SSL/TLS context
Mon Nov 2 02:52:56 2009 <ip@work>:19264 LZO compression initialized
Mon Nov 2 02:52:56 2009 <ip@work>:19264 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Mon Nov 2 02:52:56 2009 <ip@work>:19264 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
Mon Nov 2 02:52:56 2009 <ip@work>:19264 Local Options hash (VER=V4): '530fdded'
Mon Nov 2 02:52:56 2009 <ip@work>:19264 Expected Remote Options hash (VER=V4): '41690919'
Mon Nov 2 02:52:56 2009 <ip@work>:19264 TLS: Initial packet from 85.75.20.80:19264, sid=39807ff5 7fa961b0
...
...
...
Mon Nov 2 02:52:57 2009 <ip@work>:19264 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Nov 2 02:52:57 2009 <ip@work>:19264 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 2 02:52:57 2009 <ip@work>:19264 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Mon Nov 2 02:52:57 2009 <ip@work>:19264 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Mon Nov 2 02:52:57 2009 <ip@work>:19264 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Mon Nov 2 02:52:57 2009 <ip@work>:19264 [rodos] Peer Connection Initiated with 85.75.20.80:19264
Mon Nov 2 02:52:57 2009 rodos/<ip@work>:19313 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/clients/rodos
Mon Nov 2 02:52:57 2009 rodos/<ip@work>:19264 MULTI: Learn: 192.168.144.14 -> rodos/85.75.20.80:19264
Mon Nov 2 02:52:57 2009 rodos/<ip@work>:19264 MULTI: primary virtual IP for rodos/<ip@work>:19264: 192.168.144.14
Mon Nov 2 02:52:58 2009 rodos/<ip@work>:19264 PUSH: Received control message: 'PUSH_REQUEST'
Mon Nov 2 02:52:58 2009 rodos/<ip@work>:19264 SENT CONTROL [rodos]: 'PUSH_REPLY,route 192.168.0.0 255.255.255.0,route 192.168.144.1,ping 10,ping-restart 120,ifconfig 192.168.144.14 192.168.144.13' (status=1)
|
(some lines have been intentionally left out) - rodos is the common name of the winxp@work client vpn certificate...
PLEASE Please please,
if you have managed to make visible the client side network to the server side network in a similar topology... can you give me any hints?
Thank you in advance for your help...
