pfSense (or other dedicated router) questions

[sfx2000]

I'll have to take a look. 100 GB isn't enough for snort logs? wow.. I have a 500GB spinner I could use in there, but the speed of an SSD (as long as it's not abused with writes) would be hard to give up. I reboot in just seconds...

Current disk should be more than enough - I'd suggest using logrotate to age them out over time, lot depends on your needs and requirements.

 

[sfx2000]

I don't understand your statement. The DUID gets recreated on each reboot, and the comcast DHCPv6 server identifies my router only by the DUID... so it thinks I keep changing routers each time a reboot.

Can you do a packet dump on the DHCPV6 handshake - I'm not in a spot where I can do this myself, nor do I have access to the last round of traces I captured at the moment (not at home right now)

Remember, there's three ways to represent DUID (Time/LinkLayer Addr is one, the other LinkLayer only, and the last is vendor uniquely defined UID associated with the enterprise name).

So if pfSense is using DUID-LLT and the server is expecting DUID-LL or DUID-EN, then that's a real problem, as we get into part of the spec which has an evil work "SHOULD NOT" as in should not change, it's not a shall not change, which suggests that they can indeed change and still be compliant - which drives people nuts that work on this kind of stuff.

The packet capture should show the handshake and what is sent by pfSense. You only need to capture on ports UDP346 and UDP347, but even without filtering those ports, it should show up...

Also, note what model/firmware version is in use for your cable modem, and you're on Comcast if I recall correctly...

This actually may be related to the similar issue that I chanced to discuss with CoxHSI tier 4 (network engineering).

 

[sfx2000]

And the question about model/firmware on the modem, some are configured as relay agents, and this can cause additional confusion - see https://tools.ietf.org/html/rfc6939

 

[garyd9]

My quoted response gave you less respect than you deserve. Sincere apologies.

Please don't apologize for disagreeing with me. If everyone agreed, I'd be bored and we'd never improve the world. Anyway.. I KNOW I'm right... and you probably know that you're right.. so it's fun figuring out the discrepancy.

I only get annoyed when people don't use rational arguments.

One of the reasons I jumped to the offensive on the pfsense.org forum was in reaction to the typical response to people asking the questions I was asking. Over there, I see stupid (and incredibly unhelpful) responses such as "Your an idiot. You shouldn't want to do that." In those cases, no one ever answers the questions being asked, they only criticize the question. So, my approach over there was to immediately squelch those people by presenting WHY the question was legit, give several random (but not too specific) reasons for wanting to do something, and challenging anyone who even started to respond on the attack. (It actually seemed to have mostly worked. At least I didn't get the "you're stupid for asking" type response.

As for any responses on here (or there) - I may have come across abrasively. It's a natural talent I've honed and developed over the years to keep people away from me. (I'm an engineer: give me as problem, I work out a solution, but I really don't want to spend hours talking about it.) Sadly, it screws me over when I'm seeking the help of others.

 

[sfx2000]

Please don't apologize for disagreeing with me. If everyone agreed, I'd be bored and we'd never improve the world. Anyway.. I KNOW I'm right... and you probably know that you're right.. so it's fun figuring out the discrepancy.

I only get annoyed when people don't use rational arguments.

Nullity is ok - he's smart, and interested in learning new things - as an enthusiast, he's pretty good - I've enjoyed working with him thru issues - a bit combative sometimes

Did you get a chance to review the two RFC's I mentioned - and it would be a major plus if you grabbed the pcap and shared...

 

[garyd9]

Can you do a packet dump on the DHCPV6 handshake - I'm not in a spot where I can do this myself, nor do I have access to the last round of traces I captured at the moment (not at home right now)

I know for a fact, based on pfsense logs, that it was re-creating the DUID on each reboot (and that it was creating a different DUID each time.)

As for which kind of DUID, I have no clue. Isn't there something I can do on the pfsense UI for packet capturing? If you tell me what you'd like me to set up (and the steps for doing it, etc - just assume I'm a clueless newbie) I'll do it and send the results via a google drive link...

(I can force it to renew dhcpc6 by going to the interface->WAN page, and performing a Save followed by Apply.)

 

[garyd9]

Oh, and in other news, I killed the netgear R7000 last night. No idea what happened, but first the 2.4 radio started getting flaky (flickering off and on) and then both radios started losing it.. finally, the stopped all together. Did a firmware reset/reconfigure, and still no radios. Did a firmware reset with complete nvram wipe.. and STILL no radios. I didn't see any magic smoke escaping, but... well.. I guess I pushed that thing pretty hard over the past few years. He's dead, Jim.

I had to run out to a micro center (2 hour drive each way) and picked up one of those unifi AC-PRO AP's. I got home about 30 minutes ago and it's already set up and running. (It's just sitting on a shelf for now where the r7000 was at.) This thing is NICE. I'm looking forward to getting another one, and mounting them both properly in ceiling space. I can even use a raspberry pi as a "controller." (I know I don't need the controller, but it's neat to look at.)

The only flaw I can find with it is that I can't figure out how to get the management software to communicate over a vlan. The individual SSID's work with tagged vlans, but no idea how to get the AP to talk to the controller s/w over a TAGGED vlan. That means I have a single switch port with 3 tagged vlans and one untagged (which is driving me nuts.) I'll send a question to the unifi folks about this in the morning.

 

[sfx2000]

I know for a fact, based on pfsense logs, that it was re-creating the DUID on each reboot (and that it was creating a different DUID each time.)

As for which kind of DUID, I have no clue. Isn't there something I can do on the pfsense UI for packet capturing? If you tell me what you'd like me to set up (and the steps for doing it, etc - just assume I'm a clueless newbie) I'll do it and send the results via a google drive link...

Logs are useful, but if it's not on the wire, it doesn't exist...

See here - https://doc.pfsense.org/index.php/Sniffers,_Packet_Capture

Hint - tcpdump -i <wan interface> >> /var/tmp/trace.pcap

The -i is the WAN facing port - so in my case, it would be;

tcpdump -i igb0 >> /var/tmp/trace.pcap

Do this on a WAN interface refresh, and then you can scp the file from the router to your desktop...

that's a good start - and the output can be viewed via Wireshark...

 

[sfx2000]

He's dead, Jim.

Bones...

 

[garyd9]

Logs are useful, but if it's not on the wire, it doesn't exist...

Attached to a PM to you. Please reply to this thread (or that PM) with any useful info you might get from it.

 

[sfx2000]

Attached to a PM to you. Please reply to this thread (or that PM) with any useful info you might get from it.

It's hitting the SHOULD statement - e.g. in the RFC, it's actually a SHOULD NOT, but your DUID is DUID-LLT, not DUID-LL or DUID-EN, which makes it time based...

And there's not much you can do about this one, it's up to the DHCP6 Server to be consistent here - no matter the PD or IA...

Pretty much the same issue I saw with CoxHSI, and this isn't limited to pfSense - they're actually somewhat compliant to the spec from the client side - but then we also might have the agent in the middle, which for some operators is the Cable Modem itself...

 

[sfx2000]

And FWIW - thanks for not posting the PCAP here - they can expose a lot of info, and I respect that, and won't post the text out - I've responded with the text out privately to garyd9, but suffice it to say, we understand what the problem is...

 

[sfx2000]

Anyways - I probably need to collect my thoughts here - this is an interop issue, and either side can change...

What I can say is that this seems to be consistent behavior across all the BSD variants (pfSense is one, Airport Extreme's, which have the same issue, are NetBSD based)...

I've always been of the opinion that servers need to be general, as clients might be specific - in other works, have a thick skin (the server for inbound traffic, handling many options) and a civil tongue (try to limit things to some basics).

This, my friends, is the bane of interoperability... we have a client with permitted behavior, and a server that is doing permitted behavior as per spec, and things still break...

 

[garyd9]

silly auto-moderation. It'd be nice if the forum admin could just flag users as "not a spammer" so we could reduce this occurrence.

 

[garyd9]

From RFC3315 (in reference to LLT types of DUID's):

Clients and servers using this type of DUID MUST store the DUID-LLT
in stable storage, and MUST continue to use this DUID-LLT even if the
network interface used to generate the DUID-LLT is removed. Clients
and servers that do not have any stable storage MUST NOT use this
type of DUID.

That certainly seems to indicate that it shouldn't change just because the machine rebooted.

(The packet capture showed that the DUID being used, by both pfSense and the comcast side of the link, is a DUID-LLT.)

Now I know how my QA testers feel when I mistakenly flag one of their bug reports as a duplicate of a feature. The difference is that my QA people can actually talk to me about it and/or edit the ticket to remove the "dupe" flag themselves. I can't do that in the pfsense tracker.

 

[garyd9]

I'm not going to type all this again, so I'll just link to it:

https://forum.pfsense.org/index.php?topic=116109.0

 

[sfx2000]

That certainly seems to indicate that it shouldn't change just because the machine rebooted.

Saw that, and as long as the machine is not restarted, it does maintain the generated value - and it stores this in /var

Where pfSense might have a problem - there's an option to store /var and /tmp in RAM - Look at the WebGUI, and under System / Advanced / Miscellaneous, and scroll down to RAM disks, there is a setting there - and many use this to reduce writes on CF/eMMC/SSD to extend the life of that media...

The contents then, if that switch is enabled, will cause the contents of /var, including the generated DUID-LLT to be lost, and a new DUID-LLT is generated when the device returns to operational state.

Would be interesting to know the state of that switch in your installation, and if enabled, disable it, allowing /var to be persistent, and see if the problem continues.

(FWIW - I have RAM disk enabled - old habit of mine, nominally to reduce the writes to the media)

@garyd9 - you can add/update the bug report you submitted earlier on this issue - thanks for prompting me to dig into this a bit further...

 

[garyd9]

Why bother updating it? They already decided that they were going to ignore it. It got marked as a duplicate of a feature request. Duh. I did update it.. and asked that they remove the 'dupe' flag, but I was shut down.

(Sorry, but that is very opposite of how I, personally, work. A bug is never a dupe of a feature. A bug should get fixed. A feature might get ignored. Whatever...)

BTW, I mentioned earlier that I do have the RAM Disk option enabled and that was the cause of the DUID file being nuked. I also posted how I worked around in post 119 (http://www.snbforums.com/threads/pf...ted-router-questions.33794/page-6#post-273355). That post leads to here: https://forum.pfsense.org/index.php?topic=114390.msg640854#msg640854 which has the basis of the workaround I used, along with a modification I made to make the workaround more efficient.

 

[sfx2000]

The work-around is a haxie - and that won't pass muster for mainline - even though it is a work-around on a bad implementation - the right fix would be to put this in a persistent .conf file - perhaps in /etc, or somewhere else...

That being said - now that we've gone down that path - some broadband operators still get a bit lost on the client side - and then we get into the ball of frustration I have with my broadband provider...

Anyways - since you've already filed the bug - an update will reopen it, so someone needs to take action - there are lots of bugs that are marked "dupe" based on info at the time - you have more info now to add...

 

[KenZ71]

Gary, respectfully, are you by chance making this too complicated?

I know it's only part of the solution- I've been able to set dd-wrt to put guest wifi accounts in a separate vlan

Then if you want the trusted guest humans to be able to see other stuff on your network why not simply put them on the same subnet but with read or write permissions ? Since you already have active directory let that be the gatekeeper for data.

Just my opinions