"Destination > any  >" Well that is wrong..  Dest would be your wan address. so you read the troubleshooting doc..  And did you follow it or just read it.  First thing to do is make sure the traffic is actually getting to pfsense wan.  Pfsense can not forward something it does not ever see. How are you testing this?  You need to make sure your coming from outside pfsense..  Your not trying to hit your pfsense wan IP from inside pfsense are you - that would be nat reflection and can be problematic and should really just be avoided.  There is never really a valid scenario that it makes sense. this really is clickity clickity..  Create your foward and your done.  If something is not working you either did it wrong or the traffic is not even getting to pfsense.  You also need to check your firewall on the box listening on 443.  maybe pfsense sends it through and that firewall blocks it?  You sure the box is even listening on 443?  Can you access it from a host on your lan directly? The troubleshooting guide covers pretty much every scenario that could be a problem. Its possible your isp blocks 443 and or you have a nat in front of pfsense that you did not forward 443 to your pfsense wan IP, etc. etc..

well quick test to make sure its pfsense or not, unplug pfsense lan from your network ;)  Does it still get answered?  If your showing an answer from that mac, then it would be in your clients arp table if on the same layer 2. But pfsense might be sending it out its wan, and something upstream could be answering.  If that is the case then yeah you would show mac of pfsense lan as the answering mac.. That would be my guess to what is happening. perfect example of this is me pinging my cable modem management IP ping 192.168.100.1 Pinging 192.168.100.1 with 32 bytes of data: Reply from 192.168.100.1: bytes=32 time=26ms TTL=63 Reply from 192.168.100.1: bytes=32 time=1ms TTL=63 Reply from 192.168.100.1: bytes=32 time<1ms TTL=63 Reply from 192.168.100.1: bytes=32 time=1ms TTL=63 my pfsense wan is public..  But I can still access my cable modem via that rfc1918 address since pfsense wan is directly connected to it.  If something on your wan answering - sniff on pfsense wan and find the mac that is answering.  It might be showing your gateway on your that network, but then you would know its something else upstream.

Generally, yeah, it's best to not loop traffic through the firewall where it's not strictly necessary to do so.

You will break things if you do as kpa advises. Don't.

Oh, I can't believe I overlooked that.  There are A LOT of virtual IP's on the system.  Thank you for the quick response!

No idea what you are doing with metasploit, so I can't comment there. Reflection is only needed if you are trying to hit the public IP of a box on your local network. e.g.- you have a web server on the lan that local clients hit via a public IP. Port forwards are not that hard. A typical forward for a web server would go something like- IF WAN Proto TCP Dest WAN address Dest port HTTP Redirect target IP 192.168.1.100 Redirect target port HTTP Description HTTP to web server Note that pfSense usually listens on TCP 443 (and maybe 22), so If you only have one IP, you'll need to change the webgui port to forward HTTPS to your WAN.

After two days I just found out that I should select LAN on Remote Logging Options / Source Address, to bind the correct interface. Now is working as expected. Thanks.

I tried to access it from another computer but web page is not opening. Pfsense is showing "192.168.1.1/24" but that is my router password, pfsense's system password is 192.168.1.2 and both of them not opening pf webui on other computer connected on same network, seems like i have done some mistake in configuration :) which ip address is needed to assign to pfsense lan interface (em0)?

Thanks for the clarification cmb. Noticed that when doing a ICMP traceroute it currently looks like this with 1:1 NAT and a ICMP-req permit any ingress rule: root@mybox:~$ traceroute -P ICMP www.mycorp.com traceroute to www.mycorp.com (178.29.55.4), 64 hops max, 72 byte packets 1  192.168.0.1 (192.168.0.1)  4.286 ms  0.853 ms  0.793 ms 2  * * * 3  * * * .... 12  isp-gw.isp.com (178.29.55.1) 37.324 ms 36.232 ms 37.232 ms 13  web.mycorp.com (178.29.55.101)  38.349 ms  37.285 ms  37.907 ms  <--- this would probably be the pfSense box at 178.29.55.100 14  web.mycorp.com (178.29.55.101)  37.661 ms  37.410 ms  36.496 ms So yes, it really seems that Freebsd 10.3 changed something.

ok man thanks for all of your help i really mean that you have got me further that anyone else on the other forums i really appreciate you i will read that link and hopefuly i get it thank you cheers

@johnpoz: you should be able to ping pfsense vlan20 address.  You allow ipv4 any any which would include icmp.. So if your not pinging something is wrong. You really can combine your block and allow rule and just make it allow ! rfc1918. So if I add your ICMP example (at the top?) and combine the last two rules I'm better off? I sure do appreciate you taking the time to help.  Not only do I want the rules but want to understand what's going on as well and you're helping with that.

@phil123456: ok I added a core and put 2gb instead of 512mb of ram, and now it seem to work fine jee snort is such a resource hog Yes, all IDS/IPS systems are resource hogs because of what they have to do.  If you start to run a full Snort or Suricata rule set, you may find even 2 GB of RAM can get a bit tight.  4 GB is a good RAM number for either Snort or Suricata in my view.  I suggest at least 2 cores for CPU, and 4 is even better. Bill

You can't negate table entries inside of a table. Create the table you want, then negate it in the rule where you're using it.

cu works great! Thanks

Build a firewall rule on your WAN with your PBX address as the source and your Linksys ATA LAN address as the destination. Make the ports whatever you use for SIP.  Generally 5060 on both sides. See if that helps.  Don't bother with port forwarding.

I have the US-150W-8 switch. I'll have a read through the links you posted.

Hi jimp, Thanks for the ultrafast reply :-) Yes indeed, it's the check_mk package. We're monitoring with it the firewalls and then we have all 5 minutes a login to the firewall via ssh from the monitoring host. I know check_mk can be used over a tcp-port but our development here decided to use it strictly over ssh, even when problems like this arise. (Which I don't understand why over ssh). On my private installation I'm using Zabbix as the monitoring, much more advanced, also encrypted direct agent/proxy communication and also great it is supported as a package by pfSense ;-) No problems with the Zabbix Agent there.

If it's in the FreeBSD base system dhclient you should file a PR against FreeBSD directly. At least from the description it sounds as though it may be a bug.