Re: [pfSense] 2.4.3 - cannot define table bogonsv6
Thanks Victor, > On Sun, Apr 1, 2018 at 4:46 PM, Olivier Mascia <o...@integral.be> wrote: > >> Since I have upgraded 2 HW box and 2 VMs to 2.4.3 I have started seeing >> such occasionally: >> >> 0:40:54 There were error(s) loading the rules: /tmp/rules.debug:22: cannot >> define table bogonsv6: Cannot allocate memory - The line in question reads >> [22]: table persist file "/etc/bogonsv6" >> >> Is there a known bug/quirk at work here? > Le 2 avr. 2018 à 01:05, Victor Padro <vpa...@gmail.com> a écrit : > > Change the value of the Firewall Maximum Table Entries to 50 in System > | Advanced | Firewall & NAT Indeed it then reloads filter cleanly. The default (empty) is said to be 200'000. So 500'000 is a large change from default. Is that the default is now highly underestimated and should/will be raised later or that this needs be significantly higher than default only because I use IPv6 and have Block logon networks checked? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] 2.4.3 - cannot define table bogonsv6
Since I have upgraded 2 HW box and 2 VMs to 2.4.3 I have started seeing such occasionally: 0:40:54 There were error(s) loading the rules: /tmp/rules.debug:22: cannot define table bogonsv6: Cannot allocate memory - The line in question reads [22]: table persist file "/etc/bogonsv6" Is there a known bug/quirk at work here? -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia ___ 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
> Le 2 août 2017 à 14:46, Adam Thompson <athom...@athompso.net> 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
> Le 2 août 2017 à 14:50, Adam Thompson <athom...@athompso.net> 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
> Le 2 août 2017 à 00:39, Matthew Hall <mh...@mhcomputing.net> 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
Re: [pfSense] IPv6 problem at OVH
> Le 1 août 2017 à 23:09, Jon Copeland <jcopel...@causmx.com> a écrit : > > 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 > 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. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia > -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] /status_queues.php: amortised/smoothed values?
Dear, Context: /status_queues.php (2.3.2-RELEASE-p1). This is not specific to this version: I have been lazy reporting. Sorry. The displayed values seem averaged over a quite lengthly period of time. If I'm seeing a considerable increase of traffic for some minutes, the values reported grow slowly. When the peak gets down and there is no more traffic (or so, let's say some Kbps only, close to zero or zero), the values reported decrease very slowly. Can this be tuned? I'd find it helpful to see more instantaneous values in status_queues.php than smoothed accumulated values. I find this helpful to visually get a big picture on wether my shaping rules are effective in their triage of the traffic. -- Best Regards, Meilleures salutations, Met vriendelijke groeten, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Strange fe80::1:1 link-local address on LAN interface
By the way, this is on a pfSense/Netgate device and I still have at least 2 support incidents available. I'd happily burn at least one of them to have someone remotely check this. I'll be back on site within 2 hours from this post, I'll check the web by then for the proper procedure to open a case. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia (from mobile device), integral.be/om > Le 26 mai 2016 à 13:03, Olivier Mascia <o...@integral.be> a écrit : > > LAN Interface (lan, igb0) > Statusup > MAC Address00:08:a2:09:58:96 > IPv4 Address10.32.0.1 > Subnet mask IPv4255.255.0.0 > IPv6 Link Localfe80::1:1%igb0 (???) > IPv6 Address2a02:578:4d07::1 > Subnet mask IPv664 > MTU1500 > Media1000baseT > > I do not understand where this fe80:1:1 comes from, it clearly isn't derived > from the MAC. > > Indeed workstations on the LAN capture fe80::1:1 for their default gateway > and even pinging that IP from a workstation doesn't work: > > ping6 fe80::1:1 > PING6(56=40+8+8 bytes) fe80::aa20:66ff:fe21:7c8e%en2 --> fe80::1:1 > ping6: sendmsg: No route to host > ping6: wrote fe80::1:1 16 chars, ret=-1 > ping6: sendmsg: No route to host > ping6: wrote fe80::1:1 16 chars, ret=-1 > > Not surprised. > The question is where could this fe80::1:1 come from? > So I could get rid of it and get there a proper link-local address? > > Reboot does not help. > Downloaded config file, there is no fe80::1:1 anywhere in there. > > -- > Meilleures salutations, Met vriendelijke groeten, Best Regards, > Olivier Mascia, integral.be/om > > > ___ > 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] Strange fe80::1:1 link-local address on LAN interface
LAN Interface (lan, igb0) Status up MAC Address 00:08:a2:09:58:96 IPv4 Address10.32.0.1 Subnet mask IPv4255.255.0.0 IPv6 Link Local fe80::1:1%igb0 (???) IPv6 Address2a02:578:4d07::1 Subnet mask IPv664 MTU 1500 Media 1000baseT I do not understand where this fe80:1:1 comes from, it clearly isn't derived from the MAC. Indeed workstations on the LAN capture fe80::1:1 for their default gateway and even pinging that IP from a workstation doesn't work: ping6 fe80::1:1 PING6(56=40+8+8 bytes) fe80::aa20:66ff:fe21:7c8e%en2 --> fe80::1:1 ping6: sendmsg: No route to host ping6: wrote fe80::1:1 16 chars, ret=-1 ping6: sendmsg: No route to host ping6: wrote fe80::1:1 16 chars, ret=-1 Not surprised. The question is where could this fe80::1:1 come from? So I could get rid of it and get there a proper link-local address? Reboot does not help. Downloaded config file, there is no fe80::1:1 anywhere in there. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Aliases on IPv6 CARP, are they known to be working? Or could there be a bug?
> Let one HA setup with xxx::2 and xxx::3 as their WAN and xxx::1 defined as > CARP. > Now let xxx::10 defined as IP alias on parent xxx::1 (the WAN CARP), same > prefix length as for the xxx::1. > > Clearly for packets coming in for xxx::1 (CARP), the system works as designed > (master gets them, backup no). > But for packets coming in for xxx::10 alias, the packets randomly reach both > systems, just as if we were in the wrong configuration where two hosts have > the same IP : whatever switch/router sits in front of WAN interface gets mad. I have made an additional discovery. And my description wasn't accurate enough. If I set things up exactly as above: it works. It fails as soon as NPt gets in the way. Here's how. WAN primary xxx:dd00::2 /57 secondary xxx:dd00::3 /57 carp xxx:dd00::1 /57 alias xxx:dd01::10 /57 (on above carp xxx:dd00::1) LAN primary xxx:dd81::2 /64 secondary xxx:dd81::3 /64 carp xxx:dd81::1 /64 NPt external xxx:dd01:: /64 internal xxx:dd81:: /64 On the LAN side, let a box with IP xxx:dd81::10 (/64), gateway to xxx:dd81::1 For the remaining assume the primary is actually master, and the secondary is backup. Now I think my description of the context of the issue is right and true. Problem is indeed this: Packets incoming on WAN for xxx:dd01::10 are in error, going randomly to primary and secondary. If test pinging from the host at xxx:dd81::10 to the outside, all echo requests are captured correctly on the WAN of the master. But echo replies come back randomly to the master and the backup. I now recognize clearly NPt gets in the way. I know you will ask why NPt? The provider I have to live with for now, in front of my WAN *cannot* (for now, they say), set things so they properly route our /56 to us through a PtP subnet. I wouldn't have NPt at all, and would have no aliases to define, and would not have any question to ask. But they can't proceed (hardly believable, yes) for now. The above trick using NPt, splitting the /56 subnet in two /57 halves, one used on the WAN, allows me to re-use some part of the second half on the LAN after NPt magic. That's the reason of the numbering above: dd01 actually translate to dd81 which is on the next /57 of the /56. I think I'm not mistaken saying there is nothing else I could do to use the IPv6 block as long as they don't route it properly to our WAN. And without HA setup, it actually works fine. But with CARP in the way, IP aliases on the WAN carp which happen to be reflected on the LAN through NPt, do get into trouble. It probably is much more expected than a bug, but maybe some wizard here will have a clever idea (short of changing provider - which is in the plan anyway but will take months) to overcome this? Thanks again! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Aliases on IPv6 CARP, are they known to be working? Or could there be a bug?
Hello Chris, Jim and all, Let one HA setup with xxx::2 and xxx::3 as their WAN and xxx::1 defined as CARP. Now let xxx::10 defined as IP alias on parent xxx::1 (the WAN CARP), same prefix length as for the xxx::1. Clearly for packets coming in for xxx::1 (CARP), the system works as designed (master gets them, backup no). But for packets coming in for xxx::10 alias, the packets randomly reach both systems, just as if we were in the wrong configuration where two hosts have the same IP : whatever switch/router sits in front of WAN interface gets mad. This situation is seen in an ESXi cluster with those systems being 2.3.1 VMs. The 'whatever switch/router' sitting in front of WAN happens to be Cisco 1000v. This is not my equipment, so my investigation capabilities are limited. I'm simply not yet sure if this something bad outside of pfSense or if this is something going wrong with pfSense in the context of IP aliases added with a parent interface being the WAN CARP IP (in IPv6). With IPv4, the equivalent setup (some IP alias on top of the WAN CARP IPv4), I do not see this wrong behavior. This is why I fear a bug in pfSense/freeBSD anyway. If someone could confirm / infirm this, it would prove very helpful. Thanks! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Why can't we define a point-to-point OpenVPN using only IPv6?
> Le 24 mai 2016 à 17:56, Doug Lytle <supp...@drdos.info> a écrit : > >> Is the IPv4 requirement something thats planned to be removed in future >> releases? >> >> I don't assume many people have adopted IPv6 yet. > > Ensuring stable, robust and complete IPv6 (+IPv4) support was and is > the primary goal for 2.4 > > IPv6-only was a non-goal so far, so nobody invested time into it yet - > but of course, eventually nobody wants to bother with IPv4 anymore :-) > > Realistically, though, there's more pressing things to work on - like > cipher negotiation (so you can upgrade encryption without having to > roll out new configs to all your clients), actually *releasing* 2.4, etc. You're going too far compared to what I asked: I'm not asking for IPv6 only support. It just is that I have a need to create an OpenVPN tunnel between two sites only transporting IPv6 (I have an *other* tunnel using IPsec between these 2 sites for IPv4, but I'm fixing whatever bugs held me from successfully tunneling IPv6 between those two sites through IPsec by adding another IPv6 only tunnel using OpenVPN. For sure a world without IPv4 is not for tomorrow, I don't think this is a goal in itself either. Though, IPv6 is *very* important in significant portions of the world *today* (and *yesterday* too). Generally I have no real problems with pfSense with IPv6. The software is excellent (and the labeled hardware too). Except recently between an old 2.2.2 (which I can't upgrade to 2.2.6 or 2.3.x) and a 2.3.x which gave me headaches trying to get IPv6 to get through IPsec. I finally abandoned the idea of it between those two sites. Oh side note: since initial post I *could* setup the IPv6-only site-to-site tunnel. I just had to trick, giving OpenVPN an IPv4 tunnel subnet as it insisted for, but did not declare any local or remote IPv4 subnets (to route between sites). Works for me, both tunnels (IPsec IPv4 and OpenVPN IPv6) are now happily living next to each other. That's a temporary solution for 1 to 3 months, then the old site with 2.2.2 will disappear. Of course the downside of this trick is that my IPv6 traffic is so much slower through OpenVPN than through IPsec. It is even asymmetric: A to B is 10 times faster (about 200 Mbps) than B to A (about 20 Mbps when sun shines, ~15 Mbps in other times) through the OpenVPN tunnel. The IPv4 is much better served through the IPsec tunnel (similar speeds both ways, and they're at about 500 Mbps, sometimes a little bit higher. I know from a previous discussion here why this speed difference between IPsec and OpenVPN. Thanks ! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPv6 with Comcast and two pfSense - invalid prefix length, XID mismatch
There's indeed no NAT concept in IPv6 but you can use NPt to assign globally routable IPs on WAN and have them match to a translated locally routable prefix. Say you have x:y:z:a::/64 on the WAN side which translate to fd01::/64 on the LAN side. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia (from mobile device), integral.be/om > Le 19 mai 2016 à 21:59, Steve Yates <st...@teamits.com> a écrit : > > Is there a way to force pfSense to do NAT for IPv6? If so then we could make > it work. I understand that's not the point of IPv6 but... ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Switching from 2.3.1 DEV to 2.3.1 REL ?
> Le 19 mai 2016 à 11:29, Renato Botelho <ga...@freebsd.org> a écrit : > >> On May 18, 2016, at 20:39, Olivier Mascia <o...@integral.be> wrote: >> >> I had switched through the GUI to Branch development snapshots experimental >> while I was initially in 2.3-REL on some boxes. It helped a lot in the >> interim. >> Following announcement of 2.3.1-REL I just switched the GUI settings back to >> Stable branch. >> But upon checking for new update, it offers me some 2.3.2 snapshot, and not >> 2.3.1-REL. >> >> I guess the steps to do should be more or less similar to those I had to do >> to switch from 2.3 beta to 2.3 REL. >> But could you please remind these steps (or link) here to help? >> > > When you use stable repo configuration, as you did, you will show on GUI > 2.3.2 as the next available version and it happens because your current > repository config still have information about devel branch, since stable > didn’t exist yet when you updated last time. > > You can go ahead and upgrade and you will end up on 2.3.1-RELEASE, but if you > want to be really sure about it, go to console and run option 13, when it > asks for confirmation just say No. At this point all repo information will be > updated and you will see 2.3.1-RELEASE even on GUI Thanks Renato: perfectly clear explanation and it behaves exactly as described. Fixed (not an issue). -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Switching from 2.3.1 DEV to 2.3.1 REL ?
I had switched through the GUI to Branch development snapshots experimental while I was initially in 2.3-REL on some boxes. It helped a lot in the interim. Following announcement of 2.3.1-REL I just switched the GUI settings back to Stable branch. But upon checking for new update, it offers me some 2.3.2 snapshot, and not 2.3.1-REL. I guess the steps to do should be more or less similar to those I had to do to switch from 2.3 beta to 2.3 REL. But could you please remind these steps (or link) here to help? Could you also log the wish to have the GUI obey the instruction of switching back to Stable branch and indeed offer an 'upgrade' path from whatever snapshot it was on back or toward the latest REL version? I'm sure it would help some people, too. Many thanks for this 2.3.1 bug fix release! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
> Le 3 mai 2016 à 11:17, Olivier Mascia <o...@integral.be> a écrit : > >> Le 3 mai 2016 à 09:49, Chris Buechler <c...@pfsense.com> a écrit : >> >>> Or would it be that my BACKUP (according to /status_carp.php) do also >>> advertise (which it shouldn't as BACKUP)? >> >> That's the problem. I'm seeing that in some cases and not others with >> IPv6 CARP in 2.3, with no apparent reason as to why. It seems like it >> continues to work fine in that circumstance for me, but that could >> definitely affect switch CAM tables and cause issues like packet loss >> in some environments. I need to look at it closer tomorrow. > > It's a relief to read your comment. :) Chris, I upgraded the backup from 2.3-REL to 2.3.1-DEVELOPMENT (amd64), built on Thu May 12 23:47:16 CDT 2016. It started working as expected as soon as that one booted after the upgrade. On this backup node, capturing the ff02::12 I'm now *ONLY* seeing those from the master. And I do not suffer anymore (well I hope I'm not speaking too soon, but it is stable for >1 hour now) of the weird effect of some packets choosing to go to the backup instead of the master. Has something been changed/fixed in the current snapshots which would explain this or I'm just running by chance, I do not know. I'll try to understand by reviewing redmine for bug fixes and changes. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] NPt and IPsec on pfSense
> Le 12 mai 2016 à 11:11, Olivier Mascia <o...@integral.be> a écrit : > > Assuming two sites having to use NPt to map IPv6 IP Alias from WAN to > fd00::/64 like on the LAN. > > For instance: > > Site A: a:b:c:1000::1/56 is the WAN IPv6. And a:b:c:1001::1/64 (IP Alias on > WAN) match with fd01::1/64 on LAN through NPt. > Site B: w:x:y:1000::1/56 is the WAN IPv6. And w:x:y:1002::1/64 (IP Alias on > WAN) match with fd02::1/64 on LAN through NPt. > > IPsec with a phase1 IKEv2 (over IPv6, but same issue with IPv4) between WAN > IPs. > Along with a phase2 (tunnel6) defined between fd01::/64 and fd02::/64. > > IPsec connection shows up, including phase2. But nothing walks through the > tunnel. > For instance Site A LAN fd01::2 pings some Site B LAN fd02::2, and nothing is > routed through the tunnel. > I'm quite persuaded it has to do with the NPt. > > When does exactly the NPt translation occurs and how does it interact with > IPsec tunnels defined? That would help understand where this is failing and > if there is a path to a solution. Some more experiments and searches later... NPt doesn't seem to be the culprit, 2.3-REL looks like it is. One of the ends is 2.2.2 (a nearly exactly one year old release - 14 Apr 2015), and the other is 2.3. From the 2.3 site (pinging the remote) I can capture the right ESP packets going out through the WAN interface. On the other end 2.2.2 site, I can capture on the ipsec interface both the incoming echo requests and the outgoing echo replies. I can also track the corresponding outgoing ESP packets on its WAN interface. But the 2.3 site does not get *anything*. I can't even see an incoming ESP packet (we're taking IPv6 here all along) on its WAN. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] NPt and IPsec on pfSense
Hello, Assuming two sites having to use NPt to map IPv6 IP Alias from WAN to fd00::/64 like on the LAN. For instance: Site A: a:b:c:1000::1/56 is the WAN IPv6. And a:b:c:1001::1/64 (IP Alias on WAN) match with fd01::1/64 on LAN through NPt. Site B: w:x:y:1000::1/56 is the WAN IPv6. And w:x:y:1002::1/64 (IP Alias on WAN) match with fd02::1/64 on LAN through NPt. IPsec with a phase1 IKEv2 (over IPv6, but same issue with IPv4) between WAN IPs. Along with a phase2 (tunnel6) defined between fd01::/64 and fd02::/64. IPsec connection shows up, including phase2. But nothing walks through the tunnel. For instance Site A LAN fd01::2 pings some Site B LAN fd02::2, and nothing is routed through the tunnel. I'm quite persuaded it has to do with the NPt. When does exactly the NPt translation occurs and how does it interact with IPsec tunnels defined? That would help understand where this is failing and if there is a path to a solution. Shouldn't the phase2 tunnel6 be defined in terms of a:b:c:1001::/64 and w:x:y:1002::/64 instead of fd01::/64 and fd02::/64? Obviously since I'm asking, I tested that without success, but I could have mixed up something during all the attempts I did. Would some NPt translation be needed on the IPsec interface itself? If I'm setting up an IPv4 configuration, I have no issue: using both LAN networks on the phase2 tunnel definition and it works fine. I tried to find similar configuration examples but couldn't yet find anything giving me clues. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] 2.3-REL check_reload_status high cpu load
This is dual core and CARP HA setup.
Having issues and found out that check_reload_status uses 100%.
last pid: 20560; load averages: 1.07, 1.01, 0.72 up 0+00:21:3823:10:20
122 processes: 4 running, 100 sleeping, 18 waiting
Mem: 51M Active, 53M Inact, 112M Wired, 75M Buf, 1745M Free
Swap: 2048M Total, 2048M Free
PID USERNAME PRI NICE SIZERES STATE C TIMEWCPU COMMAND
299 root 123 20 1K 2504K CPU00 15:25 100.00%
/usr/local/sbin/check_reload_status
11 root 155 ki31 0K32K RUN 0 14:15 60.99% [idle{idle:
cpu0}]
11 root 155 ki31 0K32K RUN 1 13:08 42.97% [idle{idle:
cpu1}]
0 root -16- 0K 192K swapin 0 0:25 0.00% [kernel{swapper}]
4 root -16- 0K32K - 0 0:01 0.00% [cam{scanner}]
12 root -60- 0K 288K WAIT1 0:00 0.00% [intr{swi4:
clock}]
35889 root 200 101M 8312K select 0 0:00 0.00%
/usr/local/bin/vmtoolsd -c /usr/local/shar
12 root -92- 0K 288K WAIT0 0:00 0.00% [intr{irq256:
vmx0}]
41215 root 210 262M 36564K piperd 0 0:00 0.00% php-fpm: pool
nginx (php-fpm)
7 root -16- 0K16K pftm0 0:00 0.00% [pf purge]
15 root -16- 0K16K - 1 0:00 0.00% [rand_harvestq]
82176 root 200 46196K 8284K kqread 1 0:00 0.00% nginx: worker
process (nginx)
4 root -16- 0K32K - 0 0:00 0.00% [cam{doneq0}]
82987 root 52 20 17000K 2592K wait1 0:00 0.00% /bin/sh
/var/db/rrd/updaterrd.sh
12 root -92- 0K 288K WAIT1 0:00 0.00% [intr{irq257:
vmx1}]
52990 unbound 200 43084K 18676K kqread 1 0:00 0.00%
/usr/local/sbin/unbound -c /var/unbound/un
54788 root 200 30140K 17968K select 1 0:00 0.00%
/usr/local/sbin/ntpd -g -c /var/etc/ntpd.c
41400 root 200 15012K 2220K nanslp 0 0:00 0.00%
[dpinger{dpinger}]
See ps uxawww belog sig.
What to look for?
What to test?
What to dump or log to narrow the issue?
--
Meilleures salutations, Met vriendelijke groeten, Best Regards,
Olivier Mascia, integral.be/om
ps uxawww
USER PID %CPU %MEMVSZ RSS TT STAT STARTED TIME COMMAND
root 11 101.0 0.0 032 - RL 10:48PM 22:34.31 [idle]
root 299 100.0 0.1 1 2504 - RNs 10:48PM 10:36.06
/usr/local/sbin/check_reload_status
root0 0.0 0.0 0 192 - DLs 10:48PM 0:00.00 [kernel]
root1 0.0 0.0 9136 788 - ILs 10:48PM 0:00.00 /sbin/init --
root2 0.0 0.0 016 - DL 10:48PM 0:00.00 [crypto]
root3 0.0 0.0 016 - DL 10:48PM 0:00.00 [crypto returns]
root4 0.0 0.0 032 - DL 10:48PM 0:00.06 [cam]
root5 0.0 0.0 016 - DL 10:48PM 0:00.00 [mpt_recovery0]
root6 0.0 0.0 016 - DL 10:48PM 0:00.00 [fdc0]
root7 0.0 0.0 016 - DL 10:48PM 0:00.17 [pf purge]
root8 0.0 0.0 016 - DL 10:48PM 0:00.00 [sctp_iterator]
root9 0.0 0.0 032 - DL 10:48PM 0:00.01 [pagedaemon]
root 10 0.0 0.0 016 - DL 10:48PM 0:00.00 [audit]
root 12 0.0 0.0 0 288 - WL 10:48PM 0:00.78 [intr]
root 13 0.0 0.0 032 - DL 10:48PM 0:00.00 [ng_queue]
root 14 0.0 0.0 048 - DL 10:48PM 0:00.01 [geom]
root 15 0.0 0.0 016 - DL 10:48PM 0:00.11 [rand_harvestq]
root 16 0.0 0.0 016 - DL 10:48PM 0:00.00 [vmdaemon]
root 17 0.0 0.0 016 - DL 10:48PM 0:00.00 [pagezero]
root 18 0.0 0.0 016 - DL 10:48PM 0:00.00 [idlepoll]
root 19 0.0 0.0 032 - DL 10:48PM 0:00.01 [bufdaemon]
root 20 0.0 0.0 016 - DL 10:48PM 0:00.04 [syncer]
root 21 0.0 0.0 016 - DL 10:48PM 0:00.00 [vnlru]
root 51 0.0 0.0 016 - DL 10:48PM 0:00.02 [md0]
root 301 0.0 0.1 1 2288 - IN 10:48PM 0:00.00
check_reload_status: Monitoring daemon of check_reload_status
root 311 0.0 0.2 13624 4836 - Is 10:48PM 0:00.01 /sbin/devd -q
root12668 0.0 0.3 59068 6340 - Is 10:48PM 0:00.00 /usr/sbin/sshd
root12740 0.0 0.1 14612 2108 - Is 10:48PM 0:00.00
/usr/local/sbin/sshlockout_pf 15
root23356 0.0 0.1 14400 2124 - S10:48PM 0:00.01
/usr/local/sbin/radvd -p /var/run/radvd.pid -C /var/etc/radvd.conf -m syslog
root23972 0.0 0.1 14516 2316 - Ss 10:48PM 0:00.04
/usr/sbin/syslogd -s -c -c -l /var/dhcpd/var/run/log -P /var/run/syslog.pid -f
/var/etc/syslog.conf
root25962 0.0 0.1 12268 1872 - Is 10:48PM 0:00.00
/usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh
root26226 0.0 0.1 12268 1884 - I10:48PM 0:00.00
[pfSense] HA setup (CARP) + IPv6 + NPt ?
Hello list, I might have a partial clue to my issues getting IPsec (phase1 IPv4 + 2 phase2 IPv4 and IPv6) to work correctly regarding IPv6. To synthesize the issue, I have the IPv4 tunnels on easily. The IPv6 tunnel shows up, but no traffic flows the tunnel. Since then, I have had the opportunity to redo that setup between two other site, and there it works. The difference? The tunnel that works doesn't use NPt. The tunnel that I can't get IPv6 flowing through have NPt on both ends. Would there be a known impossibility here? This works: IPv4 Phase1 between to end-points (both are 2.3-REL), with two phase2 (one IPv4 tunnel between 10.49.0.0/16 and 10.32.0.0/16 and one IPv6 tunnel between a.b.c.d:://64 and a.b.c.e::/64 which are the subnets configured on LANs - no NPt here in the game). This does not work : IPv4 Phase1 between to other end-points (one is 2.3-REL, on is 2.2.2-REL), with two phase2 (one IPv4 tunnel between 10.0.0.0/16 and 10.1.1.0/24 and one IPv6 tunnel between fd00:://64 and fd01::/64 which are the subnets configured on LANs - NPt is used on these systems). Any idea or explanation? I fear NPt gets in the way of the decision routing before entering the tunnel. Could this be worked around? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
Thanks Steve, > Are you only syncing in one direction? > > fe80::250:56ff:febf:3ca5 is a link-local address which looks a bit strange in > my skimming of the below. > > Overall, we have two IPv6 ranges for the routing: > WAN CARP IP: 2607:ff50::12/125 > WAN IP router 1: 2607:ff50::17/125 > WAN IP router 2: 2607:ff50::16/125 > LAN block: 2607:ff50:0:4c::0/64 > > 2607:ff50:0:4c::0/64 is routed to 2607:ff50::12 by our data center. CARP > syncs over IPv4 and we've not had a problem. We're on 2.2.6. I also have only global IPv6 addresses on both WAN and as CARP IP. But each interface always have a link-local address. Check /status_interfaces.php for instance. And the CARP announcements seem to be sent from these LL addresses. (For the PFSYNC between both FW, I have a third interface 'opt1' dedicated to that link, using IPv4 indeed.) It probably is similar for you. If you'd like, run a packet capture on your WAN, address family IPv6, protocol ANY: you should see some lines similar to this one (among possibly many other things - a 3 to 5 seconds capture will be more than enough): > FW1: 11:59:13.379073 IP6 fe80::250:56ff:febf:3ca5 > ff02::12: ip-proto-112 36 > ... Now run the same on your other box, and the source address you will see will be the same as on the first box. For the test, do NOT filter on IPv6 and then CARP : won't work, never captures anything (on IPv6). Must be a bug in the packet capture interface of pfSense. > "CARP is not permitted on their equipment" > > Is that even possible? How would they prevent that other than tying the IP > address to a MAC address? It is more than possible because as things have (slowly) progressed today, it now looks nearly certain they're the problem. On my LAN interfaces, CARP works perfectly for our LAN side CARP IPv4 and CARP IPv6. It's only on the interfaces facing them that it fails. I guess something to do with multicasts FF02::12 being dropped by switches. They're supposed to remove blocking on request and I'm now pretty sure they do something wrong in this regard. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 4 mai 2016 à 21:13, Steve Yates <st...@teamits.com> a écrit : > > "IPv6 does not seem to get proper advertisements from peer and both think > they're MASTER" > > Are you only syncing in one direction? > > fe80::250:56ff:febf:3ca5 is a link-local address which looks a bit strange in > my skimming of the below. > > Overall, we have two IPv6 ranges for the routing: > WAN CARP IP: 2607:ff50::12/125 > WAN IP router 1: 2607:ff50::17/125 > WAN IP router 2: 2607:ff50::16/125 > LAN block: 2607:ff50:0:4c::0/64 > > 2607:ff50:0:4c::0/64 is routed to 2607:ff50::12 by our data center. CARP > syncs over IPv4 and we've not had a problem. We're on 2.2.6. > > "CARP is not permitted on their equipment" > > Is that even possible? How would they prevent that other than tying the IP > address to a MAC address? > > -- > > Steve Yates > ITS, Inc. > > -Original Message- > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Olivier Mascia > Sent: Wednesday, May 4, 2016 5:12 AM > To: pfSense Support and Discussion Mailing List <list@lists.pfsense.org> > Subject: Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both > NICs > > >> Le 3 mai 2016 à 11:17, Olivier Mascia <o...@integral.be> a écrit : >> >>> Le 3 mai 2016 à 09:49, Chris Buechler <c...@pfsense.com> a écrit : >>> >>>> Or would it be that my BACKUP (according to /status_carp.php) do also >>>> advertise (which it shouldn't as BACKUP)? >>> >>> That's the problem. I'm seeing that in some cases and not others with >>> IPv6 CARP in 2.3, with no apparent reason as to why. It seems like it >>> continues to work fine in that circumstance for me, but that could >>> definitely affect switch CAM tables and cause issues like packet loss >>> in some environments. I need to look at it closer tomorrow. >> >> It's a relief to read your comment. :) >> >> As I clearly have a system where this happen, what would you need from me or >> my system to maybe help you pinpoint what's the cause? >> Could this possibly be a NIC drivers issue? >> Those are vmware VMs using VMXNET3 (underlying physical NICs on the cluster >> hosts are 10 Gbe). >> Would it be worth trying to downgrade to E1000 and see if it helps? Or a >> probable pure loss of time? >> >> Also, from your comment, am I right assuming this is not known to happen >> with <2.3 releases? >> So that I could c
[pfSense] How to debug an IPv6 phase2 over IPsec (IKEv2) IPv4 phase1?
Having switched recently from OpenVPN to IPsec (IKEv2 only) for 3 site to site tunnels, I'm still debugging why I can only get it to work for IPv4. Phase1 are setup with IPv4. Adding two phase2, one tunnel4 and one tunnel6, nothing flows through the tunnel6. Capturing on IPSEC interface on one side attempting a ping to remote site, I see for instance: 17:33:25.757775 (authentic,confidential): SPI 0xcf5bb1d6: IP6 fd00::1:1 > fd01::107: ICMP6, echo request, seq 170, length 40 But I get no replies from the other party. What's more, capturing ESP on the other side, I get NO incoming ESP packet at all. If I'm pinging IPv4, I trace the echo requests, I have ESP packets flowing on the other site and the echo replies on the sender: all works (can pipe any IPv4 traffic with excellent performance). Only the IPv6 seems stuck. Capturing the echo requests on the sender IPSEC interface, does this prove the packets embark the tunnel (and so that the issue is on the other end)? Or not? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
> Le 3 mai 2016 à 11:17, Olivier Mascia <o...@integral.be> a écrit : > >> Le 3 mai 2016 à 09:49, Chris Buechler <c...@pfsense.com> a écrit : >> >>> Or would it be that my BACKUP (according to /status_carp.php) do also >>> advertise (which it shouldn't as BACKUP)? >> >> That's the problem. I'm seeing that in some cases and not others with >> IPv6 CARP in 2.3, with no apparent reason as to why. It seems like it >> continues to work fine in that circumstance for me, but that could >> definitely affect switch CAM tables and cause issues like packet loss >> in some environments. I need to look at it closer tomorrow. > > It's a relief to read your comment. :) > > As I clearly have a system where this happen, what would you need from me or > my system to maybe help you pinpoint what's the cause? > Could this possibly be a NIC drivers issue? > Those are vmware VMs using VMXNET3 (underlying physical NICs on the cluster > hosts are 10 Gbe). > Would it be worth trying to downgrade to E1000 and see if it helps? Or a > probable pure loss of time? > > Also, from your comment, am I right assuming this is not known to happen with > <2.3 releases? > So that I could consider rebuilding those VMs using 2.2.6 for instance? > And upgrade to 2.3.x later? > > Thanks! I'm lost trying to get CARP / IPv6 working, including on 2.2.6 (I setup two new VM using 2.2.6 to compare results with those I had with 2.3). CARP works for IPv4 and IPv6 on my LAN side. On WAN side, only IPv4 is OK. IPv6 does not seem to get proper advertisements from peer and both think they're MASTER. The ports on which my WAN interfaces are plugged in are managed by the hosting provider and I tend to think they light have something setup wrong on their side. By default, CARP is not permitted on their equipment and I have to trigger (once) a GUI command to "activate CARP" on each of my interfaces facing their equipment. To my understanding it probably allows the required multicast to flow between both ports. I fear their setup might not work for the ff02::12 traffic. Capturing on IPv4, I see : FW1: 11:54:38.719091 IP 51.254.87.130 > 224.0.0.18: VRRPv2, Advertisement, vrid 104, prio 0, authtype none, intvl 1s, length 36 ... and FW2: 11:54:38.723415 IP 51.254.87.130 > 224.0.0.18: VRRPv2, Advertisement, vrid 104, prio 0, authtype none, intvl 1s, length 36 ... That looks good and understandable to me. State MASTER or BACKUP switch properly from one box or the other, when I shutdown one of the others, and restore properly to FW1 MASTER and FW2 BACKUP when both are online. Therefore, the IPv4 CARP VIP works properly which can be easily tested. Capturing on IPv6, I see : FW1: 11:59:13.379073 IP6 fe80::250:56ff:febf:3ca5 > ff02::12: ip-proto-112 36 ... and FW2: 11:59:13.202384 IP6 fe80::250:56ff:febf:37a3 > ff02::12: ip-proto-112 36 ... And both FW switch to MASTER. This same behavior with 2.3 and 2.2.6. I'll talk again to my supplier who have the control of those ports, insisting on checking IPv6 multicast. But I feel sad not really knowing if I'm hit by a bug their side or my side on pfSense level. If someone has CARP on IPv6 working, would you be so kind to check what you can capture about it (IPv6)? Does it differ from the scheme I'm seeing? Thanks!! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
> Le 3 mai 2016 à 09:49, Chris Buechler <c...@pfsense.com> a écrit : > >> Or would it be that my BACKUP (according to /status_carp.php) do also >> advertise (which it shouldn't as BACKUP)? > > That's the problem. I'm seeing that in some cases and not others with > IPv6 CARP in 2.3, with no apparent reason as to why. It seems like it > continues to work fine in that circumstance for me, but that could > definitely affect switch CAM tables and cause issues like packet loss > in some environments. I need to look at it closer tomorrow. It's a relief to read your comment. :) As I clearly have a system where this happen, what would you need from me or my system to maybe help you pinpoint what's the cause? Could this possibly be a NIC drivers issue? Those are vmware VMs using VMXNET3 (underlying physical NICs on the cluster hosts are 10 Gbe). Would it be worth trying to downgrade to E1000 and see if it helps? Or a probable pure loss of time? Also, from your comment, am I right assuming this is not known to happen with <2.3 releases? So that I could consider rebuilding those VMs using 2.2.6 for instance? And upgrade to 2.3.x later? Thanks! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
> Le 2 mai 2016 à 20:24, Olivier Mascia <o...@integral.be> a écrit : > > I have a problem with IPv6 on a HA setup. > > With IPv4, it is OK. > >> IPv4 : >> VLAN MAC Address TypeAge Port >> Mod >> -+-+---+-+--+--- >> 2776 .5e00.0168dynamic 0 Veth5 >> 5 >> 2776 .5e00.0168dynamic 0 Po4 >> 6 >> Total MAC Addresses: 2 > > With IPv6 the MAC is reported active on both pfSense's (Veth5/Veth6 instead > of Veth5/Po4 as above). > >> IPv6 >> VLAN MAC Address TypeAge Port >> Mod >> -+-+---+-+--+--- >> 2776 .5e00.016adynamic 1 Veth5 >> 5 >> 2776 .5e00.016adynamic 2 Veth6 >> 6 >> Total MAC Addresses: 2 > > I proceeded for IPv6 as for IPv4. > > One IPv6 address for each WAN interface: > x:y:z:d8ff::2/64 and x:y:z:d8ff::3/64. > And a CARP virtual IP definition of x:y:z:d8ff::1/64 on WAN interface. > The VHID is 106. > > Pinging from outside either one of the WAN adresses looks good. > Pinging the CARP VIP loose packets at varying rate and captures show echo > requests packets arriving randomly on each WAN interface. > > The IPv4 part of that same setup works wonderfully. In case anybody would doubt what I'm seeing... Here is a ping from one remote location to the CARP VIPv6: 16 bytes from x:y:z:d8ff::1, icmp_seq=0 hlim=57 time=17.095 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=1 hlim=57 time=16.801 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=2 hlim=57 time=16.906 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=3 hlim=57 time=16.004 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=4 hlim=57 time=17.142 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=8 hlim=57 time=16.766 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=11 hlim=57 time=18.267 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=15 hlim=57 time=18.232 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=18 hlim=57 time=16.817 ms 16 bytes from x:y:z:d8ff::1, icmp_seq=22 hlim=57 time=18.129 ms ^C See the missing replies 5, 6, 7, 9, 12, 13, 14, 16, 17, 19, 20, 21 ? Now look the capture on the WAN of the BACKUP pfSense: 00:50:29.040856 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 5, length 16 00:50:30.040092 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 6, length 16 00:50:31.040665 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 7, length 16 00:50:33.041250 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 9, length 16 00:50:34.041469 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 10, length 16 00:50:36.040262 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 12, length 16 00:50:37.041530 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 13, length 16 00:50:38.041524 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 14, length 16 00:50:40.040628 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 16, length 16 00:50:41.041671 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 17, length 16 00:50:43.041429 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 19, length 16 00:50:44.041769 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 20, length 16 00:50:45.040738 IP6 2a02:578:85a0:101:78eb:bc6c:8ac4:efa3 > x:y:z:d8ff::1: ICMP6, echo request, seq 21, length 16 Those echo requests weren't lost for everybody. :( -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
Sorry, top-posting this time. Capturing on WAN(x:y:z:d8ff::2/64), link-local = fe80::250:56ff:febf:7014 (is MASTER), I can see: 00:15:27.653423 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:28.663409 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:29.673410 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:30.683425 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:31.693405 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 00:15:32.703418 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:7014 > ff02::12: ip-proto-112 36 At the same time on WAN(x:y:z:d8ff::3/64), link-local = fe80::250:56ff:febf:3f5 (is BACKUP), I see: 00:15:27.196544 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:28.606544 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:30.016541 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:31.426541 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:15:32.836536 IP6 (hlim 255, next-header VRRP (112) payload length: 36) fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 I'm concerned about the source address being the BACKUP IPv6 link-local in those packets. Shouldn't they be the above :7014 instead of :3f5? With IPv4, that's one can see, the same source (the master) in those packets wether they're captured on master or backup. on x.y.z.130 WAN (master): 00:24:24.943397 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:25.953407 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:26.963397 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 on x.y.z.131 WAN (backup): 00:24:47.151981 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:48.162019 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 00:24:49.172016 IP 51.254.87.130 > 224.0.0.18: CARPv2-advertise 36: vhid=104 advbase=1 advskew=0 authlen=7 counter=10448678271752372706 What is it different with IPv6 (if that if) for these packets to stick their source address to the link-local? Or would it be that my BACKUP (according to /status_carp.php) do also advertise (which it shouldn't as BACKUP)? Indeed, if I halt the master, the backup switches to master role and look at the capture: 00:41:21.016506 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:22.426501 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:23.836499 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:25.246504 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 00:41:26.656497 IP6 fe80::250:56ff:febf:3f5 > ff02::12: ip-proto-112 36 The same as when it was backup... I think I start narrowing it a bit more here. But I'd do well with a gentle tap on the shoulder from one IPv6 / CARP guru from here... Must be some simple horrible configuration mistake... or a bug related to CARP IPv6 and in such case, if I can help gather whatever is needed to debug and fix it... -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 2 mai 2016 à 20:24, Olivier Mascia <o...@integral.be> a écrit : > > I have a problem with IPv6 on a HA setup. > > With IPv4, it is OK. > >> IPv4 : >> VLAN MAC Address TypeAge Port >> Mod >> -+-+---+-+--+--- >> 2776 .5e00.0168dynamic 0 Veth5 >> 5 >> 2776 .5e00.0168dynamic 0 Po4 >> 6 >> Total MAC Addresses: 2 > > With IPv6 the MAC is reported active on both pfSense's (Veth5/Veth6 instead > of Veth5/Po4 as above). > >> IPv6 >> VLAN MAC Address TypeAge Port >> Mod >> -+-+---+-+--+--- >> 2776 .5e00.016adynamic 1 Veth5 >&
[pfSense] 2.3-REL /diag_packet_capture.php - bug or misleading behavior
The /diag_packet_capture.php allows to set Address Family to IPv6 Only and further Protocol to CARP. In such case it captures nothing (or rather filters out too much). To actually see the ip-proto-112 packets to ff02::12, one has to set Protocol to Any. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] 2.3-REL, HA, WAN CARP IPv6 MAC seen as active on both NICs
I have a problem with IPv6 on a HA setup. With IPv4, it is OK. > IPv4 : > VLAN MAC Address TypeAge Port > Mod > -+-+---+-+--+--- > 2776 .5e00.0168dynamic 0 Veth5 > 5 > 2776 .5e00.0168dynamic 0 Po4 > 6 > Total MAC Addresses: 2 With IPv6 the MAC is reported active on both pfSense's (Veth5/Veth6 instead of Veth5/Po4 as above). > IPv6 > VLAN MAC Address TypeAge Port > Mod > -+-+---+-+--+--- > 2776 .5e00.016adynamic 1 Veth5 > 5 > 2776 .5e00.016adynamic 2 Veth6 > 6 > Total MAC Addresses: 2 I proceeded for IPv6 as for IPv4. One IPv6 address for each WAN interface: x:y:z:d8ff::2/64 and x:y:z:d8ff::3/64. And a CARP virtual IP definition of x:y:z:d8ff::1/64 on WAN interface. The VHID is 106. Pinging from outside either one of the WAN adresses looks good. Pinging the CARP VIP loose packets at varying rate and captures show echo requests packets arriving randomly on each WAN interface. The IPv4 part of that same setup works wonderfully. x.y.z.130/28 and x.y.z.131/28 CARP virtual IP of x.y.z.129/28 on WAN interface. The VHID is 104. No visible issue with simple pinging, no suspect packet captures, and no internetworking issues at all with IPv4. The direct link using opt1 on both boxes uses 172.16.0.2/24 and 172.16.0.3/24. The rules on that opt1 'sync' interfaces are setup according to the Book. One weird dumb question: would the opt1 'sync' interface also need IPv6 subnets in order for this to work? What could I do to help diagnose this further? Could it be a problem with 2.3-REL? I never had the opportunity to build and test such a setup with previous versions. I have support incidents purchased along with other pfSense hardware, but this is not on pfSense hardware but on VMs. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3_1 ?
> Le 2 mai 2016 à 16:19, Jason Hellenthal <jhellent...@dataix.net> a écrit : > > Signé partie PGP > _1 would not be a development release. That would be a patch or an addendum > which I would assume handles the ntp security flaw patched in recent FreeBSD > security release. > > https://www.freebsd.org/security/advisories/FreeBSD-SA-16:16.ntp.asc > > On May 2, 2016, at 08:54, Olivier Mascia <o...@integral.be> wrote: > > The update check on 2.3-REL GUI offers me 2.3_1, yet I don't see mention of > it on pfsense.org. > Could it be that my system polls for dev branch releases and not only > released builds? > Or that the auto-update only revealed the beast before the blog on > pfsense.org? Indeed. Installed packages to be UPGRADED: pfSense: 2.3 -> 2.3_1 [pfSense] ntp: 4.2.8p6 -> 4.2.8p7 [pfSense] -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] 2.3_1 ?
The update check on 2.3-REL GUI offers me 2.3_1, yet I don't see mention of it on pfsense.org. Could it be that my system polls for dev branch releases and not only released builds? Or that the auto-update only revealed the beast before the blog on pfsense.org? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPsec: tunneling both IPv4 and IPv6 between two sites
> Le 1 mai 2016 à 18:47, WebDawg <webd...@gmail.com> a écrit : > >> I have had a performance issue with OpenVPN recently (though I used OpenVPN >> a lot in the past for remote access VPN and some point to point link over >> slow links). I started using IPsec for those two new links with higher >> performance and the results are excellent. Indeed I configured IKEv2 on both >> endpoints. So I should push the experience of adding a second phase2 for >> tunneling IPv6. >> >> Thanks ! >> > What kind of performance issues? Highspeed links? Just wondering. Recent threads here in this list: "Debugging a bi-directional speed discrepancy through an OpenVPN tunnel" and "IPsec - how to assess encryption is active?" have all the details. In short: yes, 1.5 Gbps links, OpenVPN 350 Mbps in one direction (I could have lived with that) and about 15 Mbps in the other (I couldn't trace why). With IPsec I got results in the range 500 to 750 Mbps in both directions, and it's clear that with more specific hardware, higher rates might be attained. Now if only I could get my IPv6 traffic take the train along with the IPv4 packets, it'd be perfect. :) -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPsec: tunneling both IPv4 and IPv6 between two sites
> Le 1 mai 2016 à 10:35, Olivier Mascia <o...@integral.be> a écrit : > >> That page is a little out of date in one respect: You can't mix traffic >> with IPsec using IKEv1, but you can with IKEv2. So long as both sides >> support IKEv2 you can carry IPv6 and IPv4 in P2 entries. >> >> FWIW, You can also tunnel both at once using OpenVPN. > I'm busy testing that but my IPv6 traffic doesn't cross the tunnel. On Status / IPsec I'm seeing this, having defined two phase2 (one tunnel IPv4 and one tunnel IPv6): 10.0.0.0/16 Local: cb9f5c9f 10.1.1.0/24 Rekey: 694 seconds (00:11:34) AES_GCM_16 Bytes-In: 5,376 (5 KiB) fd00::/64 Remote: cd70616cfd01::/64 Life: 1495 seconds (00:24:55) Packets-In: 64 Install: 2106 seconds (00:35:06)IPComp: noneBytes-Out: 13,768 (13 KiB) Packets-Out: 105 As far as *I* can tell, it looks fine. The remote and local subnets are fine (match my LAN subnets). Of course I have checked that I see the same thing reversed on the other end. On firewall rules, IPSEC interface, I currently have two pass-through rules, one for IPv4 and one for IPv6. The other rules needed are supposedly added by pfSense (without displaying them) as System / Advanced / Firewall - Disabled auto-added VPN rules is NOT checked. But are those auto-added suitable for passing both IPv4 and IPv6 inside the tunnel? Phase1 is setup using IPv4 / IKEv2. One Phase2 is tunnel IPv4 and the other is tunnel IPv6. One end is 2.3-REL, the other one is 2.2.2-REL (which I cannot upgrade for the time being). Would someone have an idea, based on their own experience with IPsec and both IPv4+IPv6, of what wrong in my setup to look for? So much thanks for the help, -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPsec: tunneling both IPv4 and IPv6 between two sites
Sorry for having asked this question. While I had tried to find the answer before posting, I finally found the answer seconds later. https://doc.pfsense.org/index.php/IPv6_and_VPNs "Currently IPv6 with IPsec is functional, but traffic cannot be mixed families in a tunnel. Meaning, IPv6 traffic can only be carried inside a tunnel which has IPv6 endpoints, and IPv4 traffic can only be carried over a tunnel using IPv4 endpoints. A single tunnel cannot carry both types of traffic." So be it. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 30 avr. 2016 à 12:54, Olivier Mascia <o...@integral.be> a écrit : > > Dear all, > > How about tunneling both IPv4 and IPv6 between two sites using IPsec? > Does this necessarily involves two phase1/phase2 or can one phase1 (v4 for > instance) be used with two phase2 (one v4, one v6)? > > I still have a lot to learn about IPsec. > > -- > Meilleures salutations, Met vriendelijke groeten, Best Regards, > Olivier Mascia, integral.be/om > > > ___ > 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] IPsec: tunneling both IPv4 and IPv6 between two sites
Dear all, How about tunneling both IPv4 and IPv6 between two sites using IPsec? Does this necessarily involves two phase1/phase2 or can one phase1 (v4 for instance) be used with two phase2 (one v4, one v6)? I still have a lot to learn about IPsec. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPsec - how to assess encryption is active?
Thanks Jim for this explanation. It clarifies a lot of things. Including, if I followed you correctly, that I did the right thing for now to switch to IPsec using AES-GCM, mostly blindly following the recommendations of the latest pfSense book (January 2016). -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia (from mobile device), integral.be/om > Le 29 avr. 2016 à 20:45, Jim Thompson <j...@netgate.com> a écrit : > > Because OpenVPN uses tun/tap, and there is a HUGE amount of overhead in that. > >“HUGGGEEE!” — Donald J. Trump > > The statement "On a modern intel system, the intel chip itself (or AMD) has > AES128 or better implemented in hardware. “ is incorrect. Modern Intel / > AMD parts have instructions that can accelerate the AES algorithm. > >• AESENC. This instruction performs a single round of encryption. The > instruction combines the four steps of the AES algorithm - ShiftRows, > SubBytes, MixColumns & AddRoundKey into a single instruction. >• AESENCLAST. Instruction for the last round of encryption. Combines the > ShiftRows, SubBytes, & AddRoundKey steps into one instruction. >• AESDEC. Instruction for a single round of decryption. This combines the > four steps of AES - InvShiftRows, InvSubBytes, InvMixColumns, AddRoundKey > into a single instruction >• AESDECLAST. Performs last round of decryption. It combines InvShiftRows, > InvSubBytes, AddRoundKey into one instruction. >• AESKEYGENASSIST is used for generating the round keys used for > encryption. >• AESIMC is used for converting the encryption round keys to a form usable > for decryption using the Equivalent Inverse Cipher. >• PCLMULQDQ is used for carryless multiply (CLMUL), which is used in > AES-GCM. > > The other issue is that encryption without a HMAC is all but worthless. (It > increases privacy, but not security.) Typically the HMAC involves an entire > second pass over the packet, and this isn’t accelerated. Very new Intel CPUs > have some acceleration support for SHA (SHA1, SHA256, etc), but it’s not > anything like hardware offload. > > This is why AEAD modes (such as AES-GCM) exist, and why we added support for > AES-GCM to IPsec for FreeBSD.OpenVPN is supposed to get support for AEAD > (GCM) in OpenVPN 2.4. > But that’s not going to solve the issue with the overhead of tun/tap. That’s > going to take actual work, putting OpenVPN over netmap, or DPDK, or something > like that. > > Versus AES-NI, actual hardware offload, using something like Intel > QuickAssist, is much (much) faster. We’ve run nearly 20Gbps using a CPIC > card. This tweet says “10Gbps”, but using two tunnels, we got it to 17Gbps > https://twitter.com/gonzopancho/status/703677820694720512 with an otherwise > unmodified system. That was AES-CBC-128 + HMAC-SHA1, IIRC. Yes, QAT will > accelerate SHA. That’s not going to happen on FreeBSD without a lot of > work, because the IPsec stack on FreeBSD needs….. a lot of work. (It’s a bit > of a hot mess, see upcoming BSDcan talk. > http://www.bsdcan.org/2016/schedule/events/727.en.html) > > net-net: we accelerated IPsec using AES-GCM (leveraging AES-NI) first, > because that was going to be the most benefit. > > Jim > (Yes, we tried OpenVPN with QAT, tun/tap is the blocker here. See above, or > my repeated statements on this list, the forum, and elsewhere.) > > >> On Apr 29, 2016, at 1:10 PM, Olivier Mascia <o...@integral.be> wrote: >> >> Indeed. >> Why didn't the OpenVPN tunnel show me that level of perf, despite settings >> for using hardware acceleration, is another story, but I'm happy with the >> IPsec results and will stick to that on this link. >> >> Thanks for having confirmed me I hadn't fallen in a rabbit hole. >> :) >> >> -- >> Meilleures salutations, Met vriendelijke groeten, Best Regards, >> Olivier Mascia, integral.be/om >> >>> Le 29 avr. 2016 à 19:58, ED Fochler <soek...@liquidbinary.com> a écrit : >>> >>> On a modern intel system, the intel chip itself (or AMD) has AES128 or >>> better implemented in hardware. I get ~700Mb on sftp on my macbook air >>> 2012 like that, so those numbers are exactly where I’d expect the CPU to be >>> maxed out doing AES128 or AES256 encryption. That’s what hardware >>> acceleration feels like. You should see the CPU (or one core at least) on >>> the IPSec tunnel ends being fully occupied at that throughput. >>> >>>ED. >>> >>> >>>> On 2016, Apr 29, at 1:52 PM, Olivier Mascia <o...@integral.be> wrote:
Re: [pfSense] IPsec - how to assess encryption is active?
Indeed. Why didn't the OpenVPN tunnel show me that level of perf, despite settings for using hardware acceleration, is another story, but I'm happy with the IPsec results and will stick to that on this link. Thanks for having confirmed me I hadn't fallen in a rabbit hole. :) -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 29 avr. 2016 à 19:58, ED Fochler <soek...@liquidbinary.com> a écrit : > > On a modern intel system, the intel chip itself (or AMD) has AES128 or better > implemented in hardware. I get ~700Mb on sftp on my macbook air 2012 like > that, so those numbers are exactly where I’d expect the CPU to be maxed out > doing AES128 or AES256 encryption. That’s what hardware acceleration feels > like. You should see the CPU (or one core at least) on the IPSec tunnel ends > being fully occupied at that throughput. > > ED. > > >> On 2016, Apr 29, at 1:52 PM, Olivier Mascia <o...@integral.be> wrote: >> >> Seeing throughput I did not expected with an IPsec tunnel compared to what I >> was seeing using OpenVPN (which I always used up to the perf discrepancy I >> discovered today on a new link), I wonder if it really encrypts anything. >> >> Phase 1 is set for AES256, SHA256 DH group 2. >> Phase 2 is set for ESP AES256-GCM 128 bits and SHA256. >> >> No other encryption / hash is checked as alternatives on Phase 2. >> >> I'd say I'm good to go that way, but I'm driving between 500 and 750 Mbps >> through the tunnel (transfer rate of ~45 to ~80 MB/sec in Windows File >> explorer between filesystems on each side of the tunnel), and I quite >> couldn't believe it. >> >> Could something be wrong? >> >> -- >> Meilleures salutations, Met vriendelijke groeten, Best Regards, >> Olivier Mascia, integral.be/om >> >> >> ___ >> 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
[pfSense] IPsec - how to assess encryption is active?
Seeing throughput I did not expected with an IPsec tunnel compared to what I was seeing using OpenVPN (which I always used up to the perf discrepancy I discovered today on a new link), I wonder if it really encrypts anything. Phase 1 is set for AES256, SHA256 DH group 2. Phase 2 is set for ESP AES256-GCM 128 bits and SHA256. No other encryption / hash is checked as alternatives on Phase 2. I'd say I'm good to go that way, but I'm driving between 500 and 750 Mbps through the tunnel (transfer rate of ~45 to ~80 MB/sec in Windows File explorer between filesystems on each side of the tunnel), and I quite couldn't believe it. Could something be wrong? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] Debugging a bi-directional speed discrepancy through an OpenVPN tunnel --> IPsec
Having tried a large number of things, it looks like an UDP receive issue on (B). Connecting the tunnel through TCP transport instead of UDP brings the throughput around 75 Mbps in both directions. Over UDP, it is a good ~300 Mbps in one direction and a mere ~15 Mbps in the opposite (A to B). That means in the direction being problematic, throughput is actually higher over TCP than UDP, which of course is counterintuitive. So I decided to test an IPsec tunnel instead, in order to rule out OpenVPN specific issues... I never used IPsec tunnel before but could establish one rather simply following the book recommended settings and... I'm quite surprised at the throughput I get (very high). To the point that I'm wondering if it's really encrypting anything! I'm leaving this (self) thread here and starting another one about IPsec. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 29 avr. 2016 à 11:45, Olivier Mascia <o...@integral.be> a écrit : > > Dear all, > > In case some of you would have an idea what to look for and adjust, here is a > strange issue I have between two end-points of an OpenVPN tunnel. Both sites > each have >= 1 Gbps connectivity to Internet. > > One site (A) is still using pfSense 2.2.2-REL on 'Intel(R) Xeon(R) CPU E31270 > @ 3.40GHz, 4 CPUs: 1 package(s) x 4 core(s)' (hyper-threading turned off). > This is a nanobsd configuration. > > New site (B) is using pfSense 2.3-REL on 'Intel(R) Xeon(R) CPU E5-2690 v2 @ > 3.00GHz, 2 CPUs: 1 package(s) x 2 core(s)' (this is actually a VM). This is > full setup. > > I have an OpenVPN tunnel between both (peer to peer, shared key, AES-128-CBC, > SHA1). > > Using the tunnel for file transfers between both sites, I peak over 350 Mbps > inside the tunnel from (B) to (A). But from (A) to (B) I peak at ~14 Mbps. > Which looks really strange. I'm wondering where is the culprit: sending from > (A), or receiving on (B). > > Using iperf3 with 3 to 5 threads, outside of the VPN, but through both > pfSense anyway, I consistently get 800 to 900 Mbps, either (A) to (B) or (B) > to (A). It is only within the OpenVPN tunnel that I can see the asymmetric > speed. And it puzzles me. > > If you have any kind of idea about what to look for, I'll take whatever you > give me. > Thanks for reading me, > -- > Meilleures salutations, Met vriendelijke groeten, Best Regards, > Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Debugging a bi-directional speed discrepancy through an OpenVPN tunnel
Dear all, In case some of you would have an idea what to look for and adjust, here is a strange issue I have between two end-points of an OpenVPN tunnel. Both sites each have >= 1 Gbps connectivity to Internet. One site (A) is still using pfSense 2.2.2-REL on 'Intel(R) Xeon(R) CPU E31270 @ 3.40GHz, 4 CPUs: 1 package(s) x 4 core(s)' (hyper-threading turned off). This is a nanobsd configuration. New site (B) is using pfSense 2.3-REL on 'Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz, 2 CPUs: 1 package(s) x 2 core(s)' (this is actually a VM). This is full setup. I have an OpenVPN tunnel between both (peer to peer, shared key, AES-128-CBC, SHA1). Using the tunnel for file transfers between both sites, I peak over 350 Mbps inside the tunnel from (B) to (A). But from (A) to (B) I peak at ~14 Mbps. Which looks really strange. I'm wondering where is the culprit: sending from (A), or receiving on (B). Using iperf3 with 3 to 5 threads, outside of the VPN, but through both pfSense anyway, I consistently get 800 to 900 Mbps, either (A) to (B) or (B) to (A). It is only within the OpenVPN tunnel that I can see the asymmetric speed. And it puzzles me. If you have any kind of idea about what to look for, I'll take whatever you give me. Thanks for reading me, -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] GUI /firewall_virtual_ip.php - reordering them?
Could this be listed as an enhancement request for the GUI editing of the virtual IPs ? Some ability to reorder them, at least manually (like rules for instance)? When you have a good number of IP aliases, it would help grasp the big picture in a glimpse to check wether something is not right or missing. Or have them automatically ordered, first by Type, then Interface and then by IP (that's just how *I* would order them by hand). -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] CARP and both IPv4 and IPv6: do they live together?
> Le 28 avr. 2016 à 00:28, Chris Buechler <c...@pfsense.com> a écrit : > >> >> Sure, I'm not helped by the transit provider which does not actually route >> the /56 prefix to my link (savages!) but merely 'switch' it to me, expecting >> ARP/NDP from >> each of my connected devices, and me using one dedicated IP of the block as >> gateway. > > That's a mess, make them fix that. It's ugly at a minimum, and will > make many typical uses of IPv6 impossible. No competent ISP will > assign your /56 directly to their router in its entirety. > > >> Until I thought of the RA!! I have set RA on WAN to Router Only over my >> defined WAN IPv6 CARP > > You don't want RAs enabled on WAN. Your ISP's router is the one > sending RAs in that case (if anything is). You're advertising yourself > on that network as a router for other hosts, which is never what you > want on your WAN. Thanks a lot Chris for your answer. The supplier is a provider of turn-key dedicated hardware + ESXi/vSphere infrastructure, all setup in their own private data centers. Takes the hardware provisioning and servicing out of our hands. We experiment with their offering as an alternative way of implementing our presence in data centers. In this context, where in the end we only have access to VMs that we define as we see fit, we decided to build two pfSense VMs, in HA setup, with vSphere rule for keeping them separated on distinct physical hosts. (For other needs than this one, we use hardware purchased from pfSense website by the way, nice boxes, thanks!!). True, their way to provide IP blocks (either IPv4 or IPv6) is a mess (assigned at their routers, and merely switched to us). We work with them to change that asap. I second your opinion on RA on WAN. Yet, I turn it off, I loose IPv6 connectivity, while turned on as described, I'm only left with the WAN IPv6 CARP not reachable, but trafic is fine toward inner equipment. That is completely unusual, bizarre, whatever, but until they properly route trafic to me, I'm happy with what I now currently have. :) The HA setup looks fine now, well-tuned and I could simulate the loss of one host and see the traffic persist nicely through the secondary pfSense. Very nice. Thanks again, -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] CARP and both IPv4 and IPv6: do they live together?
> Le 26 avr. 2016 à 00:37, Olivier Mascia <o...@integral.be> a écrit : > > It looks like as soon as I bring IPv6 to the party, my secondary starts > thinking it's MASTER instead of BACKUP. Sometimes on the WAN side, sometimes > on the LAN, sometimes both. Quite hard to describe, I'm still trying to > build up a reproducible test case on my 2.3 cluster. So out of the blue, are > there known-bugs or other kind of difficulties in having H.A. along with IPv4 > and IPv6? This stabilized after reboots. Sure, I'm not helped by the transit provider which does not actually route the /56 prefix to my link (savages!) but merely 'switch' it to me, expecting ARP/NDP from each of my connected devices, and me using one dedicated IP of the block as gateway. Without HA and CARP I have (this was tested fine) to IP Alias (on the WAN) all IPv6 I need on the LAN, while using some fd00::/64 like on the LAN side and NPT. Tricky, but works. Now with HA/CARP in the game, I had NO issues communicating with any of both pfSense on their public IPv6 (one is on ::2 and the other on ::3). But I can't get any answer from ::1 when defining it as CARP VIP over the WAN. Nor could I get any answer from some inner host (let's say on fd00::5 corresponding to w.x.y.z::5) by using an IP Alias on top of the WAN (v6) CARP VIP (which itself didn't answer, as I wrote above)... Until I thought of the RA!! I have set RA on WAN to Router Only over my defined WAN IPv6 CARP, instead of the WAN as default... and I have got connectivity with inner hosts. Yet I don't have any connectivity with the WAN IPv6 CARP itself. Getting me a bit puzzled to say the least. For now I will simply delist my record for the WAN side of the cluster of routers. So that my named-based VPNs and other kind of accesses only talk IPv4 to the VIPv4. As long as trafic with inner hosts can be established properly, I'm already quite happy. If someone has had similar experience, I'd be happy to read about it, when you have some minutes and the will to share. Thanks! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] CARP and both IPv4 and IPv6: do they live together?
It looks like as soon as I bring IPv6 to the party, my secondary starts thinking it's MASTER instead of BACKUP. Sometimes on the WAN side, sometimes on the LAN, sometimes both. Quite hard to describe, I'm still trying to build up a reproducible test case on my 2.3 cluster. So out of the blue, are there known-bugs or other kind of difficulties in having H.A. along with IPv4 and IPv6? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] HA and OpenVPN
> Le 25 avr. 2016 à 20:04, Travis Hansen <travisghan...@yahoo.com> a écrit : > Did you select the carp IP as the 'interface' in the openvpn server config? > or do you just have WAN selected? > Le 25 avr. 2016 à 20:21, Brady, Mike <mike.br...@devnull.net.nz> a écrit : > Did you change the OpenVPN configured Interface to be the VIP rather than the > WAN? No, I didn't. :( That was the stupid mistake I was looking after. Thank you Brady and Travis. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] HA and OpenVPN
> Le 25 avr. 2016 à 20:04, Travis Hansen <travisghan...@yahoo.com> a écrit : > > Did you select the carp IP as the 'interface' in the openvpn server config? > or do you just have WAN selected? Hmm... I'm on the move since my previous post, but this seems obvious enough for me having made that mistake. :) I'll check back later today, but chances are the fault is there. Thanks!! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] HA and OpenVPN
Hello, I now have a HA cluster of 2 pfSense boxes pretty much well setup, everything working as expected, excepted one thing. Connecting to a remote access OpenVPN server on the WAN CARP IP fails here: Apr 25 19:29:36: Vérification du statut d'accessibilité de la connexion ... Apr 25 19:29:36: La connexion est accessible. Tentative de démarrage de la connexion. Apr 25 19:29:38: OpenVPN 2.3.10 x86_64-apple-darwin [SSL (OpenSSL)] [LZO] [PKCS11] [MH] [IPv6] built on Mar 2 2016 Apr 25 19:29:38: library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.09 Apr 25 19:30:00: Control Channel Authentication: using '/var/folders/zz/zyxvpxvq6csfxvn_n0/T/connection.5wkLkh/ta.key' as a OpenVPN static key file Apr 25 19:30:00: UDPv4 link local (bound): [undef] Apr 25 19:30:00: UDPv4 link remote: [AF_INET]w.x.y.z:1194 ... and after a timeout: Apr 25 19:31:00: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) Apr 25 19:31:00: TLS Error: TLS handshake failed Apr 25 19:31:00: SIGUSR1[soft,tls-error] received, process restarting Apr 25 19:31:01: UDPv4 link local (bound): [undef] Apr 25 19:31:01: UDPv4 link remote: [AF_INET]w.x.y.z:1194 ... When connecting to either box non CARP WAN address, ie w.x.y.z+1 or z+2 in this example, it works. Even accepting UDP OpenVPN on destination Any does not fix it. So this does not look like a filter rule issue. Is there something particular to take into account regarding UDP traffic toward the WAN CARP IP or something specific regarding OpenVPN? I can live with having to establish VPN to the primary box and change it should it fail (this is for maintenance only of the resources behind the firewall), but I find it strange it does not work on the CARP IP. What obvious thing did I miss? -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] XMLRPC sync - user/password limitations? And a possible bug regarding 'admin' user
> Le 25 avr. 2016 à 00:34, Olivier Mascia <o...@integral.be> a écrit : > > /xmlrpc.php: webConfigurator authentication error for 'admin' from 172.16.0.2 > during sync settings. > > The user setup on the primary firewall is not 'admin'. So if the secondary > attempts to validate the password against 'admin', that could be the issue. Just re-read once again the Book. OK, I read too fast on those two lines: " Set Remote System Username to admin. Note: This must always be admin, no other user will work! " Took them for default example values, while the small comment says this is not an exercise. Why is there a box to enter the remote system username, when it is useless and has to be 'admin' anyway?... :) What privilege limitations can be made to user 'admin', and still get it to work for xmlrpc? I don't like keeping a user named admin, no matter how strong the password might be, so I usually disable it and create a new one with all the required rights for full administration. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] XMLRPC sync - user/password limitations? And a possible bug regarding 'admin' user
More info. There indeed must be something wrong with the setting up of the couple user/password used by primary to update secondary config. At least the following log message found on the secondary is suspect: /xmlrpc.php: webConfigurator authentication error for 'admin' from 172.16.0.2 during sync settings. The user setup on the primary firewall is not 'admin'. So if the secondary attempts to validate the password against 'admin', that could be the issue. I will try by re-opening access for the admin user (on both for good measure), but would love not to have to do that in the future. Or... what exact minimalist access rights are needed for the default 'admin' user to be able to receive configuration updates through XMLRPC? I could restrict that 'admin' user to only that, as a temporary workaround. Though, it looks like there is another issue. To test get sure you have a second user with full admin rights for backup in case it works this works for you, while it fails on me. Edit the 'admin' user, remove all pages access and membership in the admins groups. Logoff, logon using admin. You have full access to any part of the configuration. No restrictions apply. This is 2.3-REL, I think I did not write that. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > Le 24 avr. 2016 à 23:40, Olivier Mascia <o...@integral.be> a écrit : > > Hello, > > Are there limitations (password length for instance, case sensitivity issues > on the username) on the user/password used on system_hasync.php page to reach > the peer? > > I started setting this up while the peer (secondary) still had admin as > username (fresh after setup), and a long complex password. The configuration > synchronized, but with a warning about authentication. I first thought: OK > this is expected because the primary I'm copying has 'admin' disabled (not > allowed to login) and another user name is used as the real admin. I could > understand as soon as users had been synced there might be an authentication > error, afterwards. > > So I updated on system_hasync.php, but now I keep getting "An authentication > failure occurred while trying to access https://;. And the newer settings > just don't sync. > > Checked username and password 3 times, looks good while entering it in > system_hasync.php and is fine for logging interactively or at the console. > > The alternate username has caps in the name. And the password is longer than > usual, but reasonable (>20 chars and <25 chars). > > I'm aware of this: "XMLRPC sync is currently only supported over connections > using the same protocol and port as this system - make sure the remote > system's port and protocol are set accordingly!" and took care that both are > identical. > > A bit puzzled. > -- > Meilleures salutations, Met vriendelijke groeten, Best Regards, > Olivier Mascia, integral.be/om > > > ___ > 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] HA: XMLRPC sync - user/password limitations?
Hello, Are there limitations (password length for instance, case sensitivity issues on the username) on the user/password used on system_hasync.php page to reach the peer? I started setting this up while the peer (secondary) still had admin as username (fresh after setup), and a long complex password. The configuration synchronized, but with a warning about authentication. I first thought: OK this is expected because the primary I'm copying has 'admin' disabled (not allowed to login) and another user name is used as the real admin. I could understand as soon as users had been synced there might be an authentication error, afterwards. So I updated on system_hasync.php, but now I keep getting "An authentication failure occurred while trying to access https://;. And the newer settings just don't sync. Checked username and password 3 times, looks good while entering it in system_hasync.php and is fine for logging interactively or at the console. The alternate username has caps in the name. And the password is longer than usual, but reasonable (>20 chars and <25 chars). I'm aware of this: "XMLRPC sync is currently only supported over connections using the same protocol and port as this system - make sure the remote system's port and protocol are set accordingly!" and took care that both are identical. A bit puzzled. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPV6 WAN/LAN routing
> Le 21 avr. 2016 à 01:15, Chris Buechler <c...@pfsense.com> a écrit : > >> Or are these solicitations unexpected (the upstream provider has a setup >> issue regarding my /56 network)? > > They're unexpected. That means your ISP isn't routing that network to > you as they must be for it to be usable inside your network. ISP > issue. Thanks, that's clear. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPV6 WAN/LAN routing
>> I must be tired or something but I have a strange thing with IPv6 on a new >> box I just setup. >> >> Have a x:y:z:d800::/56 routed to me. >> WAN is static IPv6 on x:y:z:d800::1/64, gateway is >> x:y:z:d800::::: (not a nice one but that is what they gave >> me). >> LAN is static IPv6 on x:y:z:d801::1/64, no gateway as usual for LAN >> interface. >> >> From a host on the LAN side, at x:y:z:d801::100 (or any other), I can reach >> pf LAN interface on x:y:z:d801::1, I can also reach pf WAN interface on >> x:y:z:d800::1, but I can't get a packet to go further. >> >> Yet, from pf itself, I can reach (ping for instance) www.google.com (IPv6) >> from WAN interface, but not from LAN interface. >> >> I would have thought "ok I miss a pass rule on the LAN interface", but there >> is one. This by far is not my first pfSense box, and they all have various >> kind of IPv6 links. Not that I couldn't be awfully wrong somewhere. So what >> obvious detail am I overlooking here? If you have any idea? >> >> This is 2.3-RELEASE by the way. Other boxes (on other networks) are still >> 2.2.x. >From some packet captures, something caught my eye, but I'm not sure if this >an issue in the hands of my upstream provider or something local to my pfSense >box. Here are two captures on the WAN of pfSense. First one, I'm pinging the WAN ip from a very remote location. One clearly see 4 echo requests and 4 echo replies. 23:32:47.466402 IP6 2a02:578:85a0:101:5cf:576b:9daf:77ca > x:y:z:d800::1: ICMP6, echo request, seq 73, length 40 23:32:47.466455 IP6 x:y:z:d800::1 > 2a02:578:85a0:101:5cf:576b:9daf:77ca: ICMP6, echo reply, seq 73, length 40 23:32:48.476917 IP6 2a02:578:85a0:101:5cf:576b:9daf:77ca > x:y:z:d800::1: ICMP6, echo request, seq 74, length 40 23:32:48.476933 IP6 x:y:z:d800::1 > 2a02:578:85a0:101:5cf:576b:9daf:77ca: ICMP6, echo reply, seq 74, length 40 23:32:49.491979 IP6 2a02:578:85a0:101:5cf:576b:9daf:77ca > x:y:z:d800::1: ICMP6, echo request, seq 75, length 40 23:32:49.492019 IP6 x:y:z:d800::1 > 2a02:578:85a0:101:5cf:576b:9daf:77ca: ICMP6, echo reply, seq 75, length 40 23:32:50.507963 IP6 2a02:578:85a0:101:5cf:576b:9daf:77ca > x:y:z:d800::1: ICMP6, echo request, seq 76, length 40 23:32:50.507987 IP6 x:y:z:d800::1 > 2a02:578:85a0:101:5cf:576b:9daf:77ca: ICMP6, echo reply, seq 76, length 40 This time, I'm pinging the LAN ip (x:y:z:d801::1) from the same remote location. No echo requests, only neighbor solicitations from a link-local address fe80...dc78, which I could trace as the upstream router, to ff02::1:ff00:1. But no advertisements on return from the pfSense box. What looks wrong here? The absence of advertisements from pfSense box on these solicitations (I would have an issue with my pfSense setup)? Or are these solicitations unexpected (the upstream provider has a setup issue regarding my /56 network)? 23:35:41.814361 IP6 fe80::aa0c:dff:fe44:dc78 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has x:y:z:d801::1, length 32 23:35:42.815472 IP6 fe80::aa0c:dff:fe44:dc78 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has x:y:z:d801::1, length 32 23:35:51.411220 IP6 fe80::aa0c:dff:fe44:dc78 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has x:y:z:d801::1, length 32 If someone with (easily) much better inner knowledge of IPv6 specifics (than me) has an idea... Thanks!! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] IPV6 WAN/LAN routing
> Le 20 avr. 2016 à 18:53, Steve Yates <st...@teamits.com> a écrit : > > To rule out any missing firewall rules, on Status: System logs: Settings, > check "Log packets matched from the default block rules put in the ruleset" > and see if it starts logging your pings from the LAN. > > -- > > Steve Yates > ITS, Inc. Thanks Steve, No the default rules don't catch any of these packets. Activating the logging on my wide LAN allow rule, I can indeed even see them OK as in: Default allow LAN IPv6 to any rule (10102)[x:y:z:d801::130] [2a00:1450:4007:808::2003]ICMPv6 -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om > > > -Original Message- > From: List [mailto:list-boun...@lists.pfsense.org] On Behalf Of Olivier Mascia > Sent: Wednesday, April 20, 2016 11:39 AM > To: pfSense Support and Discussion Mailing List <list@lists.pfsense.org> > Subject: [pfSense] IPV6 WAN/LAN routing > > Dear all, > > I must be tired or something but I have a strange thing with IPv6 on a new > box I just setup. > > Have a x:y:z:d800::/56 routed to me. > WAN is static IPv6 on x:y:z:d800::1/64, gateway is > x:y:z:d800::::: (not a nice one but that is what they gave > me). > LAN is static IPv6 on x:y:z:d801::1/64, no gateway as usual for LAN interface. > > From a host on the LAN side, at x:y:z:d801::100 (or any other), I can reach > pf LAN interface on x:y:z:d801::1, I can also reach pf WAN interface on > x:y:z:d800::1, but I can't get a packet to go further. > > Yet, from pf itself, I can reach (ping for instance) www.google.com (IPv6) > from WAN interface, but not from LAN interface. > > I would have thought "ok I miss a pass rule on the LAN interface", but there > is one. This by far is not my first pfSense box, and they all have various > kind of IPv6 links. Not that I couldn't be awfully wrong somewhere. So what > obvious detail am I overlooking here? If you have any idea? > > This is 2.3-RELEASE by the way. Other boxes (on other networks) are still > 2.2.x. > > -- > Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier > Mascia, integral.be/om > ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] IPV6 WAN/LAN routing
Dear all, I must be tired or something but I have a strange thing with IPv6 on a new box I just setup. Have a x:y:z:d800::/56 routed to me. WAN is static IPv6 on x:y:z:d800::1/64, gateway is x:y:z:d800::::: (not a nice one but that is what they gave me). LAN is static IPv6 on x:y:z:d801::1/64, no gateway as usual for LAN interface. >From a host on the LAN side, at x:y:z:d801::100 (or any other), I can reach pf >LAN interface on x:y:z:d801::1, I can also reach pf WAN interface on >x:y:z:d800::1, but I can't get a packet to go further. Yet, from pf itself, I can reach (ping for instance) www.google.com (IPv6) from WAN interface, but not from LAN interface. I would have thought "ok I miss a pass rule on the LAN interface", but there is one. This by far is not my first pfSense box, and they all have various kind of IPv6 links. Not that I couldn't be awfully wrong somewhere. So what obvious detail am I overlooking here? If you have any idea? This is 2.3-RELEASE by the way. Other boxes (on other networks) are still 2.2.x. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] pfSense on vmware ESXi 6.0
> Le 15 avr. 2016 à 12:33, Mike Montgomery <onezero1010...@gmail.com> a écrit : > > I'm not positive, but I was always under the impression to only use the VX > net cards for Windows OS, I have always used the e1000 for Linux/pfsense. > Run several firewalls in esxi 5.1 and never any issues. Never needed tweak > anything at all, except for when I tried to do carp. I'll arrange some different tests later, but for now, VMXNET3 WAN, VMXNET3 LAN, the hosts have only 1 Gbps ethernet, I get ~850 Mbps in both directions through 'speedtest.net' (from a LAN windows server box) to some servers I know well. That's about only 15% less than wire-speed, even though there is the expected overhead of the virtualization. Not bad. Is it stable for long-term? Only time will tell me, but it looks steady for now. For fault-tolerance, I tend to think that CARP and dual virtualized pfSense (with affinity on different hosts), would be lighter than using vmware Fault Tolerance. That will be next week tests. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Status - Queues: is that a moving average on the last X minutes?
It looks to me the data displayed by Status - Queues is a kind of average over some time frame (maybe 1 minute, maybe more, don't know). Could this be shorter? Could the data be reported half-live, for instance one sample every 5 seconds with the data of those last 5 seconds, not taking into account any past traffic? When trying to assess the effectiveness of some settings, getting a more instantaneous queues usage might be more useful. Well, I think so. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] pfSense on vmware ESXi 6.0
Hello, I'm looking for advices and best practices when running pfSense (this time it will be 2.3) in a vmware VM. I'm offered to move some resources to a virtual datacenter made of dedicated hardware hosts in clusters, running ESXi 6.0 and vSphere. I have access to such an infrastructure for the next 3 weeks. I have used pfSense in a number of devices and hosts, but never inside a VM, except for experimenting with configurations of pfSense itself. I could build up a pfSense 2.3 VM without real difficulties. Installing the integration tools was easy through the included package. Now, what are the pitfalls I should look for? Any shared vmware experience from you will undoubtedly help fine tuning this. For now the pfSense VM I configured has these resources: OS declared to vSphere is FreeBSD 10.3 64 bits, 1 socket, 2 cores, 2 GHz reserved, 2 GB RAM, 10 GB HD, 2 network adapters. I'm generally resources-conservative but I could allow much more if it makes sense. For these adapters I have the choice between E1000, VMXNET 2, VMXNET 3. I have set them for VMXNET 3 but without background about this being the right-thing-to-do or not. At least it seems to work but I still need to stress test the VM (traffic-wise) a little bit. Are there tunings inside pfSense which you could recommend / not live without, based on your experience inside vmware virtual machines? Network interfaces settings? All are set for their default pfSense values, which means TCP segmentation offloading and large receive offloading are disabled. Would it make sense to enable those? Thanks for any insight you might want to share. -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.3.1 -> 2.3 ?
> Le 14 avr. 2016 à 02:55, Chris Buechler <c...@pfsense.com> a écrit : > >> Hello, >> >> I had a 2.3 RC installed and (mistakenly) let it auto-upgrade some hours >> ago. It went straight to some 2.3.1 DEV instead of 2.3 REL as I expected >> (my mistake). Is there any appropriate way to come back to 2.3 REL other >> than rebuilding it from scratch? >> > > Yes, check here. > https://forum.pfsense.org/index.php?topic=109690.0 Worked perfect. I'm back on: " 2.3-RELEASE (amd64) built on Mon Apr 11 18:10:34 CDT 2016 FreeBSD 10.3-RELEASE The system is on the latest version. " Thanks! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] vmware tools
Reading this: https://doc.pfsense.org/index.php/Open_VM_Tools_package after package installation and reboot, ps uxawww | grep vmware gives me this output which differs from the doc.pfsense.org article: root55265 0.0 0.2 17000 2516 - S12:04PM 0:00.00 sh -c ps uxawww | grep vmware 2>&1 root55414 0.0 0.2 18740 2248 - S12:04PM 0:00.00 grep vmware root84296 0.0 0.8 103460 8236 - S11:37AM 0:00.34 /usr/local/bin/vmtoolsd -c /usr/local/share/vmware-tools/tools.conf -p /usr/local/lib/open-vm-tools/plugins/vmsvc Does /usr/local/bin/vmtoolsd here correspond to /usr/local/sbin/vmware-guestd which the article shows? It says "As long as vmware-guestd is shown in the output, it is working." Here I have vmtoolsd, not vmware-guestd. Merely a matter of older/newer version of this stuff between the article and 2.3.x? Thanks! -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] 2.3.1 -> 2.3 ?
Hello, I had a 2.3 RC installed and (mistakenly) let it auto-upgrade some hours ago. It went straight to some 2.3.1 DEV instead of 2.3 REL as I expected (my mistake). Is there any appropriate way to come back to 2.3 REL other than rebuilding it from scratch? (I don't have a problem rebuilding anew, but I'm merely testing this in a vm in a dedicated cloud offering which I'm test-driving for 3 weeks, and I don't seem to have a way to upload the iso first for a local installation. I have to remotely mount the iso and though this works, it takes obviously much longer time to proceed with the install. So if I could spare some time for other things, it's be nice even if not 'perfect' way to proceed.) Thanks, -- Meilleures salutations, Met vriendelijke groeten, Best Regards, Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN and TOTP?
> Le 12 oct. 2015 à 23:06, Nikos Zaharioudakis <nza...@gmail.com> a écrit : > > To my knowledge OpenVPN comes with LDAP support. > > Check on https://www.freeipa.org > Their recent editions provide one time passwords that can be produced with > a FreeOTP mobile app. > > Hope this solves your issue. > > Nikos Thanks Nikos, this goes along the same kind of lines as what John suggested, and both are very good reminders or existing solution paths. I will have some time free in the coming days to tests all these paths. -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] github.com/google/google-authenticator/ on pfSense 2.2x
Hello, Could someone give me pointers on environment needed for me to experiment with building Google Authenticator PAM module for pfSense 2.2.4 (amd x64) ? The code I'm talking about is here: git clone https://github.com/google/google-authenticator/ I'm only concerned with the libpam sub-directory. I can build it and use it successfully with freeradius, on a LinuxMint 17.2 environment. And can get pfSense to refer to that box, successfully. Though I would like to experiment the same using the freeradius available as a package for pfSense and adding this PAM on it. I guess I first need to setup a development environment en BSD, then I should be flying? Are there some recommended guidelines for porting and debugging (if needed) things to the specific BSD environment of pfSense 2.2x? -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] OpenVPN and TOTP?
> Le 6 oct. 2015 à 01:09, Jon Gerdes <gerd...@blueloop.net> a écrit : > > OVPN can use RADIUS. So now you need to research wiring TOTP up to > RADIUS but that will be a lot easier because there will be lots of > vendors with pre cast offerings and no doubt a slew of free software > alternatives. > > If you have Win 2008+ which is pretty likely then that has a lot built > in already. Wack a NPS role on a DC and follow one of the howtos on > the wiki to get RADIUS working with pfSense and OpenVPN and then fold > in TOTP afterwards. You also have Free Radius to play with. pfSense > has a package for that which might be worth looking into. > > Cheers > Jon Thanks a lot John. Lots of good ideas here around RADIUS. I completely overlooked that OpenVPN could use it. Will investigate all these options. -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] OpenVPN and TOTP?
Dear all, Have you heard of any support (add-on?) for time based one time passwords support in OpenVPN? Along the lines of RFC6238 so it could be used with Google Authenticator, Microsoft Authenticator, and the countless alike mobile Apps. Would be interesting to get users to use their credentials plus a TOTP when connecting to remote access OpenVPN setups. In addition (or not) of certificates. On the same train, I'd really like our admins to have to use a TOTP in addition to login/password when connecting to pfSense for administration. -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] DHCPv6 - Dynamic DNS
Dear all, Is it appropriate / expected that configuring the section Dynamic DNS on the services_dhcpv6.php page requires an IPv4 as "the primary domain name server IP address for the dynamic domain name"? I don't know yet if this work or not, but I had to enter the IPv4 address of my DNS server for the page to accept saving. Seems strange in this IPv6 context to have to do that. I intuitively tried first with its IPv6 address and I couldn't save. -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Status - Traffic Shaper - Queues
[ This message never made it to the list (at least I have not received the echo, so do I think.) I'm retransmitting without the small screen captures and without OpenPGP signature, as I suppose attachments of any kind blocked the message from delivery. I apologize in advance if this will lead to a double post. ] Dear all, This is a request for enhancements in the GUI, unless discussion uncovers errors on my own side. I can't easily make a sense of the "Status - Traffic Shaper - Queues" page, and I think that goes against the whole concept behind pfSense. :) First issue is about interval over which the values displayed are computed. I'm more than OK with "Queue graphs take 5 seconds to sample data". But then, *what* are those displayed data? Are they limited to the last 5 seconds? Or are they a moving mean over some over period of time? What period? I can't match what I see there with reality of some traffic. Some added traffic does raise the counters (but slowly), dropping that same traffic only sees those counters decrease very slowly over time. Could it be that the values displayed are means "since initial page load"? Could it be changed to more instantaneous values? (means over 5 seconds, between page refreshes, is probably good enough). Maybe a GUI checkbox to alternate between a "last 5 seconds sample" view and this accumulated view? Second issue is linked with CBQ traffic shaper setting. No matter how I build my setup, through wizard or custom, I always end up with the Status: Traffic shaper: Queues page to show me a wrong / illogical value on the "Root queue" lines: it is always more or less (or close to) *twice* the sum of the queues behind the "Root". It probably is a bug in the reporting of the data, cause again I can't make a sense of that doubled value. Third issue is with values displayed first (after 5 seconds) when displaying the page. Sometimes, not often, the values I see are hugely wrong and exaggerated. I for instance can see WAN doing 150 Mbps and the LAN showing 540 Mbps while the physical reality is that WAN is limited to 10 Mbps and LAN 70 Mbps (on this VDSL2 connection). If I wait for 1 minutes or more, the values go down rather slowly and finally settle to more or less meaningful values. Still with those comments from first and second issue above. WAN (9 Mbps) qVoip (pri 7, 1 Mbps, can borrow) qAck(pri 6, 2 Mbps, can borrow) qHigher (pri 4, 3 Mbps, can borrow) qDef(pri 2, 2 Mbps, can borrow) qLower (pri 1, 1 Mbps, can borrow) Same concept, different Mbps, for LAN and OPT1. Are these behaviors confirmed by other people? (The doubling (more or less) on Root queue lines, I only have seen them with CBQ setups, as far as I remember.) -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] client VPN on IOS
> Le 15 sept. 2015 à 15:18, Ray Bagby <rba...@sbcglobal.net> a écrit : > > Greetings, > >Anyone have any luck connecting iphone via VPN? > > Thanks Very easily, I would say. And very stable once setup. I use "OpenVPN Connect" iOS App (just search "openvpn" in iOS AppStore, should be the first choice or close to). There may be others, I merely use that one and it fits my needs. On pfSense, do not forget to first install the package "OpenVPN Client Export Utility" and use it to package the config file you will need on the iOS device. You will then have a new tab "Client Export" within the OpenVPN menu. Most settings it not all should be OK by default (for a first try at least). On the lower right of the screen click on the tiny link "OpenVPN Connect" and you will get a proper file for your device. You will have to either move the exported config file through iTunes/USB or send it to yourself by email (much less secure of course), in order to import it in the App and then use it. -- Meilleures salutations, Met vriendelijke groeten, Best Regards. Olivier Mascia, integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] Suricate package with fixed PPPoE support?
Hello, Regarding this: https://redmine.openinfosecfoundation.org/issues/1445 Could we get the Suricata package available for pfSense, built with the discussed and apparently tested PPPoE fix, without waiting for Suricata 2.1 to get out of beta? Thanks! __ Olivier Mascia integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.2.2 - Status - Traffic shaper - Queues
It is weird to the point that sometimes, if I visit it I first see completely wrong values : 1.4 Gbps on my WAN for instance (which is technically limited to 70 Mbps). In such case, over some minutes the values start decreasing and finally come to some more sensibe values. Here is a pic upon entering the status - traffic shaper - queues this morning. The values are odd. This is a VDSL line with profile 70 (down) /10 (up) Mbps. If I wait some *minutes*, the values are more plausible, but probably wrong anyway. If any of you has an idea what configuration defect I should look for... Thanks! __ Olivier Mascia integral.be/om Le 23 avr. 2015 à 11:15, Olivier Mascia o...@integral.be a écrit : Dear all, As I remember when I started using pfSense (back at 2.0) I could make a sense of the dynamic view Status - Traffic shaper - Queues. I could watch my voip queue for instance and clearly see it report sensible values according to the VOIP sessions in progress. I could even spot the count of simultaneous channels just by looking at the packets rate. Somehow I lost that 'sense', not sure if it was since 2.1 or some sub-release since then, but it still is obscure (to me) with 2.2.2. Is the dynamic reporting done by that status display meant to be some mean over some time instead of an instant report (at each refresh)? It is weird to the point that sometimes, if I visit it I first see completely wrong values : 1.4 Gbps on my WAN for instance (which is technically limited to 70 Mbps). In such case, over some minutes the values start decreasing and finally come to some more sensibe values. Is there some known defect there? Or is this a known symptom for something terribly ill-configured on my side in the traffic shaper? Thanks for sharing your thoughts or experiences on the matter. Best regards, __ Olivier Mascia integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
[pfSense] 2.2.2 - Status - Traffic shaper - Queues
Dear all, As I remember when I started using pfSense (back at 2.0) I could make a sense of the dynamic view Status - Traffic shaper - Queues. I could watch my voip queue for instance and clearly see it report sensible values according to the VOIP sessions in progress. I could even spot the count of simultaneous channels just by looking at the packets rate. Somehow I lost that 'sense', not sure if it was since 2.1 or some sub-release since then, but it still is obscure (to me) with 2.2.2. Is the dynamic reporting done by that status display meant to be some mean over some time instead of an instant report (at each refresh)? It is weird to the point that sometimes, if I visit it I first see completely wrong values : 1.4 Gbps on my WAN for instance (which is technically limited to 70 Mbps). In such case, over some minutes the values start decreasing and finally come to some more sensibe values. Is there some known defect there? Or is this a known symptom for something terribly ill-configured on my side in the traffic shaper? Thanks for sharing your thoughts or experiences on the matter. Best regards, __ Olivier Mascia integral.be/om ___ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
Re: [pfSense] 2.1.5: RRD: There has been an error creating the graphs.
On Nov 5, 2014 8:39 AM, Olivier Mascia o...@integral.be mailto:o...@integral.be wrote: Hello, Checking the logs, I get 5 or 6 errors ... I expect that clearing whatever past data there is might help clean the error. What steps should I take to reset this? Le 5 nov. 2014 à 23:41, Oliver Hansen oliver.han...@gmail.com a écrit : I believe in the settings tab for RRD there is a reset option. I've had to reset mine after almost every upgrade since 2.1. I feel sad not to have seen that reset button, sooner. It seems to have cleared things up. Thanks! __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
[pfSense] 2.1.5: RRD: There has been an error creating the graphs.
Hello, Checking the logs, I get 5 or 6 errors similar to this one when accessing the Status - RRD Graphs menu item: php: /status_rrd_graph_img.php: Failed to create graph with error code 1, the error is: ERROR: No DS called 'inpass6' in '/var/db/rrd/wan-traffic.rrd'/usr/bin/nice -n20 /usr/local/bin/rrdtool graph /tmp/wan-traffic.rrd-year.png --start 1383582289 --end 1415204689 --step 86400 --vertical-label bits/sec --color SHADEA#ee --color SHADEB#ee --title pfsense.tipnet.tipgroup.com - WAN :: Traffic - 1 year - 1 day average --height 200 --width 620 DEF:wan-in_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass:AVERAGE:step=86400 DEF:wan-out_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass:AVERAGE:step=86400 DEF:wan-in_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock:AVERAGE:step=86400 DEF:wan-out_bytes_block=/var/db/rrd/wan-traffic.rrd:outblock:AVERAGE:step=86400 DEF:wan-in6_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass6:AVERAGE:step=86400 DEF:wan-out6_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass6:AVERAGE:step=86400 DEF:wan-in6_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock6:AVERAGE:ste p=86400 This is not a recent event, it has been that way for months. I do not really care if I have to loose old data to fix this because I have other traffic data collection (SNMP based) and at the switch ports level too. Let's say it just would be a convenience to get those to work again, when I have to quickly have a look to past traffic while connected in the admin interface. I expect that clearing whatever past data there is might help clean the error. What steps should I take to reset this? Or is there something else to check and correct first. I have to confess I'm puzzled with the ERROR: No DS called 'inpass6'. I only know one thing for sure: I din't tweaked anything around or about RRD by myself at any point in time. This pfSense installation started its life with 2.0.x 64 bits. And went to 2.1 upon release, then followed up to 2.1.5. IPv6 was actually rolled out some months after 2.1 got installed. If someone has an idea or a hint to share, that'd be friendly. Thanks! __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] PFS 2.1.4 -- IPv6 with PPPoE (worked until 2.1.3)
The NOT so funny thing is that following this discussion it came to my attention that I was still running 2.1.3. I upgraded to 2.1.4 this morning. Nothing else changed in the configuration : packets do not route anymore between IPv6 LAN and IPv6 WAN. pfsense can ping6 and traceroute6 anything else either WAN side or LAN side. But LAN computers can not reach anything else outside (over IPv6). I will run some more tests and then will restore 2.1.3 to better check this. I am particularly interested in seeing if you have an IPv6 (other than link local) provided ? You get a fe80: as WAN IP (I currently have fe80::215:17ff:fe16:18dc%em4) and the gateway is currently fe80::207:7dff:fe56:5900%pppoe0. This kind of setup has always worked until my 2.1.3-2.1.4 upgrade this morning. :( __ Olivier Mascia tipgroup.com/om Le 8 juil. 2014 à 19:49, b...@todoo.biz a écrit : One more question : Can you show me the output of your interface page ? I am particularly interested in seeing if you have an IPv6 (other than link local) provided ? And also can you show me the output of your routing table ? Sincerely yours. G.B. Le 7 juil. 2014 à 09:48, Olivier Mascia o...@integral.be a écrit : I will assume your link is provided through VDSL2 as you mention Belgacom. The next WAN setup works fine with a fixed-IP circuit provided by EDPNET, who uses Belgacom VDSL2 network. PastedGraphic-1.png Assign (for instance) one /64 out of the /56 they provide you to the LAN (I understand you did that). Regarding RA, I have to use these settings to best serve a LAN made of PCs (mostly Windows, some Linux) and Macs. In this configuration, neither pfsense DHCPv4 server nor pfsense DHCPv6 server are used, those services are offered by other computers inside the LAN. I cut the print-screen before it, but don't forget to list your /64 LAN net in the RA subnet(s) field (the third field). PastedGraphic-2.png Hope it might help, __ Olivier Mascia tipgroup.com/om Le 6 juil. 2014 à 23:32, b...@todoo.biz a écrit : Hi, We are trying to debug an IPv6 link provided by Belgacom. We have our IPv6 through a PPPoE link, but instead of attributing our IPv6 to the default interface (WAN), the fixed IPv6 seems to end up on the lo0 interface ? I can ping6 google using the default route, but not through our LAN where I have configured one of the /64 block taken from the /56 provided by Belgacom. I have properly configured RA on the LAN with stateless autoconfig… still no luck ! Is there a bug somewhere or am I missing smthg ? Thanks. G.B. Capture d’écran 2014-07-06 à 23.21.06.png «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ BSD - BSD - BSD - BSD - BSD - BSD - BSD - BSD - «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ PGP ID -- 0x1BA3C2FD ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ BSD - BSD - BSD - BSD - BSD - BSD - BSD - BSD - «?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§«?»¥«?»§ PGP ID -- 0x1BA3C2FD ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] PFS 2.1.4 -- IPv6 with PPPoE (worked until 2.1.3)
I don't really get what went mad today on this configuration after 2.1.3 - 2.1.4 upgrade but after a lot of suspicion on (too) many (correct) settings and finally re-assessing the initial configuration which worked fine on 2.1.3 *and* a final reboot (the clue?), it now is back alive and routing IPv6 as correctly as before. So, G.B., as a synthesis: I am particularly interested in seeing if you have an IPv6 (other than link local) provided ? On its auto-configuration page EDPNET says these IPs are reserved for this fixed IP circuit: IPv6 LAN prefix 2a02:578:::/48 IPv6 WAN prefix 2a02:578::::/64 Using the PPPOE for IPv4 WAN and DHCP6 for IPv6 WAN, I get: On the WAN interface status page: IPv6 Link Local fe80::f5a0:854e:1417:a510%pppoe0 IPv6 addressfe80::215:17ff:fe16:18dc%em4 The gateway automatically defined is as this: WAN_DHCP6 (default) WAN fe80::207:7dff:fe56:5900 fe80::207:7dff:fe56:5900Interface WAN_DHCP6 Gateway The start of the IPv6 routing table is like this: Destination Gateway Flags RefsUse Mtu Netif Expire default fe80::207:7dff:fe56:5900%pppoe0 UGS 0 3428 1492pppoe0 ::1 ::1 UH 0 0 16384 lo0 2a02:578::1::/64link#1 U 0 319 1500em0 2a02:578::1::1 link#1 UHS 0 0 16384 lo0 2a02:578::20::/64 link#2 U 0 0 1500em1 2a02:578::20::1 link#2 UHS 0 0 16384 lo0 2a02:578::::/64 link#10 U 0 81 1492pppoe0 2a02:578:::f5a0:854e:1417:a510 link#10 UHS 0 0 16384 lo0 ... On the LAN interface, I use a /64 out of the /48 for LAN, and another one for OPT1. You can see that above. Yours, __ Olivier Mascia tipgroup.com/om Le 9 juil. 2014 à 11:55, Olivier Mascia o...@integral.be a écrit : The NOT so funny thing is that following this discussion it came to my attention that I was still running 2.1.3. I upgraded to 2.1.4 this morning. Nothing else changed in the configuration : packets do not route anymore between IPv6 LAN and IPv6 WAN. pfsense can ping6 and traceroute6 anything else either WAN side or LAN side. But LAN computers can not reach anything else outside (over IPv6). I will run some more tests and then will restore 2.1.3 to better check this. I am particularly interested in seeing if you have an IPv6 (other than link local) provided ? You get a fe80: as WAN IP (I currently have fe80::215:17ff:fe16:18dc%em4) and the gateway is currently fe80::207:7dff:fe56:5900%pppoe0. This kind of setup has always worked until my 2.1.3-2.1.4 upgrade this morning. :( __ Olivier Mascia tipgroup.com/om Le 8 juil. 2014 à 19:49, b...@todoo.biz a écrit : One more question : Can you show me the output of your interface page ? I am particularly interested in seeing if you have an IPv6 (other than link local) provided ? And also can you show me the output of your routing table ? Sincerely yours. G.B. Le 7 juil. 2014 à 09:48, Olivier Mascia o...@integral.be a écrit : I will assume your link is provided through VDSL2 as you mention Belgacom. The next WAN setup works fine with a fixed-IP circuit provided by EDPNET, who uses Belgacom VDSL2 network. PastedGraphic-1.png Assign (for instance) one /64 out of the /56 they provide you to the LAN (I understand you did that). Regarding RA, I have to use these settings to best serve a LAN made of PCs (mostly Windows, some Linux) and Macs. In this configuration, neither pfsense DHCPv4 server nor pfsense DHCPv6 server are used, those services are offered by other computers inside the LAN. I cut the print-screen before it, but don't forget to list your /64 LAN net in the RA subnet(s) field (the third field). PastedGraphic-2.png Hope it might help, __ Olivier Mascia tipgroup.com/om Le 6 juil. 2014 à 23:32, b...@todoo.biz a écrit : Hi, We are trying to debug an IPv6 link provided by Belgacom. We have our IPv6 through a PPPoE link, but instead of attributing our IPv6 to the default interface (WAN), the fixed IPv6 seems to end up on the lo0 interface ? I can ping6 google using the default route, but not through our LAN where I have configured one of the /64 block taken from the /56 provided by Belgacom. I have properly configured RA on the LAN with stateless autoconfig… still no luck ! Is there a bug somewhere or am I missing smthg ? Thanks. G.B. Capture d’écran 2014-07-06 à 23.21.06.png
Re: [pfSense] Bogon List
My pfsense box is connected to the edge and has a public IP address, so private and bogons are checked. It is the end user that appears to be on an ISP that is using a private IP one hop upstream from his personal router. When his packets reach the public internet, it appears to come from 216.14.x.x. My question is why IP 216.14.x.x is being caught by the bogon filter even though it is not listed in CYMRU’s database. Paul Galati paulgal...@gmail.com For what it's worth, at least a portion (20) of 216.14.0.0/16 is listed (in the fullbogons list at least). From http://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt: 216.14.64.0/20 __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Web GUI certs
Le 22 mai 2014 à 04:04, Volker Kuhlmann list0...@paradise.net.nz a écrit : What exactly should I be putting into the pfsense cert manager to get a similar effect? And make the browser accept the IP address(es) too? You need to properly define the alternative names of your server certificate. You typically don't do that on CA certificates. pfsense cert manager has this in the create internal certificate screen. The real X509 alt names extension would be a string such as this one: IP:192.168.3.7, IP:fe80::1234:1234:1234:abcd, DNS:localhost, DNS:*.mydomain.top The pfsense GUI offers you to enter multiple pairs of a type and a value, which with example would be: IP 192.168.3.7 IP fe80::1234:1234:1234:abcd DNS localhost DNS *.mydomain.top __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] ICMPv6 filtering recommendations with pfSense?
Le 14 mai 2014 à 03:37, Chris Buechler c...@pfsense.com a écrit : IMO, I agree that it's best to let ICMP flow free on IPv6. ICMP has had a bad reputation for a long time, and it's mostly undeserved in recent times. Jim How should I interpret the code you pointed to? That pfSense do let ICMPv6 flow freely (at least most of it deemed to be required for IPv6 correct behavior) by default, and it then is not dropped by the default block rule? The ICMPv6 traffic that's considered required for things to function properly is automatically allowed. Excellent. Thanks! __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] ICMPv6 filtering recommendations with pfSense?
Le 21 mai 2014 à 09:23, Seth Mos seth@dds.nl a écrit : The ICMPv6 traffic that's considered required for things to function properly is automatically allowed. Excellent. Thanks! The rules should automatically allow ICMP6 echo, packet to big and neighbor discovery on the link-local addresses so that basic functionality works. Iirc ICMP6 echo is not allowed from the internet using the GUA addresses, but ND, RA and RS is for normal operation. The rules are specifically higher in the ruleset to prevent accidentally blocking (and breaking) your IPv6 internet. To be fair, we could make the RA and RS rules a bit more fine grained for ICMP6, but those would apply to the link-local scope and are of limited reachability (atleast not from the internet). We already toggle a sysctl if we want to accept a RS for a given interface, so that would be of limited use. In followup of this discussion and before reading you above, I had updated my ruleset to allow ICMPv6 echoreq (with log) on the WAN from 2000::/3 only. I have no blocking rule for ICMPv6. Only that echoreq additional allow rule, which if correctly understood is not strictly required, but it fits my will until the day I would get a flooding attack on that. On the LAN, I have no ICMP rules whatsoever and if reading you correctly, should be just right. It at least just seems so, LAN interface pingable from LAN and we see no issue with our IPv6 network, being able to reach any IPv6 target, either LAN or WAN side. To my understanding, I'm then just fine set, with the added 'pingability' from the WAN (albeit on ICMPv6 only, not ICMPv4 which is blocked by default rules). If I'm wrong and still have understood something wrong, I'll gladly stand corrected. Thanks! __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] Filtering on source == gateway addresses
Le 21 mai 2014 à 16:09, Paul Beriswill paul.berisw...@pdfcomplete.com a écrit : On 05/19/2014 01:14 PM, Olivier Mascia wrote: pfSense 2.1.3 Would it be possible to write rules filtering on one (or all) of the gateway addresses? For instance, using the gateway names as an ALIAS. Or creating an ALIAS whose value is resolved to this or that gateway or all gateway addresses. That sounds like the normal way of doing it. If you define an alias that includes all GW addrs you can then use the alias in place of a IP address on your filters. Paul The gateway addresses are obtained by PPPOE for the IPv4 part of the link and DHCPv6 for the IPv6 part. So I can't define an ALIAS, not knowing the exact gateway IPs which can vary if there is a disconnection (VDSL technology on that specific site I'm referring to). To be honest, I have seen that these addresses do not seem to change often (more or less one short disconnection per 20 days and the gateway addresses do not change on each disconnect). But I think the interest for some ALIAS or other mean to refer to the actual gateway addresses in rules might be useful. Or I might have missed something big. :) __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
[pfSense] Filtering on source == gateway addresses
pfSense 2.1.3 Would it be possible to write rules filtering on one (or all) of the gateway addresses? For instance, using the gateway names as an ALIAS. Or creating an ALIAS whose value is resolved to this or that gateway or all gateway addresses. __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
[pfSense] ICMPv6 filtering recommendations with pfSense?
Hello, What about RFC 4890 and pfSense configuration of complex ICMPv6 filtering rules? Could it be possible to define a rule where multiple ICMPv6 types might be checked at once? For instance setting up a single rule to allow Type 1, 2, 3, 4, 128 and 129? Instead of needing to create as many specific rules as specific types to block or allow? Are there other documentation on ICMPv6 filtering, without dropping essential functionality, in the specific context of pfSense 2.1.x? Thanks ! __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] ICMPv6 filtering recommendations with pfSense?
Le 8 mai 2014 à 12:37, Mark Tinka mark.ti...@seacom.mu a écrit : On Thursday, May 08, 2014 12:25:54 PM Olivier Mascia wrote: Are there other documentation on ICMPv6 filtering, without dropping essential functionality, in the specific context of pfSense 2.1.x? My personal opinion, we already killed IPv4 by filtering ICMP (and thereby, killing pMTU). Let's not repeat that in IPv6. That said, ICMPv6 is different from ICMPv4, as it ensures link reachability among hosts (ARP is gone, as you know). It would be nice for pfSense, perhaps, to provide rate limits that would help ensure ICMPv6 isn't abused, but does not cut off service. That said, if you do want to filter ICMPv6, be sure to (at least) allow the following ICMPv6 messages: echo-reply echo-request membership-query membership-report membership-termination neighbor-advertisement neighbor-solicit router-advertisement router-solicit time-exceeded Mark. Thanks for this advice. On the WAN interface, I’m currently allowing full ICMPv6 in, albeit only from Global Unicast and Multicast addresses. That is: only from 2000::/3 and ff00::/8. The intention was to limit at least requests from WAN side using spoofed local addresses. I’m pretty confident that I do not break (too) many things this way (am I wrong?). I’m also logging these packets with some alerts from my syslog server if their rate suddenly raise. Rate limits, at least on replies, *should* be inherent to the implementation of ICMPv6 as far as I have read (don’t remember where though). Is this enforced in pfSense, I don’t currently know. __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] ICMPv6 filtering recommendations with pfSense?
Le 8 mai 2014 à 19:05, Brian Candler b.cand...@pobox.com a écrit : On the WAN interface, I’m currently allowing full ICMPv6 in, albeit only from Global Unicast and Multicast addresses. That is: only from 2000::/3 and ff00::/8. I don't think you'll see any packets with multicast source addresses. It's possible you could see packets with Link-Local source addresses (fe80::/64) from the upstream router, but you may not care. Thanks. They (upstream router) confirmed I can drop their eventual link-local ICMPv6 packets. Allowing multicast source addresses is indeed probably needless. __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] ICMPv6 filtering recommendations with pfSense?
Le 8 mai 2014 à 20:05, Jim Pingle li...@pingle.org a écrit : Code of interest here: https://github.com/pfsense/pfsense/blob/master/etc/inc/filter.inc#L2644 IMO, I agree that it's best to let ICMP flow free on IPv6. ICMP has had a bad reputation for a long time, and it's mostly undeserved in recent times. Jim How should I interpret the code you pointed to? That pfSense do let ICMPv6 flow freely (at least most of it deemed to be required for IPv6 correct behavior) by default, and it then is not dropped by the default block rule? (Which probably would be just fine for me). __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org https://lists.pfsense.org/mailman/listinfo/list
[pfSense] High cpu on check_reload_status
Hi, What might explain this issue and what could be done to fix it? PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND 69066 root 139 20 6908K 1448K CPU11 0:58 99.66% /usr/local/sbin/check_reload_status /usr/local/sbin/check_reload_status eats a cpu core. Thanks for pointers, Regards, __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] RRD: 'There has been an error creating the graphs.' - how could I clear this?
Hello, I see this error when viewing the RRD graphs: the graph is grayed and the message « There has been an error creating the graphs. Please check your system logs for further details. » is displayed in red. The system log says : php: /status_rrd_graph_img.php: Failed to create graph with error code 1, the error is: ERROR: No DS called 'inpass6' in '/var/db/rrd/wan-traffic.rrd'/usr/bin/nice -n20 /usr/local/bin/rrdtool graph /tmp/wan-traffic.rrd-day.png --start 1388135379 --end 1388221779 --step 300 --vertical-label bits/sec --color SHADEA#ee --color SHADEB#ee --title `hostname` - WAN :: Traffic - 1 day - 5 minutes average --height 200 --width 620 DEF:wan-in_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass:AVERAGE:step=300 DEF:wan-out_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass:AVERAGE:step=300 DEF:wan-in_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock:AVERAGE:step=300 DEF:wan-out_bytes_block=/var/db/rrd/wan-traffic.rrd:outblock:AVERAGE:step=300 DEF:wan-in6_bytes_pass=/var/db/rrd/wan-traffic.rrd:inpass6:AVERAGE:step=300 DEF:wan-out6_bytes_pass=/var/db/rrd/wan-traffic.rrd:outpass6:AVERAGE:step=300 DEF:wan-in6_bytes_block=/var/db/rrd/wan-traffic.rrd:inblock6:AVERAGE:step=300 DEF:wan-out6_bytes_block=/var/d I wonder what might have changed recently that would explain this condition. I’m not concerned about the data (I don’t heavily rely on these for anything, using other metering systems to monitor and log network activities), so I can loose the data, but I would like to clean this error condition anyway. Does anybody have pointers to me? Thanks a lot, __ Olivier Mascia tipgroup.com/om ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] 2.1 - strange minor issue with OpenVPN
Le 8 oct. 2013 à 16:45, Jim Pingle li...@pingle.org a écrit : On 10/7/2013 9:21 AM, Olivier Mascia wrote: Have you an idea what I should look for about this issue (see linked print-screen)? All my OpenVPN services report an error contacting the daemon, both on the status page (as in print-screen) and also on the dashboard page. Yet, all these services are running and working fine. This is only a status report issue between the services and the status screens. So nothing critical, but strange. I have another setup where I do not see such a behavior and I can’t get a sense of it. Do you have any advanced options in the VPN instances? Last time I saw that it was an upgraded 1.2.3 setup that had the old OpenVPN status package, and there were conflicting management directives in the advanced options. If you have those, remove them. Checked. No advanced options in any of these 3 OpenVPN configurations. And this is a pfSense machine which started life with 2.01 in 2012 and got upgraded to 2.1 this september 2013. Though… I forced a change in each of these configs, saved, reverted the change and saved again, and since I did that I haven’t yet seen the reporting problem again. So it most likely was something odd in the configurations, cleaned by the forced change/rewrite of configuration. At least it looks that way. Thanks a lot, __ Olivier Mascia integral.be ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] 2.1 - strange minor issue with OpenVPN
Dear all, Have you an idea what I should look for about this issue (see linked print-screen)? All my OpenVPN services report an error contacting the daemon, both on the status page (as in print-screen) and also on the dashboard page. Yet, all these services are running and working fine. This is only a status report issue between the services and the status screens. So nothing critical, but strange. I have another setup where I do not see such a behavior and I can’t get a sense of it. Any pointer welcome. https://www.dropbox.com/s/iydm2hgnmf2sv8p/Capture%20d%E2%80%99%C3%A9cran%202013-10-07%20%C3%A0%2015.15.11.png Thanks ! __ Olivier Mascia integral.be ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] /usr/local/bin/check_reload_status eating 100% cpu?
Le 17 sept. 2013 à 00:32, Olivier Mascia o...@tipgroup.com a écrit : I have been using 2.01 for about 2 years. Just upgraded to 2.10. This an amd64 full install. I’m seeing high-cpu usage (which was in the past 1 or 2%) and I can further verify that /usr/local/bin/check_reload is eating one full core. There is no noticeable impact thanks to this being a multi-core system. What should I further check to narrow down the issue? I have since read that check_reload wouldn’t be the issue in itself, but the consequence of some other problem. The question is: which one? What to check for? The purpose of upgrading from 2.0 to 2.1 was to activate our IPv6 native connectivity from our provider (EDPNET in Belgium). For what it looks like, our IPv6 setup on this box, also doing NATed IPv4 is quite correct, as seen from inside LAN workstations, both PC and Macs, that can access IPv6 servers on the internet without issue - let’s cite http://ipv6.google.com, but also http://ipv6.whatismyv6.com. Though, we lack past experience with pfSense IPv6 and some detail might well be the trigger to this issue. EDPNET ask for using DHCPv6, which we did. I dropped the Npt, using on the LAN interface the static subnet routed to us by the ISP through DHCPv6 WAN and it works nicely, high-cpu usage of check_reload disappeared. There is a secondary issue, which might be linked to this one (don’t know). On the Dashboard page, the OpenVPN widget keeps saying « [error] unable to contact daemon » and this for all our 3 OpenVPN server definitions. Yet those 3 VPN setups work without issue (can connect to them). This strange OpenVPN dashboard issue, is still present, but again, despite these errors those OpenVPN tunnels and remote access setups do work fine. __ Olivier Mascia integral.be ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] /usr/local/bin/check_reload_status eating 100% cpu?
Hello, I have been using 2.01 for about 2 years. Just upgraded to 2.10. This an amd64 full install. I’m seeing high-cpu usage (which was in the past 1 or 2%) and I can further verify that /usr/local/bin/check_reload is eating one full core. There is no noticeable impact thanks to this being a multi-core system. What should I further check to narrow down the issue? Thanks for any ideas. __ Olivier Mascia integral.be ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
Re: [pfSense] /usr/local/bin/check_reload_status eating 100% cpu?
Le 16 sept. 2013 à 14:33, Olivier Mascia o...@tipgroup.com a écrit : I have been using 2.01 for about 2 years. Just upgraded to 2.10. This an amd64 full install. I’m seeing high-cpu usage (which was in the past 1 or 2%) and I can further verify that /usr/local/bin/check_reload is eating one full core. There is no noticeable impact thanks to this being a multi-core system. What should I further check to narrow down the issue? I have since read that check_reload wouldn’t be the issue in itself, but the consequence of some other problem. The question is: which one? What to check for? The purpose of upgrading from 2.0 to 2.1 was to activate our IPv6 native connectivity from our provider (EDPNET in Belgium). For what it looks like, our IPv6 setup on this box, also doing NATed IPv4 is quite correct, as seen from inside LAN workstations, both PC and Macs, that can access IPv6 servers on the internet without issue - let’s cite http://ipv6.google.com, but also http://ipv6.whatismyv6.com. Though, we lack past experience with pfSense IPv6 and some detail might well be the trigger to this issue. EDPNET ask for using DHCPv6, which we did. There is a secondary issue, which might be linked to this one (don’t know). On the Dashboard page, the OpenVPN widget keeps saying « [error] unable to contact daemon » and this for all our 3 OpenVPN server definitions. Yet those 3 VPN setups work without issue (can connect to them). Thanks for any directions... __ Olivier Mascia integral.be ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
[pfSense] 2.01 / 2.1 - Email alerting on unsuccessful login ?
Hello all, Is there a mean to configure an alerting mechanism (email for instance) on unsuccessful login at the web admin interface? Same for unsuccessful login through OpenVPN? I can scan the logs, some proactive warning would be useful though. Did I miss an existing functionality? Thanks, — Olivier Mascia ___ List mailing list List@lists.pfsense.org http://lists.pfsense.org/mailman/listinfo/list
