Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-11 Thread Jim Pingle
On 12/10/2014 07:34 AM, Chris Bagnall wrote: > On 10/12/14 6:36 am, Chris L wrote: >> That’s actually your fault for using 10/8, not Comcast's. >> Even if they were to use something like 10.58.223.0/24 they’d still >> conflict with your 10/8. > > There are so many different brands and models of co

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Jim Thompson
> On Dec 10, 2014, at 1:16 PM, Chris Bagnall wrote: > >> On 10/12/14 3:30 pm, Giles Coochey wrote: >> http://tools.ietf.org/html/rfc6598 >> Ultimately, it's a crap shoot, and the solution is to use IPV6 and 6:4 >> NAT for legacy. > > If only someone could have forseen that IPv4 would run out s

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Lyle Giese
AT&T/SBC used 2wire brand DSL routers and there was a version of FW in them that used 172.16/12 for the LAN. I used to see that model frequently just before they started pushing Uverse instead. Lyle Giese LCR Computer Services, Inc. On 12/10/14 06:34, Chris Bagnall wrote: On 10/12/14 6:36 am

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Lyle Giese
Chris, Maybe Karl needs to read RFC 1918. It can be enlightening to find out he does not 'own' 10.0.0.0/8 Yes, VPN's require unique subnets on both sides of the VPN server, but that is the price you pay for using a VPN with RFC 1918 addresses. Lyle Giese LCR Computer Services, Inc. On 12/

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Chris Bagnall
On 10/12/14 3:30 pm, Giles Coochey wrote: http://tools.ietf.org/html/rfc6598 Unfortunately, there are people who stick their networks (erroneously) on 100.64/10 as well - including at least one government department in the UK - who shall remain nameless for the avoidance of ridicule :-) I s

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Giles Coochey
On 10/12/2014 06:36, Chris L wrote: On Dec 9, 2014, at 8:53 PM, Karl Fife wrote: In the wild, I'm seeing a an increasing number of crappy consumer/ISP routers with subnets that conflict with ours (10../8). Comcast appears to be a common offender, curiously allocating the largest private subne

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Karl Fife
I agree with you Chris. That's an excellent choice for someone building out a new network assuming you don't peer with other networks/systems in that space. Ultimately, it's a crap shoot, and the solution is to use IPV6 and 6:4 NAT for legacy. Still, if there were a way to easily invoke clie

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Karl Fife
Chris L, can you clarify your point? Every RFC1918 subnet carries with it a risk of subnet conflict. Some subnets carry more risk than others. In our case, 192/168/n would result in higher probability of conflict because most small networks use that space. I might 'fault' Comcast because they

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-10 Thread Chris Bagnall
On 10/12/14 6:36 am, Chris L wrote: That’s actually your fault for using 10/8, not Comcast's. Even if they were to use something like 10.58.223.0/24 they’d still conflict with your 10/8. There are so many different brands and models of consumer router on the market these days in the 10/8 and

Re: [pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-09 Thread Chris L
On Dec 9, 2014, at 8:53 PM, Karl Fife wrote: > In the wild, I'm seeing a an increasing number of crappy consumer/ISP > routers with subnets that conflict with ours (10../8). Comcast appears > to be a common offender, curiously allocating the largest private subnet > to their smallest customers.

[pfSense] Client-Side 1:1 NAT for IP address conflicts w/ VPN

2014-12-09 Thread Karl Fife
In the wild, I'm seeing a an increasing number of crappy consumer/ISP routers with subnets that conflict with ours (10../8). Comcast appears to be a common offender, curiously allocating the largest private subnet to their smallest customers. Of course this breaks VPN due to address ambiguity/con