|
|
On Fri, 6 Aug 2004, Michael Kelly wrote:
> I have one VPN system running as follows:
(jimc made diagram horizontal...)
> Office OpenVPN INTERNET OpenVPN Remote
> 192.168.0.0/24 10.1.0.1 10.1.0.2 192.168.4.0/24
>
> Routing for Office to remote:
> route add -net 192.168.4.0 netmask 255.255.255.0 gw $5 (10.1.0.2, right?)
>
> Routing for Remote to Office:
> route add -net 192.168.0.0 netmask 255.255.255.0 gw $5 (10.1.0.1?)
>
> And another:
> Office OpenVPN INTERNET OpenVPN Road-warrior
> 192.168.0.0/24 10.3.0.1 10.3.0.2 a.b.c.d (variable)
>
> Routing for Road Warrior to Office
> route 192.168.0.0 255.255.255.0 10.3.0.1
>
> Routing for Office to Road warrior is automatic via Office openVPN
> gateway
>
> ...is the routing between the Remote location and the Road Warrior.
> ...I have tried adding a route on the Road warrior side to forward all
> traffic for 192.168.4.0/24 to the 10.3.0.1 VPN gateway, but that got me
> nowhere fast.
The Road Warrior sends packets, whose source field says 10.3.0.2, to a
Remote host, and it wants to send a packet back. Does it have a route so
it knows where the reply should go? For example, using UNIX syntax:
route add -host 10.3.0.2 gw 10.1.0.1 (on the VPN terminus at Remote)
route add -host 10.3.0.2 gw 192.168.4.254 (on the Remote clients)
I'm imagining that 192.168.4.254 is the VPN terminus at Remote.
People usually handle this situation by putting the VPN terminus at
Remote on a choke point router which is the default route of all the
Remote clients, so the reply to 10.3.0.1 will automatically land there (not
needing the special route command above), and then the router has the route
through 10.1.0.1 for both 192.168.0.0/24 (Office) and 10.3.0.2 (Road
Warrior). Presumably if there are several road warriors you will use
OpenVPN 2.0beta$N, you will assign a small subnet for their use, and where
the above route commands say -host 10.3.0.2 that would be replaced by the
subnet.
At UCLA-Mathnet we have four discontiguous subnets, with public IP
addresses (not 192.168.0.0/16), and the choke point router is a Cisco box
which OpenVPN can't run on. I bypass the routing issue entirely by using
NAT on my VPN machine, so partners think the packets originated from it and
the replies should go back to it, which is the desired behavior. In
addition, we have purchased services (online journals) that are protected
by hostbased authentication. When a prof at home directs his default route
down the tunnel, the service provider thinks he's at work and delivers the
content. (This is legal since the service is purchased for a set of users,
not a set of IP addresses, and we only give certificates to our authorized
users.)
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc@xxxxxxxxxxxxx http://www.math.ucla.edu/~jimc (q.v. for PGP key)
____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users
|