Netgate SG-1000 microFirewall

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - hendersonmc

Pages: [1] 2 3 4
IPv6 / Re: Netgate SG-4860 crashing when changing WAN IPv6 parameters?
« on: March 12, 2018, 12:02:50 pm »
I start mine in debug all the time. Do you have adequate storage available for the somewhat larger DHCP log file?

My ISP (Comcast Xfinity) provides a 64 bit prefix delegation size and I don't have the prefix hint selected (you take what your ISP gives).

Can you screenshot the complete configuration of all assigned interfaces of the SG-4680? (Hint, you only need two to start...)

IPv6 / Re: Netgate SG-4860 crashing when changing WAN IPv6 parameters?
« on: March 11, 2018, 06:42:55 pm »
How about some screen shots of what you are changing?

p.s. you do know it is a bit reckless to change more than one thing at a time, right?

IPv6 / Re: Logged, but not formatted
« on: March 11, 2018, 06:36:38 pm »
The only LL packets that pfSense can see are those that pass through a pfSense interface.  I know about the multicast packets for things such as router advertisements etc..  However, MLD is used to discover which devices on a local LAN want to receive specific multicasts from elsewhere, not those originating on the local LAN.  For example, if your computer wants to listen to some multicast out on the net, the routers (and possibly switches) listens for the request and then arranges to get that multicast from the source and pass it on to the requesting device(es).
Agreed; all the packets logged are from potential LAN clients of a multicast stream that the pfsense router has access to. If you execute "netstat -s -s" you can see that under icmp6: has reference to "MLDv2 listener report" which am guessing means the number of listeners observed since boot.

