On Wed, Mar 6, 2013 at 7:25 AM, Edward Ned Harvey (openindiana) < [email protected]> wrote:
> > > The problem is at the remote side. If they have a huge internal corporate > network that happens to include 192.168.10.x/24 and 192.168.1.x/24 ... When > I VPN to them and my LAN is 192.168.1.x/24, I have a subnet that overlaps > with their pre-existing subnet. They can't route traffic to me without > breaking one of their internal subnets. > I get that, but in your original email you stated you don't need to access their 192.168.1.0 subnet, unless all their traffic routes over that subnet internally you shouldn't have an issue. Their side will see the request coming from your VPN point, and will send traffic there and your VPN server will send it to the proper client. What IP address are you receiving from the VPN server? Is it a 192.168.1.0 address? If it is,you're going to have more problems than it's worth and you should reIP your home network. > The most elegant solution (aside from renumbering my network) would be > NAT. It would be nice to eliminate 192.168.2.x/24 from my house, and > configure the firewall so when I send a packet to the VPN network, let my > source IP be NAT'd to 192.168.2.x/24. However, I have not yet had any luck > configuring pfsense to NAT the traffic first and then route it, NAT'd > across the VPN. > > At present, I have two problems I'm trying to solve in parallel. If I can > either make OI behave as expected, then I can use the > multiple-subnets-on-a-single-LAN solution and move forward. Or if I can > get the firewall to NAT as expected, then I can scrap the multiple-subnets > idea and move forward. > > > > The issue here sounds like since the OI box already knows that it has a > > route to 192.168.10.10 over its default route, it doesn't need to use the > > secondary IP. > > That's not quite correct. Sure, if I didn't add the static route > 192.168.10.x via 192.168.2.1, then OI would try to reach 192.168.10.x via > the default gateway. But that's irrelevant - By adding the 192.168.2.1 > route, the system does in fact know it's supposed to reach 192.168.10.x via > 192.168.2.1. The evidence is when a packet leaves the NIC destined for > 192.168.10.x, its destination MAC corresponds to 192.168.2.1. But > unfortunately, the source IP is wrong. > > Except what you're saying is that it's being sent via the default IP address (192.168.1.X) to 192.168.2.1, which is fine your router knows where that is, so it can get there. But that means that OI is using your primary IP address, not the secondary one. > > If you can't configure the router, PCI NICs are $9 these days, and > that'll > > work for sure. > > I might do that. The main obstacle is knowing I would have to wait for it > to arrive, and it will require downtime on the VM host, to solve something > that should be solvable in software. This is something that should be handled at the router, not at the client in software. I get that this can be handled in software, but it shouldn't be. It's not a client's job to route traffic to appropriate destinations. Static routing and multiple subnets on the clients are not the proper way to handle situations like this if any other option is available. Since it sounds like you're dialing the VPN from your router, the proper fix to this is to reIP your internal network to something other than one of the private nets you're trying to reach, and then add a route on the router to handle traffic to .1. and .10. and be done with it. -- Seconds to the drop, but it seems like hours. http://www.openmedia.ca https://robbiecrash.me _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
