Op 23 okt. 2012, om 17:20 heeft Michael Thomas het volgende geschreven: > 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. > >> >> 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::. Your > 3484 v6 stack picks 2001:xxxx for the source address. 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
Employer should also provide 2001:yyyy::. Or make server accessible via Internet. BRDP will handle this scenario nicely, also for existing hosts. Teco > > Mike > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
