On Wed, Jan 20, 2010 at 2:55 PM, Oliver Hansen <oliver.han...@gmail.com> wrote: > I have hub and spoke VPN network setup. 192.168.1.0/24 is the hub (central > office) and 192.168.x.0/24 are all the spokes (remote offices). These are > all connected with IPSEC VPN connections running a mix of linksys vpn > routers and pfSense 1.2.3-RC3. The problem I am having is related to two > pfSense boxes running 1.2.3-RC3 (I'll update to RELEASE if that's really the > problem but I'd rather wait a while). In most locations there is a single > subnet at the remote offices and that works fine. The remote offices are all > able to communicate to each other through the central office because on > their routers the IPSEC remote subnet is 192.168.0.0/16. > > Here is the problem: at one location we have both 192.168.2.0/24 on LAN and > 192.168.50.0/24 on OPT1. We have a VPN connection from the LAN to the hub > office and that worked fine but neither computers on the 192.168.2.0/24 or > the 192.168.1.0/24 could reach the 192.168.50.0/24 subnet. I determined that > the reason must be that any packets from the LAN must be getting sent over > the VPN tunnel before the router would check to see that it held that subnet > on one of it's own interfaces. > > Just last week, I set up a second VPN tunnel between the two routers. This > one has the destination subnet of 192.168.50.0/24 and now from the hub > router we can reach that subnet but from the 192.168.2.0/24 still cannot > reach it. My thinking was that the router with LAN and OPT1 would either > route between the two subnets and if not, it would send data up one VPN > connection because it was "interesting traffic" and then it would get sent > back down the 2nd tunnel to the other subnet. Neither of these things is > happening. >
That traffic is going out IPsec because IPsec always wins over anything in the system routing table including other directly attached networks (just how it works in the FreeBSD kernel). You either have to not include that other local subnet within your remote IPsec definition, or use OpenVPN which will work properly in that scenario. --------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
