Page 1 of 1

Problem trying to route to different subnets

Posted: Sat Jan 25, 2014 7:28 pm
by hlightstone
Openvpn server is running on ipcop 2.x

I want two different (client) logins to route to different subnets behind ipcop

the "store" login is supposed to only see the 192.168.51.x subnet while the "admin" is supposed to see the 192.168.50.x subnet.

I tried following a sample in the howto but....
if I route both subnets in the server config, both clients can see both networks

I keep thinking this should be simple but I clearly don't understand...

server.conf

# OpenVPN server configuration
# Do not modify '/var/ipcop/openvpn/server.conf' directly since any changes
# you make will be overwritten whenever you resave openvpn settings using the
# web interface!

daemon openvpnserver
writepid /var/run/openvpn.pid
dev tun
tun-mtu 1400
proto udp
port 1194
tls-server
ca /var/ipcop/ca/cacert.pem
cert /var/ipcop/certs/hostcert.pem
key /var/ipcop/certs/hostkey.pem
dh /var/ipcop/private/dh1024.pem
script-security 2
server 10.137.80.0 255.255.255.0
route 10.137.81.0 255.255.255.0
route 10.137.82.0 255.255.255.0
#route 192.168.50.0 255.255.255.0
#route 192.168.51.0 255.255.255.0
client-config-dir /var/ipcop/openvpn/ccd

keepalive 10 60
client-connect /usr/local/bin/openvpn.sh
client-disconnect /usr/local/bin/openvpn.sh
status-version 1
status /var/log/openvpnserver.log 30
cipher BF-CBC
max-clients 100
tls-verify /usr/local/bin/openvpnverify
crl-verify /var/ipcop/crls/cacrl.pem
user nobody
group nobody
persist-key
persist-tun
verb 3
--------------------------------------------------
/var/ipcop/openvpn/ccd/store
iroute 192.168.51.0 255.255.255.0
ifconfig-push 10.137.82.1 10.137.82.2
echo "done push"

--------------------------------------------------
rc.firewall.local
#!/bin/sh
# Used for private firewall rules
#
# $Id: rc.firewall.local 1912 2008-09-16 20:11:47Z owes $
#

# read variables
eval $(/usr/local/bin/readhash /var/ipcop/ethernet/settings)
if [ -f /var/ipcop/red/iface ]; then
REAL_RED=`cat /var/ipcop/red/iface`
fi

# See how we were called.
case "$1" in
start)
## add your 'start' rules here
iptables -A FORWARD -i tun -s 10.137.80.0/24 -d 192.168.52.0/24 -j DROP
iptables -A FORWARD -i tun -s 10.137.81.0/24 -d 192.168.50.0/24 -j ACCEPT
iptables -A FORWARD -i tun -s 10.137.82.0/24 -d 192.168.51.0/24 -j ACCEPT

;;
stop)

--------------------------------------------------------------
server log file

11:12:16 openvpnserver[23085] MULTI: multi_create_instance called
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Re-using SSL/TLS context
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Control Channel MTU parms [ L:1441 D:138 EF:38 EB:0 ET:0 EL:0 ]
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Data Channel MTU parms [ L:1441 D:1441 EF:41 EB:4 ET:0 EL:0 ]
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Local Options hash (VER=V4): '778eeec5'
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Expected Remote Options hash (VER=V4): '57657c3f'
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 TLS: Initial packet from xx.xx.xx.xxx:1194, sid=2089e9dc 52267f62
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 VERIFY SCRIPT OK: depth=1, /C=US/O=Lemma/CN=Lemma_CA
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 CRL CHECK OK: /C=US/O=Lemma/CN=Lemma_CA
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 VERIFY OK: depth=1, /C=US/O=Lemma/CN=Lemma_CA
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 VERIFY SCRIPT OK: depth=0, /C=US/O=Lemma/CN=store
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 CRL CHECK OK: /C=US/O=Lemma/CN=store
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 VERIFY OK: depth=0, /C=US/O=Lemma/CN=store
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
11:12:16 openvpnserver[23085] xx.xx.xx.xxx:1194 [store] Peer Connection Initiated with xx.xx.xx.xxx:1194
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 OPTIONS IMPORT: reading client specific options from: /var/ipcop/openvpn/ccd/store
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 ECHO:done push
11:12:16 openvpn CONNECT store 10.137.82.1 xx.xx.xx.xxx
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_6f1e08fc944c020d6a56b9206f2822b5.tmp
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 MULTI: Learn: 10.137.82.1 -> store/xx.xx.xx.xxx:1194
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 MULTI: primary virtual IP for store/xx.xx.xx.xxx:1194: 10.137.82.1
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 MULTI: internal route 192.168.51.0/24 -> store/xx.xx.xx.xxx:1194
11:12:16 openvpnserver[23085] store/xx.xx.xx.xxx:1194 MULTI: Learn: 192.168.51.0/24 -> store/xx.xx.xx.xxx:1194
11:12:17 openvpnserver[23085] store/xx.xx.xx.xxx:1194 PUSH: Received control message: 'PUSH_REQUEST'
11:12:17 openvpnserver[23085] store/xx.xx.xx.xxx:1194 SENT CONTROL [store]: 'PUSH_REPLY,route 10.137.80.1,topology net30,ping 10,ping-restart 60,ifconfig 10.137.82.1 10.137.82.2' (status=1)

--------------------------------------------------------------------------------------------------------
client log

