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 - Efonne

Pages: [1] 2 3 4 5 ... 43
1
Wireless / Re: Any 802.11n Support on 2.1 release ?
« on: September 17, 2013, 09:03:36 am »
I think that mode is supported, but I've never tried it myself.

2
Wireless / Re: how to build wifi wds
« on: September 17, 2013, 02:51:51 am »
People seem to essentially talk about anything related to wireless in this sub-forum if there is a pfSense system connected to it in any way.  jerusalem181 should probably make a separate topic in the Captive Portal sub-forum for that part, though, if there isn't an existing topic that already has the information to help him.

3
Installation and Upgrades / Re: Thanks for the utterly broken 2.1 update.
« on: September 16, 2013, 10:19:35 pm »
I just wanted to note that the embedded kernel is mainly intended for running on devices that can't run the regular kernel because of lack of VGA, etc.  It does not change anything about how pfSense writes to disk, where it writes to disk, or how often it writes to disk.  Some people have the mistaken notion that selecting the embedded kernel changes those aspects somehow, but it does not.  The partition layout and configuration of the internal scripts are what do that, which the kernel selection does not change.

4
Wireless / Re: Any 802.11n Support on 2.1 release ?
« on: September 16, 2013, 10:05:14 pm »
Maybe 2.2, which I think is going to a higher FreeBSD version, but not 2.1, since it is still on FreeBSD 8.x.  I think 2.1 does support more 802.11n cards than 2.0, but still only in a/b/g modes.

5
There may be a bug with MAC address handling for the *_wlan0 interfaces that may have gone unnoticed by everyone else and that I never got around to fixing myself.  Rather than assigning urtw0 directly; if it is still assigned to something, then unassign it and reboot (also reboot if you haven't since it was last assigned), or instead of rebooting you can delete the urtw0_wlan0 interface manually from the console if you know how; then create a virtual wireless interface on the wireless tab (available from the assign interfaces page) and assign urtw0_wlan1 instead or directly assigning urtw0.  If the bug I'm thinking of is still there, this may work around it.

6
Wireless / Re: Spoof MAC of hostap
« on: September 16, 2013, 09:39:33 pm »
This kind of needs it own setting, because you can only set the MAC of the base device to affect the BSSIDs of the virtual wireless interfaces that are generated.  The driver will not host a wireless network with a BSSID that differs from the MAC of the base device other than certain bits it changes when you create more than one virtual device that runs on the same base device.

There is no way to configure this through the GUI at the moment, since pfSense does not actually configure the ath0 device, instead creating ath0_wlan# devices to be configured.  FreeBSD 8 or higher, used by pfSense 2.0 or higher, actually stopped using the base device name directly, other than for querying some device details and creating virtual wireless interface that are what you actually configure with all the network settings.  pfSense 2.0.x and 2.1 internally convert the ath0 name to ath0_wlan0 instead, so that is why the MAC address setting does not affect the ath0 device.

Just for reference to those who might want to work on this, adding a setting to change it is not as simple as just changing the MAC on the base wireless device.  As far as I know, any existing virtual devices for access points created before the MAC was changed need to be removed and recreated to generate a new BSSID based on the new MAC on the base device, since IIRC the BSSID cannot be changed once an access point virtual device is created.  On boot, this setting would need to be applied before any of the virtual wireless interfaces get created.  This is because the driver won't allow the BSSID to differ from the MAC you've configured for the base device (beyond certain bit fields it changes when you have multiple access points).

7
Wireless / Re: Hostap no go in 2.1 Fix
« on: September 16, 2013, 09:17:11 pm »
Don't use that for wireless, leave it at the default setting.  Technically that setting should probably be hidden for wireless and ignored internally for wireless interfaces if someone does have it set.

8
Wireless / Re: how to build wifi wds
« on: September 16, 2013, 09:12:17 pm »
The wireless part of this topic actually has nothing to do with pfSense at all because he was talking about using separate hardware for that, so pfSense not yet supporting WDS does not apply.

9
Routing and Multi WAN / Re: MUTLI WAN & NAT ??? [SOLVED - Reply#10]
« on: January 26, 2013, 08:18:05 pm »
I saw port forwards for each.  However, was it your intention to have your port forwards use two IP addresses for the redirect target IP? (10.10.10.20 and 10.10.10.30)  I think using an alias with two (or more) addresses in it like that will make the forwarding cycle through the addresses in the alias on each connection attempt, using a different one each time.

10
Routing and Multi WAN / Re: MUTLI WAN & NAT ??? [SOLVED - Reply#10]
« on: January 25, 2013, 09:34:25 pm »
I don't have enough experience with multi-WAN to be able to just spot the issue, but I do know of one potential issue I had seen in the rules someone mentioned.  As far as I know, "Pass" on port forwards bypasses the firewall rules, likely including the ones specifying which gateway to use.  Firewall rules should be used instead of directly using "Pass" on port forwards if you have any special firewall rules with gateway settings.  The same may apply to limiters or traffic shaping.  Depending on how your rules are set up, you may need to duplicate some of the settings to the linked rules for your port forwards (I'm not certain of this, though).

11
If you set up your slices properly, upgrades should still work; however, you will need to create appropriately sized upgrade images or when you upgrade the file system will not fill the whole slice (which is typical when using an upgrade image smaller than intended for your base image size).

12
Wireless / Re: Channels beyond 11 not visible
« on: December 20, 2012, 01:14:50 am »
I think I've heard of this DHCP issue before when using the wireless in client mode.  I know of a potential fix and it has been on my todo list, but I haven't really gotten around to it (I'm not a hired developer after all and do not work for any other company that would pay me to work on pfSense; I mostly just work on things when I feel like doing it).  No one else has attempted working on it (that I'm aware of).

As for your earlier question about wireless channel availability -- the regional settings are only really there to limit the list of channels to only show what you should be seeing for your area.  This setting is especially useful for drivers or firmwares that list every channel as available (cards supported by mwl do this, for example), because it will otherwise give a long list of channels that are essentially useless since other devices won't use them.  As the note below the group of settings states (but in different words), it can only impose further limits on the channels available; it cannot add channels locked out by the driver or firmware.

13
Wireless / Re: proper miniPCIe Card for AP mode? (v2.0.1 32bit)
« on: December 20, 2012, 12:25:00 am »
I wasn't aware there were such adapters for these cards.  However, of the adapters on that site in your link, that one is opposite of what you would want.  To use a miniPCI card, you would want one like this instead: http://www.amfeltec.com/products/flexible-minipcie-to-minipci-adapter.php

14
Routing and Multi WAN / Re: NAT reflection on multi-WAN and multi-LAN
« on: December 04, 2012, 12:23:12 pm »
For the NAT reflection, are you sure that your port forward is not too permissive?  Overly permissive port forwards are one of the most common causes of loss of connectivity related to NAT reflection.  2.0 detects the most common one, using "any" for the destination, and changes it for the reflection rules, but does nothing for other address selections because anything else could be valid.

Unless I'm misunderstanding the setup, what you are seeing should not happen if your port forward only uses a single IP or alias of multiple IPs for the destination field rather than "any" or a subnet (unless maybe it is a subnet where you own every IP).

15
I don't remember when I last saw this, but the text issue seems to have been fixed with Firefox 17.0.1.  I still see the change on the right side of the dropdown menu graphic as I put the pointer over each item, but the text appearance now stays the same throughout the page.

Pages: [1] 2 3 4 5 ... 43