[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

[Openvpn-users] Re: [Openvpn-devel] hub and spoke topology checklist.txt


  • Subject: [Openvpn-users] Re: [Openvpn-devel] hub and spoke topology checklist.txt
  • From: "James Yonan" <jim@xxxxxxxxx>
  • Date: Tue, 17 Sep 2002 07:58:04 -0000

I have successfully used hub and spoke topology with OpenVPN + tun devices + linux in the past.

First, make sure that the hub has a firewall rule to route between the virtual tun subnets.

Next, reduce the failure to its least common denominator.  Can you make it fail with just a single peer-to-peer topology, or does it only fail in the hub and spoke context?

You say that TCP over the tunnel fails, but do pings also fail (small pings or large pings)?

See the FAQ for some steps on troubleshooting whether the problem is happening inside OpenVPN or the tun device or whether it relates to packets being dropped because of incorrectly configured firewall rules.

Other gotchas are MTU size, NAT timeouts and NAT-caused port reassignments.  A good test for MTU issues is that small pings go through, but large ones (that would trigger fragmentation) don't.  NAT timeout issues can often be solved by --ping n where n is between 5 and 30.

Also, might I suggest we move this thread to openvpn-users, where discussions about configuration issues belong?

James Yonan

R P Herrold <herrold@xxxxxxxxxxxx> said:

> 
> I was working through the openvpn material, and had been 
> testing with the following design checklist (see bottom)
> 
> The thought is to provide a hub and spoke design for isolated
> non-routable subnets at the end of the spokes, behind
> otherwise properly routed outbound-only NATting (which allow 
> return packets ...), where there is available a central
> routable IP hub available (to allow static custom routing 
> between those subnets).
> 
> I can ping, and indeed set up an SSH session, out to the hub,
> which indicates that encapsulation of TCP within the OpenVPN
> client is occurring -- I leave encryption off, as I am in
> process diagnosing where things are falling apart --
> 
> -- after a couple minutes, it locks up tight, and I have 
> to go kill the remote Hub routing, out of band.
> 
> As such, I have not gotten the second subnet set up yet.
> 
> The tracing shows packets for a while, but then the consoles 
> lock (in which the tracing is occurring), and I cannot 
> ctrl-C to regain control.  Network connectivity remains active 
> -- I can work out of band on the Hub, the enar spoke terminus 
> is local ...
> 
> Any thoughts on a theoretical reason this should not work?
> 
> -- Russ Herrold
> 
> =============================================================
> 
> Hub and Spoke Topology:
> 
> HUB x.y.z.a is a static IP, in routable space -- all other
> devices are masqueraded, and not reachible from the outside,
> 
> The VPN gateway will encapsulate VPN network destination traffic into the
> TUN interface, and pass the rest along to the next hop exterior NAT device
> 
> Subnets:
> 
>                          |
>            10.1.1.1      |
> client --- gateway ---- NAT ------ internet ----- HUB
> 10.1.1.2      |       10.1.1.254    0.0.0.0     x.y.z.a
>               \          |
>                \--- 192.168.1.2 ----------- 192.168.1.1
>                          |         P-t-P
>      10.1.1.x segment    |
>                         /
> -----------------------/
> 
> 
> 
>                          |
>           10.10.10.1     |
> client --- gateway ---- NAT ------ internet ----- HUB
> 10.10.10.2    |      10.10.10.254   0.0.0.0     x.y.z.a
>               \          |
>                \--- 192.168.10.2 ----------- 192.168.10.1
>                          |          P-t-P
>      10.10.10.x segment  |
>                         /
> -----------------------/
> 
> 
> Routing:
> 
> on VPN gateway-10.1.1.1
> 
> ( next hop: route add default gateway 10.1.1.254 )
> route add -host 192.168.1.1 gateway 192.168.1.2
> route add -net 10.0.0.0 gateway 192.168.1.1
> 
> 
> on VPN gateway-10.10.10.1
> 
> ( next hop: route add default gateway 10.10.10.254 )
> route add -host 192.168.10.1 gateway 192.168.10.2
> route add -net 10.0.0.0 gateway 192.168.10.1
> 
> 
> on HUB -- simple reciprocal routing for each VPN'd subnet
> 
> route add -host 192.168.1.2 gateway 192.168.1.1
> route add -net 10.1.1.0 gateway 192.168.1.2
> route add -host 192.168.10.2 gateway 192.168.10.1
> route add -net 10.10.10.0 gateway 192.168.10.2
> 
> 
> Local gateway behind NAT
> 
> 	modprobe tun
> 	echo 1 > /proc/sys/net/ipv4/ip_forward   
> 	openvpn --remote x.y.z.a --dev tun --port 5001 \
> 		--ifconfig 192.168.1.2 192.168.1.1 --verb 8
> 
> Local gateway behind NAT
> 
> 	modprobe tun
> 	echo 1 > /proc/sys/net/ipv4/ip_forward   
> 	openvpn --remote x.y.z.a --dev tun --port 5010 \
> 		--ifconfig 192.168.10.2 192.168.10.1 --verb 8
> 
> Central HUB (== x.y.z.a )
> 
> 	modprobe tun
> 	echo 1 > /proc/sys/net/ipv4/ip_forward
> 	openvpn --dev tun --port 5001 \
> 		--ifconfig 192.168.1.1 192.168.1.2 --verb 8
> 	openvpn --dev tun --port 5010 \
> 		--ifconfig 192.168.10.1 192.168.10.2 --verb 8
> 
> ===================================
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Openvpn-devel mailing list
> Openvpn-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 



-- 





-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab
_______________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users