Sat Jan 25 11:14:20 2014 OpenVPN 2.1_beta7 Win32-MinGW [SSL] [LZO2] built on Nov 12 2005
Sat Jan 25 11:14:20 2014 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sat Jan 25 11:14:26 2014 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1400)
Sat Jan 25 11:14:26 2014 Control Channel MTU parms [ L:1441 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Jan 25 11:14:27 2014 Data Channel MTU parms [ L:1441 D:1441 EF:41 EB:4 ET:0 EL:0 ]
Sat Jan 25 11:14:27 2014 Local Options hash (VER=V4): '57657c3f'
Sat Jan 25 11:14:27 2014 Expected Remote Options hash (VER=V4): '778eeec5'
Sat Jan 25 11:14:27 2014 Socket Buffers: R=[8192->8192] S=[8192->8192]
Sat Jan 25 11:14:27 2014 UDPv4 link local (bound): [undef]:1194
Sat Jan 25 11:14:27 2014 UDPv4 link remote: xx.xx.xx.xxx:1194
Sat Jan 25 11:14:27 2014 TLS: Initial packet from xx.xx.xx.xxx:1194, sid=eaf44dbf 004194d5
Sat Jan 25 11:14:27 2014 VERIFY OK: depth=1, /C=US/O=Lemma/CN=Lemma_CA
Sat Jan 25 11:14:27 2014 VERIFY OK: nsCertType=SERVER
Sat Jan 25 11:14:27 2014 VERIFY OK: depth=0, /C=US/O=Lemma/CN=xx.xx.xx.xxx
Sat Jan 25 11:14:27 2014 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 25 11:14:27 2014 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 25 11:14:27 2014 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Sat Jan 25 11:14:27 2014 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Jan 25 11:14:27 2014 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Sat Jan 25 11:14:27 2014 [xx.xx.xx.xxx] Peer Connection Initiated with xx.xx.xx.xxx:1194
Sat Jan 25 11:14:28 2014 SENT CONTROL [xx.xx.xx.xxx]: 'PUSH_REQUEST' (status=1)
Sat Jan 25 11:14:28 2014 PUSH: Received control message: 'PUSH_REPLY,route 10.137.80.1,topology net30,ping 10,ping-restart 60,ifconfig 10.137.82.1 10.137.82.2'
Sat Jan 25 11:14:28 2014 OPTIONS IMPORT: timers and/or timeouts modified
Sat Jan 25 11:14:28 2014 OPTIONS IMPORT: --ifconfig/up options modified
Sat Jan 25 11:14:28 2014 OPTIONS IMPORT: route options modified
Sat Jan 25 11:14:28 2014 TAP-WIN32 device [Local Area Connection 2] opened: \\.\Global\{16BED595-1F44-464C-8A12-B2B15300D5E8}.tap
Sat Jan 25 11:14:28 2014 TAP-Win32 Driver Version 8.3
Sat Jan 25 11:14:28 2014 TAP-Win32 MTU=1500
Sat Jan 25 11:14:28 2014 Notified TAP-Win32 driver to set a DHCP IP/netmask of 10.137.82.1/255.255.255.252 on interface {16BED595-1F44-464C-8A12-B2B15300D5E8} [DHCP-serv: 10.137.82.2, lease-time: 31536000]
Sat Jan 25 11:14:28 2014 Successful ARP Flush on interface [196612] {16BED595-1F44-464C-8A12-B2B15300D5E8}
Sat Jan 25 11:14:28 2014 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Sat Jan 25 11:14:28 2014 Route: Waiting for TUN/TAP interface to come up...
Sat Jan 25 11:14:29 2014 TEST ROUTES: 0/0 succeeded len=1 ret=0 a=0 u/d=down
Sat Jan 25 11:14:29 2014 Route: Waiting for TUN/TAP interface to come up...
Sat Jan 25 11:14:30 2014 TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
Sat Jan 25 11:14:30 2014 route ADD 10.137.80.1 MASK 255.255.255.255 10.137.82.2
Sat Jan 25 11:14:30 2014 Route addition via IPAPI succeeded
Sat Jan 25 11:14:30 2014 Initialization Sequence Completed

Re: Problem trying to route to different subnets

Posted: Sun Jan 26, 2014 9:31 pm
by hlightstone
Yes, I started with that as the baseline. I realize it assumes all the users are on the same network and I am not but I guess I'll try reconfiguring and try EXACTLY that setup. Tomorrow.

Re: Problem trying to route to different subnets

Posted: Sun Jan 26, 2014 10:32 pm
by hlightstone
Probably where my confusion exists.

I have two lans 192.168.50.x and 192.168.51.x --- on an IPCOP firewalled system

The 192.168.50.x machines need to have full access to the 192.168.51.x machines but
the 192.168.51.x machines must have no access to the .50.x network.

In IPCOP, I put the .50.x systems on a GREEN subnet and the 51.x systems on an ORANGE subnet.

But I cannot seem to get OPENVPN to map a connection to the net I want (at least updating the Windoze routing on the client machines). If I put both the route commands into the openvpn server.conf
file then any logon can route to either lan. I guess I just don't understand the routing logic.

I suspect I am caught by some conflict between the IPTABLES of IPCOP and the OPENVPN expectations.

Re: Problem trying to route to different subnets

Posted: Wed Jan 29, 2014 8:16 pm
by hlightstone
After some lovely fun troubleshooting, I discovered the routing problem was a totally messed up Windoze configuration on the server which required complete rebuilding.

The routing seems correct now (I get the expected .82 subnet where I expected it).

The problem I still have is getting the user's routing table to "automatically" get the route for the local subnet. I cannot use route commands for the two subnets in the server because they are both then pushed to the client. I want the client to only have routing to the specific subnet.

I have two subnets behind IPcop : 192.168.50.x and 192.168.51.x
Some remote clients get only .50 and some get only .51 (and I of course need to get both:)

There must be some way to push an address to the client besides the the ones in the server configuration.

If I manually added the correct route, everything works OK but .... let me not try explaining about administrative privileges, command lines, and the like to each end user....