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.

Topics - Derelict

Pages: 1 ... 16 17 18 19 [20]
General Questions / pfSense image hashes, folly?
« on: September 18, 2013, 05:14:10 am »
Isn't it kind of silly to upload MD5 and SHA256 hashes to the same mirrors hosting the images?

If someone can insert a bad image, can't they just insert a corresponding hash file to match?

Shouldn't there, instead, be PGP signatures?

Or at least a PGP-signed block of text in some release notes, blog post, etc. containing the image file names and what they should hash to?

When "Maximum number of unique source hosts (TCP/UDP/ICMP)" is set in a rule, is the n+1 source host denied or is the oldest entry (and all its states) cleared and the new one added?  Or something else?

And can I safely assume that as soon as all states for a particular source host expire, that slot is freed for another source host?


Captive Portal / Captive Portal Voucher CSV Space Bug?
« on: August 05, 2013, 12:28:27 pm »
Is it a bug in pfsense-tools' voucher.c that there is a space between the opening doublequote and the code in the voucher CSV export?

Okay -

I was all excited about multi-day vouchers using pass-through MAC with username but am seeing something really weird.

I have three portals defined.

The first one has no authentication.

The second has no authentication.

The third has vouchers enabled, Pass-through MAC addition, and Pass through MAC with username.

I connect to that network, get the voucher page, enter the voucher, and it is accepted.  But I am immediately presented with the CP login page again.

The MAC passthrough entry is added to the config for the correct portal instance, but the pass-through MAC entry in ipfw is added to the first instance instead of the third.

If I don't use Pass-through MAC addition, the user is added to the correct instance.

I restored my config to a test box and it worked fine so I'm pretty sure a restart will fix it.

But there's something funny with adding multi instance CPs still.

This is 2.1-RC0 July 22 15:44 amd64.  I don't think there have been any CP changes since.

(It might be nice to log $cpzone in portalauth.log)

Captive Portal / Vouchers spanning multiple days - Thanks
« on: July 30, 2013, 04:46:30 pm »
I am implementing a 2.1-RC1 CP instance for meeting room access and am pleased to find the following:

If I enable vouchers AND pass-through MAC addition w/ usernames, it appears I can grant access spanning multiple days, without users having to re-enter codes daily, without worrying about DHCP leases since the access is dependent only on the MAC, not the MAC/IP pairing, AND the MAC address passthrough entry is automatically cleared when the voucher code expires.

That last part was a pleasant surprise.  Given the language in the passthrough MAC GUI areas.

Awesome.  Thanks guys.

I had an active captive portal instance running and unchecked "enable captive portal" to allow everyone to pass through for a special event.

Now I want to reenable it.  I have checked enable and saved and I now have the ipfw rules in the correct context but I'm never redirected to the login page.  It's working as if the portal was disabled.  There are no mac addresses visible in the "ipfw -x zone_name list" nor in table 1 or 2.

Is there something else I have to do short of a restart to send the traffic on this interface through ipfw again? (restarting, based on prior experience, will fix it.)

2.1 20130705-1836


Firewalling / WAN / OPT Bridging - firewall rules - clarification
« on: May 23, 2013, 05:20:52 pm »
I have some questions regarding bridging the WAN on 2.0.3.

My goal is to be able to send all traffic destined for certain public IPs out to VLAN 1120 for assignment to customer router WAN ports anywhere on the campus.  I only want traffic for a subset of public IPs to be forwarded to VLAN 1120, not everything on the WAN. It would also be great if traffic coming in from VLAN 1120 that was not sourced from this subset of public IPs was dropped.

I also want the LAN port to have traditional NAPT internet access.

I have done the following:

Interface        ifname             Characteristics
COX_WAN       bge0_vlan1000  Type: none, Tagged VLAN 1000 to Metro Ethernet
INSIDE_WAN    bge1_vlan1120  Type: none, Tagged VLAN 1120 to inside switch trunk port
WAN               bridge0            Type: Static,, Members: COX_WAN, INSIDE_WAN
LAN                bge1_vlan1199  Type: Static,, DHCP Server, DNS Forwarder, Etc.

I have a /28 from Cox to utilize.  Of that, I want to reserve the last 4 addresses for these assignments so I created a firewall alias:


I have these System Tunables set:   default(1)   1

This is where I get foggy.  I am having a hard time wrapping my head around what rules need to go where on the bridge/bridge members and upon what traffic they operate.  The rules on the WAN (bridge0) seem to be functioning as expected with regard to the traditional NAPT for the LAN.

Here are the rules I currently have:

WAN (bridge0)

udp 1194 from any to WAN address  # For OpenVPN for Management
icmp from any to WAN Net          # Want to be able to ping public IPs

COX_WAN (Cox Metro E)
all from any to cust_public_ips

INSIDE_WAN (VLAN 1120 to customer router WAN ports)
all from cust_public_ips to any

Which rules actually operate on traffic coming into WAN/COX_WAN from the Metro E?  The ones on WAN, COX_WAN, or Both?

It appears to me that the rules on bridge0 operate on traffic destined for its IP address and the rules on COX_WAN operate on everything else.

The rules on WAN (bridge0) appear to operate whether is 0 or 1, which I find odd.  For instance, if I disable/enable this rule:

Pass TCP * * 22

I appropriately cannot/can open an ssh session for which I have created a port forward in NAT.

Any clarity that can be provided would be welcome.

General Questions / webConfigurator and SSH Listen IP:port
« on: May 21, 2013, 04:33:13 pm »
I would like to tell the web configurator and sshd to only bind to a specific interface.  I am setting up like this:

LAN = Management

Web configurator on port 8443, sshd on port 22.

When I open a shell, and look at the listening ports, I see *:80 *:8443 and *:22

I'd love to see management_ip:80, management_ip:8443, management_ip:22 instead like we can do with SNMP.

I don't see any way to do this in the GUI. (2.1?)

I edited /etc/sshd (adding ListenAddress) and /etc/inc/ (Adding server.bind and the port 80 redirect to management_ip:80)

This isn't working for me.  sshd isn't starting on boot even though the console message says it's starting..done.  I tried updating the pfSense_md5.txt with the right hash for /etc/sshd but no dice.  Running /etc/sshd manually starts the daemon.

Is there something more elegant?  It would seem silly to have to have a block rule for every interface address on 22/80/8443 to achieve the same thing.  If I can adjust the listen address I can have one floating rule for all OPT/GUEST interfaces blocking traffic to the management subnet.

Pages: 1 ... 16 17 18 19 [20]