There is no need to do this on the local network.  Also, multicasts are not received by every node on the network.  They are filtered by multicast MAC address in the NIC, so that if a node is not interested in a particular multicast, it doesn't hear it. 
Yes, I understand and agree that multicasts are not received by every node. My understanding that the higher level IP protocols configure the Ethernet interface according to their needs to take advantage of the NICs ability to ignore Ethernet multicast traffic in hardware. The packets coming from various LL addresses on my LAN are sending to an IPv6 multicast address (ff02::16) that must be enabled by the pfsense router based upon a reserved Ethernet multicast address for MLDv2. I know how the old mapping of IPv4 multicast addresses were handled, but have not come across the equivalent method that supports IPv6 multicast addresses. IPv6 has many multicast addresses defined for LL traffic (

This differs from IPv4 broadcasts that all devices receive.  The only thing that's comparable in IPv6 is the all nodes multicast, which is received by all nodes and used for things like router advertisements.  Also, that "2" in ff02 refers to the scope, in this case link local.  That means a router will ignore it, as it doesn't have anything to do.
Both IPv4 and IPv6 use Ethernet multicast. IPv4 also uses Ethernet broadcast, which is not supported in IPv6, but, as you pointed out, however, if every IPv6 node enables the same Ethernet multicast address on a specific interface, then there is an effective link broadcast address. Routers will NOT repeat that traffic onto other links.

BTW, RFC 3810 has been superseded by RFC 4604.
RFC4604 is an update to RFCs 3376 and 3810 and clarifies how IGMPv3 is related to MLDPv2

And, I still am waiting to hear why there is selective filtering of logged traffic. I wonder what else is unformatted besides MLDv2 listener reports...

IPv6 / Re: Logged, but not formatted
« on: March 11, 2018, 02:40:25 pm »
The rule logs and passes any packet with a IPv6 Link Local address. With a LL source address, the packet can't have a public IPv6 destination, so I can't imagine any harm with passing all link local traffic..

As you can see from the log, the firewall is not formatting the packets that go to ff02::16, which is the reason that number of records differ.

Anything addressed to ff02::/16 is a multicast packet and is received by every node on the LAN segment, including the firewall. Per IANA, this is a multicast to "All MLDv2-capable routers" per RFC 3810. MLVD is the Multicast Listener Discovery Protocol. The purpose of MLD is to enable each multicast router to learn, for each of its directly attached links, which multicast addresses and which sources have interested listeners on that link. Presumably, pfsense is a MLDv2-capable router, which might be the reason to not show this traffic (although there are about 55 internal pass rules that might match this traffic and keep this user rule from ever seeing the traffic). The raw log file though shows that the packet is being matched by the LL rule (even though the formatted entry doesn't show it).

IPv6 / Logged, but not formatted
« on: March 10, 2018, 02:46:36 pm »
I was investigating IPv6 link local traffic and wrote a rule to pass and log all link local traffic.

I was surprised to find out that at least one of the packets logged did not show up at all under the formatted output.

Can anyone explain what controls this behavior?

Installation and Upgrades / Re: VGA console video configuration
« on: March 08, 2018, 12:16:48 am »
Thanks Per Hansson! Now I can read most of the pfsense startup messages, do a useful pftop, display the firewall log, etc.

I know some active members of the forum have a different opinion about implementing the console interface, but my experience has always been, better safe than sorry.

Installation and Upgrades / Re: VGA console video configuration
« on: May 11, 2017, 10:12:11 pm »
The follow on to the question on how to temporarily change the video mode of the console is how to change to the default boot confiiguration. Ideally, for a packaged system like pfsense, that change should be stored in the XML configuration, with an appropriate webconfigurator user interface.

Installation and Upgrades / Re: VGA console video configuration
« on: May 11, 2017, 10:41:24 am »
It looks like the vidcontrol command works to display video status, but I cannot get it to change video mode

I got a list of supported modes with this command

vidcontrol -i mode | more

However, I can't pick the mode. I have tried the following and the only response I get is the command line usage for vidcontrol.

vidcontrol mode
vidcontrol mode 80x25
vidcontrol mode 80x60
vidcontrol mode 0

Am I missing a flag? or?

Installation and Upgrades / VGA console video configuration
« on: May 11, 2017, 09:57:39 am »
I have pfsense system that I built from a D2500 SBC. It has a VGA output, and I hooked up my old Nokia Multigraph 446Xpro monitor to it. The video refresh rate is a paltry 31.5kHz, which allows text to limited to about 80 characters across the screen... barely enough for the "*** Welcome to pfSense..." banner to display on a single line.

Is there a way thru the Shell interface to drive higher resolution video?

IPv6 / Re: Comcast IPv6 address issue
« on: February 16, 2017, 06:44:48 pm »
Finally solved the dhcp6c process quitting.

Apparently, the tunnelbroker GIF tunnel that I had defined was interfering with the nominal IPv6, even though it was not assigned for any use on the Interfaces (assign) page, because when I deleted it, the WAN interface got an public IPv6 address.

IPv6 / Key for dhcp6ctl
« on: January 31, 2017, 05:16:34 pm »
You may have noticed that the falling in your DHCP log entries

Jan 31 16:18:15   dhcp6c   20803   failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Jan 31 16:18:15   dhcp6c   20803   failed initialize control message authentication
Jan 31 16:18:15   dhcp6c   20803   skip opening control port

These are error messages that happen when the dhcp6c process (that is responsible for interacting with a remote dhcp6 server) tries to open a TCP control port to receive commands from the dhcp6ctl command. The intent is to authenticate each command using as hash algorithm HMAC-MD5. Since there is no /usr/local/etc/dhcp6cctlkey in the file system for pfsense, the process inhibits receiving commands, which from a security perspective is the safe course of action.

If errors annoy you as much as they annoy me, just create the file with any secret one-line phrase that you like, encoded in base-64.

You can use this link to encode your secret phrase  

IPv6 / Re: Comcast IPv6 address issue
« on: January 04, 2017, 11:54:48 am »
That one rears it's ugly head again, I've been working on a fix for that. What version of PFSense are you running?

Latest version.

However, at this point, I am thinking that the extra dhcp6c processes are happening because I am shutting down the WAN interface by clearing the Enabled flag in the configuration, saving and applying. I could verify this by repeating the disabling and then checking for the dhcp6c process, but, I doubt that this way of shutting down the interface is the recommended way. If I were to guess, the recommended way is to clearing the Enabled flag, save, and then reboot.

Plus, now that I know this, I can just do the 'killall -9 dhcp6c' command as a workaround if I am unwilling to wait for a reboot...

IPv6 / Re: Comcast IPv6 address issue
« on: January 04, 2017, 11:53:11 am »
Here is the snapshots for the Interface Assignment and WAN Interface windows. All I change in the WAN Interface Configuration is the IPv6 Configuration Type to DHCPV6, then Save and Apply. While starting, I see this

root    15315   1.0  0.1 10096  1828  -  Ss   10:34AM    0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/ em0
root    74226   1.0  0.1 10460  2072  -  S    10:34AM    0:00.00 /bin/sh /var/etc/
root    81074   0.0  0.1 10460  2084  -  S    10:34AM    0:00.00 sh -c ps uxawww | grep dhcp6c 2>&1
root    81512   0.0  0.1 10264  1908  -  S    10:34AM    0:00.00 grep dhcp6c

And then I see this

root    15315   0.0  0.1 10096  1828  -  Is   10:34AM    0:00.00 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/ em0
root    80687   0.0  0.1 10460  2084  -  S    10:38AM    0:00.00 sh -c ps uxawww | grep dhcp6c 2>&1
root    81304   0.0  0.1 10264  1908  -  S    10:38AM    0:00.00 grep dhcp6c

The DHCP log looks like this

Jan 4 10:34:33   dhcp6c   15241   failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
Jan 4 10:34:33   dhcp6c   15241   failed initialize control message authentication
Jan 4 10:34:33   dhcp6c   15241   skip opening control port
Jan 4 10:34:48   dhcp6c   15315   XID mismatch

And the system log show this
Jan 4 10:53:26   php-fpm   11639   /system_gateways.php: ROUTING: setting IPv6 default route to fe80::213:5fff:fe05:bfe2%em0
Jan 4 10:53:27   php-fpm   11639   /system_gateways.php: The command '/usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -cf /etc/dhcpd.conf -pf /var/run/ em1' returned exit code '1', the output was 'Internet Systems Consortium DHCP Server 4.3.4 Copyright 2004-2016 Internet Systems Consortium. All rights reserved. For info, please visit Config file: /etc/dhcpd.conf Database file: /var/db/dhcpd.leases PID file: /var/run/ Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 3 leases to leases file. Listening on BPF/em1/00:22:4d:b0:d3:b8/ Sending on BPF/em1/00:22:4d:b0:d3:b8/ Can't bind to dhcp address: Address already in use Please make sure there is no other dhcp server running and that there's no entry for dhcp or bootp in /etc/inetd.conf. Also make sure you are not running HP JetAdmin software, which includes a bootp server. If you think you have received this mes
Jan 4 10:53:29   php-fpm   11639   /system_gateways.php: The command '/sbin/route delete -host 2001:470:20::2 ' returned exit code '68', the output was 'route: bad address: 2001:470:20::2'
Jan 4 10:53:29   check_reload_status      Reloading filter
Jan 4 10:53:29   php-fpm   11639   /system_gateways.php: Removing static route for monitor fe80::213:5fff:fe05:bfe2 and adding a new route through fe80::213:5fff:fe05:bfe2%em0

The WAN Interface looks like this

WAN Interface (wan, em0)
Status                       up
DHCP                         up
MAC Address                  c4:2c:03:05:41:0d - Apple
IPv4 Address       
Subnet mask IPv4   
Gateway IPv4       
IPv6 Link Local              fe80::c62c:3ff:fe05:410d%em0
IPv6 Address                 2001:558:6022:b:c40:ffa:c94:3324
Subnet mask IPv6             128
Gateway IPv6                 fe80::213:5fff:fe05:bfe2
DNS servers
MTU                          1500
Media                        1000baseT <full-duplex>
In/out packets               29523479/11443436 (33.45 GiB/1.06 GiB)
In/out packets (pass)        29523479/11443436 (33.45 GiB/1.06 GiB)
In/out packets (block)         123447/3244     (18.98 MiB/374 KiB)
In/out errors                0/1
Collisions                   0

For my network, the IPv6 traffic is not forwarding. I am still using the public addresses that tunnelbroker gave me on the LAN, which might be a reason, although I can't understand what is wrong.

I am also now noting a strange behavior that the IPv6 traffic that is enabled for logging in the UI is not showing up in formatted logs. Is this because the IPv6 traffic can't be forwarded?

IPv6 / Re: Comcast IPv6 address issue
« on: January 04, 2017, 10:15:40 am »
I tracked down one issue; the dhcp6c process is being started twice for the same interface.

root    58549   0.0  0.1 10096  1832  -  Is    8:07PM    0:00.11 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/ em0
root    91097   0.0  0.1 10096  1824  -  Is    8:07PM    0:00.10 /usr/local/sbin/dhcp6c -d -c /var/etc/dhcp6c_wan.conf -p /var/run/ em0

Does anyone know how the hidden startup files can be corrected? Just editing the interface through the pfSense Interface Configuration editor is not correcting the problem.

IPv6 / Re: Comcast IPv6 address issue
« on: January 03, 2017, 04:12:15 pm »
So one more question here... do you have just a modem, or do you have a gateway (modem+router) device from Comcast? Because if you have the latter, that will definitely affect IPv6. Comcast's gateways are not configured for IPv6 prefix delegation (unless you have a business account with static address(es). If you want to run pfSense behind a Comcast gateway, you'll want to put the gateway into Bridge mode, so it functions as just a modem, and let pfSense handle all of the router/firewall functions. Yes, that also means you'll need your own WiFi access point, as the Comcast gateway won't provide local network WiFi anymore either.

Just a modem... by special request!

Pages: [1] 2 3 4