[OpenIndiana-discuss] multiple IP addresses, same NIC

[Robbie Crash]

On Wed, Mar 6, 2013 at 7:25 AM, Edward Ned Harvey (openindiana) <
openindiana at nedharvey.com> 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