Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Morgan Reed
Yeah, I trudged all the way through it a while back. You're right, the time
would've been better spent actually fixing the bug than arguing about it.

I'm pretty sure there's even been a few attempted pull requests to fix it
but they've all been rejected.

On Thu, Aug 3, 2017 at 3:28 PM, Matthew Hall  wrote:

> This bug report is absolutely insane. It required more hours for people to
> compose these replies than it would to compose the patch for the actual
> bug. I couldn't even read it all because it was so violently toxic.
>
> Matthew Hall
>
> > On Aug 2, 2017, at 9:36 PM, Morgan Reed  wrote:
> >
> > It's not "google" refusing to support it... It's one Lorenzo Colitti who
> is
> > the roadblock...
> > https://issuetracker.google.com/issues/36949085
> > But yes, it's asinine.
>
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>



-- 
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, 1759
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] Netgate SG-2220 and Leviton power supply

2017-08-02 Thread Moshe Katz
The page you linked to says that the SG-2220 needs 5A, but you say the
Leviton power supply is 4A. That's probably a bad idea. In fact, according
to the spec sheet though, the Leviton power supply is actually only
3.3A. That's almost definitely a bad idea.

--
Moshe Katz
-- mo...@ymkatz.net
-- +1(301)867-3732

On Thu, Aug 3, 2017 at 2:23 AM, Shivaram Mysore 
wrote:

> Hello,
> I have a Leviton Power supply (12v, ~4 Amps) [1] and trying to use it with
> SG-2220 running pfSense.  Will the ampere rating be enough.  I could not
> get a good read on the same based on the spec sheets for SG-2220.  But,
> wanted to confirm.
>
> [1] http://www.leviton.com/en/products/47605-psc
> [2] https://www.netgate.com/products/sg-2220.html
>
> Thanks & Regards
>
> /Shivaram
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


[pfSense] Netgate SG-2220 and Leviton power supply

2017-08-02 Thread Shivaram Mysore
Hello,
I have a Leviton Power supply (12v, ~4 Amps) [1] and trying to use it with
SG-2220 running pfSense.  Will the ampere rating be enough.  I could not
get a good read on the same based on the spec sheets for SG-2220.  But,
wanted to confirm.

[1] http://www.leviton.com/en/products/47605-psc
[2] https://www.netgate.com/products/sg-2220.html

Thanks & Regards

/Shivaram
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Matthew Hall
This bug report is absolutely insane. It required more hours for people to 
compose these replies than it would to compose the patch for the actual bug. I 
couldn't even read it all because it was so violently toxic. 

Matthew Hall

> On Aug 2, 2017, at 9:36 PM, Morgan Reed  wrote:
> 
> It's not "google" refusing to support it... It's one Lorenzo Colitti who is
> the roadblock...
> https://issuetracker.google.com/issues/36949085
> But yes, it's asinine.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Morgan Reed
It's not "google" refusing to support it... It's one Lorenzo Colitti who is
the roadblock...
https://issuetracker.google.com/issues/36949085
But yes, it's asinine.


On Thu, Aug 3, 2017 at 1:00 PM, Adam Thompson  wrote:

