Confusion in wireless setup…



  • Hi. Using 1.0 RELEASE. I'm having difficulty transfering packets across my wireless ap but no trouble connecting.

    I have 3 interfaces (WAN, LAN, and WLAN (OPT1)). WLAN (wireless) operates as its own subnet with some limited traffic to the lan (I'll set that up later) but should be able to access the WAN independent of the LAN.

    LAN: XXX.XXX.192.1 255.255.255.0 (static)
    WLAN: XXX.XXX.54.1 255.255.255.0 (dhcp)

    Took me a while to figure out but I eventually understood that I needed to both set a rule for wlan traffic (I used an any-all rule for trouble shooting) and an outbound NAT rule–which is what had me stumped for days. The NAT rule is for the WAN interface, as suggested and 'network' for XXX.XXX.54.0 (again, for troubleshooting purposes any-all).

    I can ping the WLAN interface out to WAN now but I can't seem to transfer packets from a client. At this point I can't even ping the dhcp assigned gateway. The WLAN interface is completely open. Access Point mode. No WEP. No WPA (again all for troubleshooting). Open Authentication. Before I figured out how to get WAN traffic on a secondary subnet with the advanced NAT rule I tried bridging WLAN to LAN and was able to get unencumbered traffic across.

    So my first question is regarding the gateway for WLAN interface. Both the DHCP server page and the interface page ask me if I want to set a gateway. Should I manually enter an address for either? Is the DHCP gateway supposed to be my LAN ip?

    The second question is just more general. How can/should I troubleshoot this further? Is there another type of NAT rule I am missing? Packets can and have been transferred across WLAN when it was bridged to LAN so I know it is possible. What could be preventing me from even being able to ping my gateway?

    Many thanks to the posters to this forum and the wonderful devs who helped with the project.
    ~Chad



  • You are overcomplicating things I think. In general you only need a rule at the opt1 interface to allow traffic. NAT will be done automatically unless you are using advanced outbound nat for something else.

    Is your OPT1 WLAN a wireless nic in the pfSense or is it an external Accesspoint connected to a wired interface at the pfSense? If it is an integrated wireless nic what card are you using?



  • Hoba- Thank you for the swift reply.

    OPT1 is in pfSense, however NAT was not done automatically unless I bridged OPT1 to LAN which I don't want to do.

    Just setting a ANY–>ALL rule on OPT1 did not allow traffice through. (OPT1 could not ping WAN)



  • Sounds very strange. Maybe you should start over from factory defaults. Just setup DHCP for the wireless OPT Interface and create a pass any any any rule on that interface (make sure protocol is any too). It should work just fine.

    If that doesn't work please provide the nic that you are using and post your wireless interface settings.



  • Will do. I've tried that twice before but maybe third time will be a charm.

    Info will be forthcoming.

    Nic, by the by, is a senao 400mW (atheros 5006 based) minipci.

    Best~



  • Is this a wrap or soekris? Make sure you have a reliable powersupply. These highpower wirelesscards can cause issues when using cheap powersupplies. In case it is a wrap make sure you have the latest bios as it fixes some problems with atheros cards.



  • Re: wrap/soekris. Nope. This is a via C7 with manufacturer specified max cpu draw of 7w, video disabled, a CF memory card (also negligible) and no othe peripherals other than the mini-pci. It's all powered by a 120W picopsu. That should be more than enough considering the almost nonexistant draw of the remainder of the parts.

    As for your suggested troubleshoot.

    I reset to factory defaults and made the following changes:

    Interfaces OPT1
    –------------------
    Enable: [checked]
    Type: 'static'
    Bridge with: 'none'
    IP Address: '172.16.54.1 / 24'
    Standard: '802.11g'
    Mode: 'Access Point'
    802.11g OFDM Protection Mode: 'CTS to Self'
    SSID: 'testwlan'
    Channel: '10'
    Authentication: 'Open Authentication'

    Everything is basically unchecked or left open.

    Firewall –> Rules

    Interface: OPT1
    First Rule: [All] = *

    Ping 1
    –------
    Host: www.google.com
    Interface: LAN
    Count: 3
    Output:```
    PING www.google.com (216.239.37.99) from 172.16.192.1: 56 data bytes
    64 bytes from 216.239.37.99: icmp_seq=0 ttl=239 time=23.382 ms
    64 bytes from 216.239.37.99: icmp_seq=1 ttl=239 time=14.505 ms
    64 bytes from 216.239.37.99: icmp_seq=2 ttl=239 time=16.469 ms

    --- www.google.com ping statistics ---
    3 packets transmitted, 3 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 14.505/18.119/23.382/3.807 ms

    
    Ping 2
    –------
    Host: www.google.com
    Interface: OPT1
    Count: 3
    Output:```
    PING www.google.com (216.239.37.99) from 172.16.45.1: 56 data bytes
    
    --- www.google.com ping statistics ---
    3 packets transmitted, 0 packets received, 100% packet loss
    

    So, as you can see, the rule alone doesn't make for auto resolution of a nat rule for OPT1 to WAN. At least not by default. I don't know if anyone else has had a similar experience or if this was by design but I'll leave it be for now until you have more thoughts or ideas before I go adding advanced NAT rules.

    Thanks Hoba.



  • Reboot. You might be bitten by the odd filter-reload bug. If it works after reboot it is that bug. There's an update in the pipe that will fix this problem.



  • Aha!

    That's it. So for now I'm going to assume any time I change filters I should reload.

    Is there anything I can or should do to help devs? It sounds like the problem has already been identified but if I need to fill out any kind of bug report or document this error please let me know how I can be of service.

    Thanks Hoba.



  • The fix already is in the codetree, no need for further information on the situation. This bug does not always appear, so you only need to reboot if the rules are not applied.


Log in to reply