Unable to configure NAT

  • I have a single WAN, fed from a LAN port on my firewall/router, and open ports on this router for PFsense.  (I know I don't need this, but it's there for now, until a fibre upgrade).

    I have two LANS, lan(BB) and opt1(TT).


    lan: - (huge scope I know)
    opt1: - (huge scope I know)

    I have some access points on each LAN. (used to be on .16) (used to be on .16)

    I have NAT rules setup to forward the WAN back to PFsense for https GUI access and SFTP access.  These are working fine.

    I have tried to setup (just temporarily) port 9001 to forward to an access point on port 80.

    I just cannot get this working - I can access locally just fine, and all the other access points too.

    I am trying to access from outside the PFsense LAN - I am actually on a remote site, making changes over the https GUI.

    I do see passes in the log though?

    I am not sure why this wont work?

    Is it because the access point IP's are outside the DHCP scope?

    An auto rule is created under WAN - What about under LAN and OPT1?  Do I need a rule there too?

    Outbound NAT is set to AUTO.

    I am trying http://myip:9001.

    If I change the port 80 redirect to port 443, then https:/myip:9001 takes me to the https GUI just fine.

    If I log in to a PPTP VPN session, and the PPTP server is told to give me a 192.168.16.x IP, I can access the access point.

    Any pointers here would be great!

  • LAYER 8 Netgate

    It doesn't fit with everything you've said, but have you doublechecked the default gateway in the AP?

  • LAYER 8 Global Moderator

    What do you mean it doesn't fit - I would agree that gateway not being set on the AP, or wrong gateway would clearly explain why you can not access it from a different segment.

  • Thanks.

    I assume the gateways are set correctly - I cannot check until on site, as obviously cannot access them!  I am hopefully there tomorrow, so will check.

    I assume for the 192.168.8.x ones, it is and for the 192.168.16.x ones, it is

  • LAYER 8 Netgate


    What do you mean it doesn't fit - I would agree that gateway not being set on the AP, or wrong gateway would clearly explain why you can not access it from a different segment.

    Because he said he could access it from the PPTP session on another subnet.

  • Hi.

    I still can't get it going.

    It works locally ok.

    I made an error.  I actually can't access over the VPN, although I used to be able to!  Not sure why that has stopped.

    All that is between the APs and PFsense is an unmanaged PoE switch.

    Any further ideas?


  • LAYER 8 Global Moderator

    Well my guess would be firewall or security setting on the AP that does not allow access from something on a different subnet.  What is the make and model of the AP?

    Looks to me your hitting that from the wireless network, can you actually get to it from wired network?  From both the one its on, and the other segment?

  • Hi.  It's a mix of 3com 7760 and ZyXel ones.

    If I connect to one wirelessly, I can then connect to the other 5 just fine, on both LAN interfaces.  So to me, that's connecting wired, and through PFsence to a couple.

    It's confusing me now!

  • LAYER 8 Global Moderator

    So here is what I would do - I would sniff on the pfsense interface connect to the network the AP is on, under diag, packet capture.

    From your rules you see traffic going through the fierwall.. So lets see it go out the wire, and see if you get a response back from the AP.  Will see this very quickly in the sniff if the AP does not answer then you have something wrong with the AP.  Either packets not actually getting there, firewall on the AP, etc. etc.

    If you see it come back to pfsense, then you need to figure out why pfsense is not sending it back on to you through the nat, etc.

  • Hi.

    I can see packets going out to AP and returning.

    xxx.xxx.xxx.xxx is me replacing my IP.

    15:56:48.317597 IP xxx.xxx.xxx.xxx.64991 > tcp 0
    15:56:48.318317 IP > xxx.xxx.xxx.xxx.64991: tcp 0
    15:56:48.318376 IP xxx.xxx.xxx.xxx.64991 > tcp 0
    15:56:48.567174 IP xxx.xxx.xxx.xxx.64992 > tcp 0
    15:56:48.567860 IP > xxx.xxx.xxx.xxx.64992: tcp 0
    15:56:48.567896 IP xxx.xxx.xxx.xxx.64992 > tcp 0
    15:56:51.316652 IP xxx.xxx.xxx.xxx.64991 > tcp 0
    15:56:51.317382 IP > xxx.xxx.xxx.xxx.64991: tcp 0
    15:56:51.317420 IP xxx.xxx.xxx.xxx.64991 > tcp 0
    15:56:51.566711 IP xxx.xxx.xxx.xxx.64992 > tcp 0
    15:56:51.567437 IP > xxx.xxx.xxx.xxx.64992: tcp 0
    15:56:51.567472 IP xxx.xxx.xxx.xxx.64992 > tcp 0

    So seems the packet it getting through PFSense to the AP, and the AP is responding.

    When I am on site, I will try to see if I can access the AP's from the WAN side of the PFsense, but after the router. (if that makes sense!)  Although, if I packet scan on the WAN port, I see packets from my IP to the PFsense WAN IP on port 9001, but no packets coming back.

  • LAYER 8 Global Moderator

    While that traffic looks like a conversation that should be working - what is actually in it, do a download of the capture and open it in wireshark.

    Do you mind sending PM to me for this IP your hitting.  I for 1 would never open up a AP web gui to the public net for starters ;)  But I can see what if anything comes back from the conversation.  Sure its just not showing up in your browser - what do you get on your browser for an error?

    Hard to tell if that is conversation - where your remote box got answer and sent more traffic..  all your tcp 0 doesn't look like much of anything is being seen?  Opening in wireshark make it eaiser to interpret

  • Hi.

    The GUI for PFsense I have as https.  I only wanted to quickly open port 80 on the AP GUI to check it was working, as had a complaint of lack of coverage the other week.  I thought I could quickly and easily access it to see the station associations!  How wrong was I, lol!

    Will PM you.

  • LAYER 8 Global Moderator

    so yeah I can hit your pfsense gui, but when I send to the 9001 part, I don't get ack back even.  I can not tell from what you posted what the ap is sending back - but it does look to answer but not seeing those answer at end past pfsense..  So pfsense is not routing it correctly not natting it?

    Yake a look on the wan side of pfsense via capture and see what you see.

    Sounds like your behind a double nat?  When you mention router in front of pfsense?

  • LAYER 8 Global Moderator

    See my pm - I got in, but could not ping.  And when I tried pinging from the web gui seems to have locked up the gui.

    So you are behind a double nat – and when sent traffic to 9001 I could not see any replies on the wan via a capture - which is why I tried to ping the AP ip.. And now I can not do anything.

    Curious why your on such an old version 2.0.1?

  • LAYER 8 Global Moderator

    hmmmm - this is a bit odd?

    So from the capture I do on your pfsense lan, I see my connection come in..  And the 8.7 AP syn,ack back – but then there is a RST that looks to come from my IP..  But doing a sniff on my end I never see your syn,ack - and I sure do not send RST..

    I will sniff on my wan to see if pfsense could of sent it..  But see on the bottom part of the pic my box at never sends RST.. He just keeps trying SYN because he never sees that syn,ack that I show on your side..  Where that RST is coming from has me curious.

    edit:  Ok see on my wan -- I never send RST.. So where is that RST coming from?

  • LAYER 8 Global Moderator

    Ok - your running proxy in transparent mode and captive portal, you have a issue with that setup.  if I turn off the squid and captive portal I can get in

    What I would suggest is address the design and configuration of the proxy and captive portal.. I did re-enable them and and now blocked again.

    You have a couple of packages outdated as well.. I would update to current 2.1.5 and look into the proxy/captive portal settings - looks like old, there is still setting for 192.168.10 in the external cache on the proxy, etc.?

    That explains where the RST was coming from ;)

  • Ok.  Thanks.

    I foolishly did not include the APs IP in the "allowed IPs" which bypass the captive portal.  I did allow a whole range of IPs to bypass, which included the APs, but altered the range recently, excluding the AP in error.

    For the proxy, I have now excluded private address spaces from being cached.

    Now working, and now disabled, now I know it works  :P

    It's always so obvious!

    Thanks for the help!

Log in to reply