Check out https://github.com/pfsense/pfsense-packages/blob/master/pkg_config.10.xml and search for
"<noembedded>true</noembedded>"

I think that is the right pkg_config file.

@fragged:

So you are trying to download a file from an internal server using your pfSense's WAN IP? Why? The problem you are seeing is NAT reflection. Just simply use the internal hostname or IP of the webserver.

Good point fragged… but i have to use the external domain name as the webserver uses the host header names to direct the request to the correct website on the server.

pfsense is port forwarding port 80 to the internal LAN IP of the web server. The domain name is used to direct which hosted site the webserver responds to.

The webserver is fully configured and working with several domains associated with it.
the default webserver is usually disabled, i only enabled it for teting this issue. So dumping a txt file on the default website is not possible for live work.

just seen BBcan177's reply too....

stand by i will just test using the url with host name, doamin and IP address etc.
to see what works and what does not.

oh...  for reference 1:1 NAT is disabled

console Results for: fetch -o testfile.txt "URL"

----Test Group 1----
using ip                            URL= h-t-t-p://x.x.x.x/pfsense/mylist.txt                                                works ok
using Hostname                        h-t-t-p://localservername/pfsense/mylist.txt                                works ok
using Hostname and domain    h-t-t-p://localservername.mydomain.co.uk/pfsense/mylist.txt      works ok

----Test Group 2----
using domain                            h-t-t-p://mydomain.co.uk/pfsense/mylist.txt                                  Fails.
using www.domain                  h-t-t-p://www.mydomain.co.uk/pfsense/mylist.txt                        Fails.

----Test Group 3----
ping  domain                      ping mydomain.co.uk                                  resolves ok.
ping  www.domain              ping www.mydomain.co.uk                        resolves ok.

Test group 1 all point to internal IP of webserver.... these all work so internal DNS lookup fine.
Test group 2 all point to WAN IP of router.... these all fail when used from the router console.
Test group 3 all point to WAN IP of router.... these all work ok when used from the router console ping.

**Moment of Inspiration!

Added "www" as a host pointing to the internal lan ip of the webserver in the DNS forwarder.
I can now resolve www.mydomain.co.uk to the internal ip of the web server.**

I think the key here is that the web server uses host headers to identify the website to access.
it expects to see "www.mysite.co.uk" in full.
so "mysite.co.uk" will not return a result.
hence the first test in group 2 failed and now works with "www" added.
pfsense now resolves www as an internal ip and at the same time has the full correct host header.

If this had not of worked my next step would have been..
Setup DNS to return a different result internally to externally, split-horizon DNS as BBcan177 suggested.

found this in the forum if this helps anyone….
https://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

Thank you very much for the info and advice... very much helped keep the brain cells working.
Thank you all.

18gr .22 800fps  ::)

Disclaimer: I have not thought for a moment about FreeRadius and what the actual changes are here.

Principle: This is an Open Source project. The project code is on GitHub https://github.com/pfsense/pfsense and https://github.com/pfsense/pfsense-packages
If you are into gory backend code and OS patches, there is also pfsense-tools for which there is an extra hoop to jump for access.
It is very easy to create a GitHub account if you do not already have one. Then for small things you do not need to install Git on your own device, just use the GitHub web interface. Drill down to the file in question, click the pencil to edit, make your changes, put a decent title and description of what and why it is "a good thing", save, press the button to make a pull request.

Those in charge of reviewing will be nice to you on your first try (I hope)

@laterdaze:

Indeed, the max table entries was set to 300K, a hold over from pfBlocker tuning no doubt.  Setting it to 2M resolved the memory allocation problem.  Specifying the list action as "Deny Both" causes the packets count to increase to something more like what I was seeing with pfBlocker.

Again, thanks for all that…

Glad you got it all sorted out  :)  .. Pls read this thread to see if you really need "Deny Both/Deny Inbound" Rules.

https://forum.pfsense.org/index.php?topic=86212.msg501258#msg501258

Thnx 4 the hint.  :)

worked fine

I'm setting up a network to help with some training and I've just spent all day trying to figure out how to allow traffic only from the UK to the OpenVPN port.
Finally figured it out thanks to your screen grab doktornotor  ;D

pfSense has a bit of steep learning curve for me but I'm getting there. Hopefully the new book will be out soon, I better start saving.
I've just registered to show my appreciation so I'll extend my thanks to BBCan177, the pfSense team and all contributors to these boards and the wiki.
Keep up the good work guys, it's certainly appreciated  8)

Cross reference here: https://forum.pfsense.org/index.php?topic=90700.0

sudo also has the same problem.

Solved.

In answer to the question, there are no special firewall rules required.  RADIUS authenticates over port 1812 (accounting is 1813) and the proxy listener that proxy messages are sent from is listening on port 1814 (there is a port 1816 for service status requests, but it does not appear to be necessary).  Since the proxy listener initiates the request from the pfSense installation, no outbound rule is required on the VLAN#2 interface, and no special inbound rules are required for the response.

As to what was wrong, if you are going to setup a proxy.conf file on your pfSense installation, make sure you add a proxy interface entry under interfaces.

It seems that by default the FreeRADIUS implementation puts the proxy listener on the first interface address that is not the localhost.  In my case it placed it on the 10.1.1.1 address for VLAN#1 as that was the first entry under the interfaces list.  Do not try to use src_ipaddr in proxy.conf, it won't stop the default listener setup, and will typically result in the listener from this setting being assigned to a random port each time the RADIUS service is started.

Without the proxy interface entry, although the kernel routes the requests to the correct interface, it doesn't do anything to check the validity of the source IP for the interface listening address (apparently a well known issue).  As a result, it was sending the packets out on to VLAN#2 from 10.1.2.1, but since the listener was on 10.1.1.1, the packets went out with the wrong IP address.

I now have a working FreeRADIUS proxy on my pfSense interfaces, with the actual authentication handled by a Kerberized RADIUS installation within a DMZ VLAN.

Regards,
Rob.

does anyone have a working Asterisk GUI?

When i go to http://MyIp:8888/gui/static/
I get:

Access Denied

You do not have permission to access the requested URL.

Asterisk Server

http.conf

[general]
enabled=yes
enablestatic=yes
bindaddr=0.0.0.0
bindport = 8888
prefix = gui
enablestatic = yes

–----------------------------------------
manager.conf

[general]
enabled = yes
webenabled = yes
port = 5038
bindaddr = 0.0.0.0

[admin]
secret = admin
read = system,call,log,verbose,command,agent,user,config,read,write,originate
write = system,call,log,verbose,command,agent,user,config,read,write,originate
ipermit=0.0.0.0

some one that know how to fix??