On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas <m...@mtcc.com> wrote:
> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote: > > On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <m...@mtcc.com <mailto: >> m...@mtcc.com>> wrote: >> >> No, sorry. Corporate VPN's using v6 and the lack of a coherent source >> address selection mechanism causes breakage in bizarre and unpredictable >> ways. You are not going to get the results you hope for if your mac uses an >> ISP prefix to get back inside the corpro firewall, uRPF if nothing else. >> SLAAC changes a lot of things over v4. >> >> >> VPN clients already modify the routing table to ensure traffic going >> through the VPN goes through the VPN, to enforce policies around split >> tunneling, and so on. Mine even monitors the routing table for changes so >> it can act on them. >> > > Routing is irrelevant. Sorry, but no. Routing is not irrelevant: Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. The choice of outgoing interface is a routing decision and thus the routing table can be used to influence source address selection. > Can you explain why this behaviour, combined with the "prefer matching >> interface" rule in RFC 3484, is not sufficient? If not, then there is no >> problem to solve here. >> > > Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you > 2000::, but also has 2001:yyyy::. You connect to a server on 2001:yyyy::. You missed the "your employer configures your routing table to point 2000::/64 and 2001:yyyy::/64 to the tunnel interface" step. Your employer has to configure your routing table today for IPv4 (either a default route or more-specific routes to private addresses for split tunneling). In IPv6 said employer needs to give you more specifics. > Your 3484 v6 stack picks 2001:xxxx for the source address. Nope. A routing lookup tells the kernel that the tunnel interface will be used to send to that destination, and the RFC3484 stack will pick 2000:: as the source address due to rule 5 above (note that you don't need to invoke 5.5 in RFC 6724 to make this work; RFC3484 is sufficient). > Hilarity ensues: 1) the packet gets rejected via uRPF > 2) the return packet splats against the inside firewall since it's not > allowed outside > 3) the packet makes it outside unarmored with sad faces from the security > team As James said, none of this happens. Now - if we want to make this in a routed network where the VPN tunnel is not terminated on the device itself, then RFC 3484/RFC6724 are not sufficient. But that problem not substantially different to the "multihomed with two ISPs problem", which we are trying to solve anyway. I believe this can be solved properly using source/destination routing.
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