> You could be right, I was writing from memory and ... tbh, I don't care
> enough to go look it up again :).  They shut down, that's a pain in the
> butt, I was already on HE anyway, end of story for me.
> I would do the same here, except that (IMHO) Google's refusal to support
> DHCPv6 on Android is completely asinine.  So my phone still doesn't get an
> IPv6 address here at home :-(.
> (Note: Apple products work perfectly.)
>
> It's interesting to speculate about what will happen at some future date
> when HE turns off (or starts charging for) their tunnel service...  I
> haven't heard anything credible yet, but I assume it'll happen someday.
>
> -Adam
>
> > -Original Message-
> > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Moshe
> > Katz
> > Sent: August 2, 2017 21:38
> > To: pfSense Support and Discussion Mailing List 
> > Subject: Re: [pfSense] IPv6 1:1 NAT problems
> >
> > Adam,
> >
> > Actually, the reason SIXXS shut down is exactly the opposite of what you
> > said. SIXXS shut down because IPv6 adoption was going too slow and a
> > number of ISPs were actually telling their customers "we don't plan to
> > implement
> > IPv6 because you can get it from SIXXS if you really want it." In effect,
> > ISPs were using tunnels as a way of *reducing *IPv6 rollouts.
> >
> > Vick,
> >
> > I also have an HE tunnel at home because my ISP is dragging their feet
> > about implementing IPv6. In fact, my main guest WiFi network runs
> > *only* IPv6.
> > Most of my guests only care about Gmail and YouTube, and those have
> > been
> > IPv6 enabled for ages. It's an experiment to see how many visitors can
> > get away with not noticing that they have no IPv4 connectivity.
> >
> > Moshe
> >
> > --
> > Moshe Katz
> > -- mo...@ymkatz.net
> > -- +1(301)867-3732 <(301)%20867-3732>
> >
> > On Wed, Aug 2, 2017 at 10:32 PM, Adam Thompson
> > 
> > wrote:
> >
> > > So?  Neither do I.  I don't have native IPv6 at the office either.
> > > But both are fully IPv6-connected.
> > > That's what Hurricane Electric tunnels are for.  (And SIXXS, formerly,
> > > but they've decided that IPv6 penetration has reached a point where
> > > they're not needed anymore.  Hahahaha...)
> > >
> > > http://www.tunnelbroker.net/
> > >
> > > Disclaimer: my home situation is a bit of an anomaly - the nearest HE
> > > IPv6 tunnel endpoint is <5msec away from my home router [wireless,
> > not
> > > DSL or cable], and my ISP has a 10Gbps connection to them.
> > > Performance is VERY satisfactory.  However, even my office, where the
> > > nearest HE tunnel endpoint is 30+msec away gets perfectly acceptable
> > performance on IPv6.
> > > Largely because IPv6 paths tend to be shorter and transit fewer
> > routers.
> > > (There are a number of factors at play; sometimes IPv6 is tunneled
> > > over IPv4, which means the path isn't *really* shorter.)
> > >
> > > -Adam
> > >
> > > > -Original Message-
> > > > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Vick
> > > > Khera
> > > > Sent: August 2, 2017 21:28
> > > > To: pfSense Support and Discussion Mailing List
> > > > 
> > > > Subject: Re: [pfSense] IPv6 1:1 NAT problems
> > > >
> > > > Nice. Thanks for the explanation. My IPv6 knowledge is slowly being
> > > > built up. Not having IPv6 at my home router makes it hard to play
> > > > with. I've not had the courage to bring "live" my direct allocation
> > > > at the data
> > > center
> > > > yet.
> > >
> > >
> > > ___
> > > pfSense mailing list
> > > https://lists.pfsense.org/mailman/listinfo/list
> > > Support the project with Gold! https://pfsense.org/gold
> > >
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
>
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>



-- 
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, 1759
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Matthew Hall
If you put your network segment into Assisted Mode the clients will try SLAAC 
followed by DHCPv6 so that things can cooperate between both approaches. 

Matthew Hall

> On Aug 2, 2017, at 8:00 PM, Adam Thompson  wrote:
> 
> You could be right, I was writing from memory and ... tbh, I don't care 
> enough to go look it up again :).  They shut down, that's a pain in the butt, 
> I was already on HE anyway, end of story for me.
> I would do the same here, except that (IMHO) Google's refusal to support 
> DHCPv6 on Android is completely asinine.  So my phone still doesn't get an 
> IPv6 address here at home :-(.
> (Note: Apple products work perfectly.)
> 
> It's interesting to speculate about what will happen at some future date when 
> HE turns off (or starts charging for) their tunnel service...  I haven't 
> heard anything credible yet, but I assume it'll happen someday.
> 
> -Adam

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Adam Thompson
You could be right, I was writing from memory and ... tbh, I don't care enough 
to go look it up again :).  They shut down, that's a pain in the butt, I was 
already on HE anyway, end of story for me.
I would do the same here, except that (IMHO) Google's refusal to support DHCPv6 
on Android is completely asinine.  So my phone still doesn't get an IPv6 
address here at home :-(.
(Note: Apple products work perfectly.)

It's interesting to speculate about what will happen at some future date when 
HE turns off (or starts charging for) their tunnel service...  I haven't heard 
anything credible yet, but I assume it'll happen someday.

-Adam

> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Moshe
> Katz
> Sent: August 2, 2017 21:38
> To: pfSense Support and Discussion Mailing List 
> Subject: Re: [pfSense] IPv6 1:1 NAT problems
> 
> Adam,
> 
> Actually, the reason SIXXS shut down is exactly the opposite of what you
> said. SIXXS shut down because IPv6 adoption was going too slow and a
> number of ISPs were actually telling their customers "we don't plan to
> implement
> IPv6 because you can get it from SIXXS if you really want it." In effect,
> ISPs were using tunnels as a way of *reducing *IPv6 rollouts.
> 
> Vick,
> 
> I also have an HE tunnel at home because my ISP is dragging their feet
> about implementing IPv6. In fact, my main guest WiFi network runs
> *only* IPv6.
> Most of my guests only care about Gmail and YouTube, and those have
> been
> IPv6 enabled for ages. It's an experiment to see how many visitors can
> get away with not noticing that they have no IPv4 connectivity.
> 
> Moshe
> 
> --
> Moshe Katz
> -- mo...@ymkatz.net
> -- +1(301)867-3732 <(301)%20867-3732>
> 
> On Wed, Aug 2, 2017 at 10:32 PM, Adam Thompson
> 
> wrote:
> 
> > So?  Neither do I.  I don't have native IPv6 at the office either.
> > But both are fully IPv6-connected.
> > That's what Hurricane Electric tunnels are for.  (And SIXXS, formerly,
> > but they've decided that IPv6 penetration has reached a point where
> > they're not needed anymore.  Hahahaha...)
> >
> > http://www.tunnelbroker.net/
> >
> > Disclaimer: my home situation is a bit of an anomaly - the nearest HE
> > IPv6 tunnel endpoint is <5msec away from my home router [wireless,
> not
> > DSL or cable], and my ISP has a 10Gbps connection to them.
> > Performance is VERY satisfactory.  However, even my office, where the
> > nearest HE tunnel endpoint is 30+msec away gets perfectly acceptable
> performance on IPv6.
> > Largely because IPv6 paths tend to be shorter and transit fewer
> routers.
> > (There are a number of factors at play; sometimes IPv6 is tunneled
> > over IPv4, which means the path isn't *really* shorter.)
> >
> > -Adam
> >
> > > -Original Message-
> > > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Vick
> > > Khera
> > > Sent: August 2, 2017 21:28
> > > To: pfSense Support and Discussion Mailing List
> > > 
> > > Subject: Re: [pfSense] IPv6 1:1 NAT problems
> > >
> > > Nice. Thanks for the explanation. My IPv6 knowledge is slowly being
> > > built up. Not having IPv6 at my home router makes it hard to play
> > > with. I've not had the courage to bring "live" my direct allocation
> > > at the data
> > center
> > > yet.
> >
> >
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
> >
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Moshe Katz
Adam,

Actually, the reason SIXXS shut down is exactly the opposite of what you
said. SIXXS shut down because IPv6 adoption was going too slow and a number
of ISPs were actually telling their customers "we don't plan to implement
IPv6 because you can get it from SIXXS if you really want it." In effect,
ISPs were using tunnels as a way of *reducing *IPv6 rollouts.

Vick,

I also have an HE tunnel at home because my ISP is dragging their feet
about implementing IPv6. In fact, my main guest WiFi network runs *only* IPv6.
Most of my guests only care about Gmail and YouTube, and those have been
IPv6 enabled for ages. It's an experiment to see how many visitors can get
away with not noticing that they have no IPv4 connectivity.

Moshe

--
Moshe Katz
-- mo...@ymkatz.net
-- +1(301)867-3732 <(301)%20867-3732>

On Wed, Aug 2, 2017 at 10:32 PM, Adam Thompson 
wrote:

> So?  Neither do I.  I don't have native IPv6 at the office either.  But
> both are fully IPv6-connected.
> That's what Hurricane Electric tunnels are for.  (And SIXXS, formerly, but
> they've decided that IPv6 penetration has reached a point where they're not
> needed anymore.  Hahahaha...)
>
> http://www.tunnelbroker.net/
>
> Disclaimer: my home situation is a bit of an anomaly - the nearest HE IPv6
> tunnel endpoint is <5msec away from my home router [wireless, not DSL or
> cable], and my ISP has a 10Gbps connection to them.  Performance is VERY
> satisfactory.  However, even my office, where the nearest HE tunnel
> endpoint is 30+msec away gets perfectly acceptable performance on IPv6.
> Largely because IPv6 paths tend to be shorter and transit fewer routers.
> (There are a number of factors at play; sometimes IPv6 is tunneled over
> IPv4, which means the path isn't *really* shorter.)
>
> -Adam
>
> > -Original Message-
> > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Vick
> > Khera
> > Sent: August 2, 2017 21:28
> > To: pfSense Support and Discussion Mailing List 
> > Subject: Re: [pfSense] IPv6 1:1 NAT problems
> >
> > Nice. Thanks for the explanation. My IPv6 knowledge is slowly being built
> > up. Not having IPv6 at my home router makes it hard to play with. I've
> > not had the courage to bring "live" my direct allocation at the data
> center
> > yet.
>
>
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Adam Thompson
So?  Neither do I.  I don't have native IPv6 at the office either.  But both 
are fully IPv6-connected.
That's what Hurricane Electric tunnels are for.  (And SIXXS, formerly, but 
they've decided that IPv6 penetration has reached a point where they're not 
needed anymore.  Hahahaha...)

http://www.tunnelbroker.net/

Disclaimer: my home situation is a bit of an anomaly - the nearest HE IPv6 
tunnel endpoint is <5msec away from my home router [wireless, not DSL or 
cable], and my ISP has a 10Gbps connection to them.  Performance is VERY 
satisfactory.  However, even my office, where the nearest HE tunnel endpoint is 
30+msec away gets perfectly acceptable performance on IPv6.  Largely because 
IPv6 paths tend to be shorter and transit fewer routers.  (There are a number 
of factors at play; sometimes IPv6 is tunneled over IPv4, which means the path 
isn't *really* shorter.)

-Adam

> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Vick
> Khera
> Sent: August 2, 2017 21:28
> To: pfSense Support and Discussion Mailing List 
> Subject: Re: [pfSense] IPv6 1:1 NAT problems
> 
> Nice. Thanks for the explanation. My IPv6 knowledge is slowly being built
> up. Not having IPv6 at my home router makes it hard to play with. I've
> not had the courage to bring "live" my direct allocation at the data center
> yet.


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Vick Khera
Nice. Thanks for the explanation. My IPv6 knowledge is slowly being built
up. Not having IPv6 at my home router makes it hard to play with. I've not
had the courage to bring "live" my direct allocation at the data center yet.

On Wed, Aug 2, 2017 at 10:22 PM, Adam Thompson 
wrote:

> Sadly, yes.  Partly due to providers like OVH who don't "get" prefix
> delegation.
> Also, how else do you multi-home without running BGP?  (Keeping in mind
> that the overwhelming majority of networks around the world have no access
> to BGP.)  That's one of the specific use cases for Network Prefix
> Translation.  (I don't have the RFC handy, sorry.)
> -Adam
>
> > -Original Message-
> > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Vick
> > Khera
> > Sent: August 2, 2017 21:20
> > To: pfSense Support and Discussion Mailing List 
> > Subject: Re: [pfSense] IPv6 1:1 NAT problems
> >
> > Is NAT even a thing with IPv6?
> > ___
> > pfSense mailing list
> > https://lists.pfsense.org/mailman/listinfo/list
> > Support the project with Gold! https://pfsense.org/gold
>
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
>
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Adam Thompson
Sadly, yes.  Partly due to providers like OVH who don't "get" prefix delegation.
Also, how else do you multi-home without running BGP?  (Keeping in mind that 
the overwhelming majority of networks around the world have no access to BGP.)  
That's one of the specific use cases for Network Prefix Translation.  (I don't 
have the RFC handy, sorry.)
-Adam

> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Vick
> Khera
> Sent: August 2, 2017 21:20
> To: pfSense Support and Discussion Mailing List 
> Subject: Re: [pfSense] IPv6 1:1 NAT problems
> 
> Is NAT even a thing with IPv6?
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Matthew Hall
https://tools.ietf.org/html/rfc6296

Matthew Hall

> On Aug 2, 2017, at 7:19 PM, Vick Khera  wrote:
> 
> Is NAT even a thing with IPv6?
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Vick Khera
Is NAT even a thing with IPv6?
___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


[pfSense] IPv6 1:1 NAT problems

2017-08-02 Thread Adam Thompson
(If you work for Netgate – would a paid support subscription include helping me 
diagnose the problem here, and get this working?  I’m not 100% clear if this is 
in scope or not.)

 

I’ve encountered an – apparently – unusual problem when trying to enable 1:1 
NAT for IPv6.

I’m also having a similar problem with NPt, actually, and since they both seem 
to use the same pf(4) “binat” directive, I suspect they might be related.

 

All IPs here are obfuscated because the list gets archived, but the last two 
octets/hextets[1] and subnet masks are all coped as-is.  I’ll be happy to 
provide actual IP addresses in private emails, if you think that’s where my 
problem lies.

 

Scenario:

*   OVH private cloud (so same non-delegated, NDP-only IPv6 address space 
I’ve mentioned previously)
*   pfSense VM was deployed from official OVA file
*   OVH has allocated 1:2:3:4::/56, 1.2.3.48/28 and a few more IPv4 
subnets, all bound to the same router interface on their end, connected to the 
WAN VLAN on the pfSense VM.  The IPv6 allocation is *NOT* delegated, it’s a 
simple interface binding on their router.
*   pfSense WAN address is 1.2.3.49/28 and 1:2:3:4::49/56.  Default 
gateways are 1.2.3.62 and 1:2:3:4:::::.
*   pfSense LAN address is 10.1.1.1/24 and fd60::1/64.  It is the default 
gateway.
*   One other VM exists on the “LAN” V(X)LAN[2], providing public services 
over tcp/80, tcp/443 and tcp/22.
*   Firewall rules are trivial for debugging purposes: Allow Any/Any/Any on 
WAN and Allow Any/Any/Any on LAN.
*   IPv4 Proxy ARP VIP exists for 1.2.3.50/28
*   1:1 NAT for 1.2.3.50/32 <- -> 10.1.1.2/32 exists, seems to work fine.

 

Notes:

*   I have multiple tenants within my OVH private cloud.
*   I want them all on separate VLANs, both to slightly increase security 
(no sniffing/snooping/spoofing attacks) and also to simplify IPSec tunnel setup.
*   I can’t use NPt because OVH isn’t delegating or routing that /56 to me. 
 (If they would just &^%$#@! *route* the blocks to me, I’d be done a month ago…)
*   I’m “allocating” /64s out of that /56 for each customer purely 
administratively, i.e. on paper

 

What’s happening (that I think is a bug)

*   pfSense itself has IPv6 connectivity at this point, yay.
*   I create a VIP for 1:2:3:4::50/56.
*   If and only if the VIP type is “IP Alias”, then:

*   Other VMs on the same WAN segment can ping :50.
*   External nodes cannot ping :50, until I force a “gratuitous NDP” (that 
shouldn’t even be a thing…) by pinging the default gw with the source address 
set to :50.  There might be a timer involved and I’m too impatient? Dunno, 
anyway this gets global traffic routing working.

*   The moment I create a 1:1 NAT entry for 1:2:3:4::50/128 <- -> 
fd60::2/128, all IPv6 on the WAN stops working.  pfSense no longer replies to 
Neighbour Solicitations packets from the gateway, which… well… breaks IPv6 
pretty thoroughly.  I can still see the incoming NDP packets using tcpdump, but 
no responses.

 

But:

*   If I do this with “Proxy ARP” VIP instead of “IP Alias” VIP, I can 
never ping :50, but creating the 1:1 NAT entry still breaks IPv6 on the WAN 
interface.
*   If I set the WAN interface address to something elsewhere in the range 
(e.g. 1:2:3:5::1/56) and then set up NPt between, say, 1:2:3:4:0/64 (WAN) and 
fd60::/64 (LAN), IPv6 from pfSense itself does not break, but pfSense also does 
not respond to Neighbour Solicitations for IPs in that range, so I don’t have 
functional IPv6 to or from the LAN.  This is a documented limitation, and it’s 
not supposed to work.

 

So I’m lost.  Why on earth would *creating* a 1:1 NAT entry for a pair of /128s 
break IPv6 (NDP, anyway) for the firewall itself?  Why does creating the 
equivalent NPt mapping *not* break the firewall? 

 

While I’m pissed at OVH for refusing to delegate or route the /56, it seems 
this should still be *possible*, even if awkward, to deploy.  But my IPv6 
breakage seems very weird – but what on earth could I be doing SO differently 
that it breaks for me but no-one else?

 

Thanks,

-Adam

 

 

[1] https://en.wikipedia.org/wiki/Hextet - you got a better word? Let me know!

[2] From pfSense’s perspective, it’s just another segment.  Internally, OVH 
uses VMware NSX VXLANs to emulate VLANs to emulate broadcast domains.  As far 
as I can tell, this “just works”.  It doesn’t seem to be part of the problem, 
anyway.

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPv6 problem at OVH

2017-08-02 Thread Olivier Mascia
> Le 2 août 2017 à 14:46, Adam Thompson  a écrit :
> 
> I can't speak to their other platforms, but the Private Cloud offering is 
> based on VMware, and does not permit the use of MAC addresses other than the 
> one assigned to the VM.  So CARP immediately fails there.
> Amusingly (not), there's even special plug-in in the VMware client that is 
> supposed to let me enable "OVH CARP" (it appears its function is to toggle 
> the VMware distributed vSwitch setting allowing "forged" MAC addresses and 
> promiscuous mode) but it doesn't actually work as it relies on the cluster 
> being connected to a Cisco Nexus 1000v vSwitch, which OVH appears to have 
> deprecated and removed.
> So, in any case, anything that requires MAC address changes won't work.
> -Adam


Happily I still have a PCC with Nexus 1000v and my CARP works perfectly for my 
IPv4 setup.  It just is that it never worked with IPv6. Buggy 1000v regarding 
VRRP and IPv6, it seems.

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia, http://integral.software



___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPv6 problem at OVH

2017-08-02 Thread Olivier Mascia
> Le 2 août 2017 à 14:50, Adam Thompson  a écrit :
> 
> Before I dive into details, can anyone confirm that they have 1:1 NAT working 
> for IPv6 in production?


I have Adam.

Configure your WAN using the first /57 from the /56 they give you.
For instance: :::yy00::1/56 for WAN with 
::::yy00:::: as gateway.

Now use /64 slices of the second /57 slice for your multiple LANs interfaces.
For instance:
...yy81::1/64 for LAN1
...yy82::1/64 for LAN2 and so on.
...

Then setup NPt as such:
On WAN: external :::yy01::/64 internal :::yy81::/64
On WAN: external :::yy01::/64 internal :::yy81::/64
...

Finally for each single IP to expose to the world, add an IP Alias on WAN as 
such:

:::yy01::1234/57

The /57 is important in this matter, to get it right.

Your :::yy81::1234 IP (in the :::yy81::/64 subnet) used 
internally will properly be reachable (and appear on outgoing connections) as 
:::yy01::1234.

-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia, http://integral.software


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPv6 problem at OVH

2017-08-02 Thread Adam Thompson
I've got IPv4 working, as I said, using the Proxy ARP (or IP Alias, both work) 
VIP.
I still don't have IPv6 working, though.

I'm running into a situation where 1:1 NAT for IPv6 seems to either a) simply 
not work at all, or b) utterly kills all IPv6 on the firewall for reasons I 
don't understand yet.

Before I dive into details, can anyone confirm that they have 1:1 NAT working 
for IPv6 in production?

(Eh, I'll start a new thread anyway.)

-Adam

> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Jon
> Copeland
> Sent: August 1, 2017 16:10
> To: pfSense Support and Discussion Mailing List 
> Subject: Re: [pfSense] IPv6 problem at OVH
> 
> We have this exact setup.  You are correct, you will need Virtual IP's for
> each public WAN IP that OVH have assigned you.  We have separate
> services listening on x.x.x.1, x.x.x.2, x.x.x.3 etc, works like a charm.
> 
> JC
> 
> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Adam
> Thompson
> Sent: August-01-17 12:57 PM
> To: list@lists.pfsense.org
> Subject: [pfSense] IPv6 problem at OVH
> 
> Wondering how anyone else manages (or would manage) this scenario:
> 
> * Private Cloud at OVH.  (Runs VMware, which isn't terribly relevant
> AFAICT.)
> * OVH provides a single VLAN that is connected directly to their router
> * ALL public IP addresses are terminated on that VLAN (i.e. bound
> directly to that interface on their router) including the entire IPv6 /56.
> *** As a consequence, all IPv4 addresses must respond to ARP, and all
> IPv6 addresses must respond to NDP, in order to be successfully publicly
> routed.
> (And yes, they gave me an entire /56 of IPv6... that isn't routed or
> broken up in any way.  And they won't subnet or route anything to me.
> Yay.)
> * Meanwhile, I have public services (multiple tenants) running on
> multiple VLANs, each behind a single pfSense firewall with a WAN
> interface in the massive public-address-space VLAN.
> * I very much want the service address to be different from the firewall
> address, i.e. the firewall WAN i/f might be bound to 1.2.3.4, then I want
> the publicly-accessible service to live at 1.2.3.5, so that I can distinguish
> based on reverse DNS whether outbound connections are coming from
> the firewall or from the customer's server.  This works great with IPv4, a
> Proxy ARP VIP, and 1:1 NAT.
> * I also need to provide IPv6 connectivity inbound AND outbound, ideally
> with the same reverse-dns differentiation.
> 
> I've tried 1:1 NAT, which seems to break IPv6 altogether every time I
> configure it (although JimP can't reproduce it yet, so presumably it's
> somehow environment-specific).  I'm unclear whether this will work
> anyway with the NDP adjacency requirement.
> 
> I've tried NPt, which doesn't do NDP, and so doesn't work in this
> scenario.
> 
> The next thing I can try (but haven't yet) is an IP Alias VIP with Port
> Forwarding, and then... maybe a custom Outbound NAT rule?
> 
> Am I missing something fundamental?  I know what OVH is doing is
> stupid (NDP for an entire /56?  Fee fi fo fum, I smell a DoS attack...) , but
> they have 2000+ other customers on this exact platform, surely ONE of
> them must have a similar situation!  I know IPv6 is new, but ... surely one
> them must run IPv6?
> 
> Again: IPv4 isn't a problem because Proxy ARP works great and solves
> the silliness of them not routing those allocated subnets to me.  IPv6 is a
> problem because pfSense has to handle NDP *and* do NAT and I can't
> find a way to make it do that properly
> 
> 
> Thoughts/opinions/brickbats welcome.
> -Adam
> 
> P.S. I seem to not be receiving emails from the list reliably, kindly CC me
> if you don't mind...
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold


Re: [pfSense] IPv6 problem at OVH

2017-08-02 Thread Adam Thompson
I can't speak to their other platforms, but the Private Cloud offering is based 
on VMware, and does not permit the use of MAC addresses other than the one 
assigned to the VM.  So CARP immediately fails there.
Amusingly (not), there's even special plug-in in the VMware client that is 
supposed to let me enable "OVH CARP" (it appears its function is to toggle the 
VMware distributed vSwitch setting allowing "forged" MAC addresses and 
promiscuous mode) but it doesn't actually work as it relies on the cluster 
being connected to a Cisco Nexus 1000v vSwitch, which OVH appears to have 
deprecated and removed.
So, in any case, anything that requires MAC address changes won't work.
-Adam


> -Original Message-
> From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Olivier
> Mascia
> Sent: August 2, 2017 02:31
> To: pfSense Support and Discussion Mailing List 
> Subject: Re: [pfSense] IPv6 problem at OVH
> 
> > Le 2 août 2017 à 00:39, Matthew Hall  a
> écrit :
> >
> >> The real issue is that HA setup of a couple of pfSense is impossible
> >> with such an awkward IPv6 setup as OVH imposes to us.
> >
> > Just curious: how does it break CARP + pfSync?
> 
> I don't have the exact specifics in memory right now, but I'll see to dust-
> off some old notes. I remember it was inextricable. But could be a bug in
> VRRP implementation on OVH side and nothing to do with the way they
> (don't) route the IPs (as CARP + pfSync works fine on IPv4 on the same
> platform and the way they deliver IPv4).
> 
> Without those notes, the most specific I remember is that packets were
> coming in randomly on the master (processing them) and the slave
> (properly ignoring them). Just as if the same MAC was seen on both on
> their OVH side.
> 
> 
> --
> Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier
> Mascia, http://integral.software
> 
> 
> ___
> pfSense mailing list
> https://lists.pfsense.org/mailman/listinfo/list
> Support the project with Gold! https://pfsense.org/gold

___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold

Re: [pfSense] IPv6 problem at OVH

2017-08-02 Thread Olivier Mascia
> Le 2 août 2017 à 00:39, Matthew Hall  a écrit :
> 
>> The real issue is that HA setup of a couple of pfSense is impossible with 
>> such an awkward IPv6 setup as OVH imposes to us.
> 
> Just curious: how does it break CARP + pfSync?

I don't have the exact specifics in memory right now, but I'll see to dust-off 
some old notes. I remember it was inextricable. But could be a bug in VRRP 
implementation on OVH side and nothing to do with the way they (don't) route 
the IPs (as CARP + pfSync works fine on IPv4 on the same platform and the way 
they deliver IPv4).

Without those notes, the most specific I remember is that packets were coming 
in randomly on the master (processing them) and the slave (properly ignoring 
them). Just as if the same MAC was seen on both on their OVH side.


-- 
Best Regards, Meilleures salutations, Met vriendelijke groeten,
Olivier Mascia, http://integral.software


___
pfSense mailing list
https://lists.pfsense.org/mailman/listinfo/list
Support the project with Gold! https://pfsense.org/gold