That's the way that pf (the packet filtering software used by pfSense) works, and doing it this way has its own set of advantages as well. There's no way to change it that I'm aware of, I'm sure if you dig around the OpenBSD/pf docs you can find the reason why they decided on doing it that way.

Well I'm sure I'm being a dummy, but not quite THAT big a dummy, lol  ;) Yes, my pfSense DOES have a public IP address.  It's a machine I use to run a sizeable portion of our WISP, so of that I am quite, quite sure. OK, I tried a couple of things.  First of all, I reconfigured the camera to report on port 80, the standard http port (as you of course know).  Then I decided to NAT port 2468 to 80 in deference to the admittedly common proxy port being potentially blocked by sbcglobal or comcast ( I am connecting a workstation through the former and my service provider is the latter).  Here is a screen cap of what the firewall says: [image: firewallsays.png]

Got it figured out, the route does need to be set which is the ip of the cisco box itself even though there are 6 public ips. So the gateway of a public ip gets routed to another public ip on the same subnet to get sent back to the telco and out to the internet.

5060 needs to be TCP/UDP same with 5062 That should be fine. It even states that on the 3cx website firewall test.

I would also suggest some reading. http://slacksite.com/other/ftp.html If your forwarding port 20 you clearly don't understand how the ftp protocol works.  In no case would port 20 need to be forwarded.  20 is never used in an unsolicited manner to ftp server, as source port with ftp server creating the traffic - sure.  The state table of the firewall would allow the return traffic, never a reason to forward that port.

Ah … the user tried to hide his mistake ... happens all the time. Glad you have the issue resolved ... and don't have to make crazy flight plans for a 1 minute fix.

Destination address on the port forward should be an IP (or "WAN Address"), not 'any'.

Thank you. i've got it working and really love pfSense now. @cmb I know its not the perfect solution, but my Boss like to have it that way. The shares are only reachable from the IP of another Server and (of course) not the whole internet.

Thanks

@kappler0: Here is the NAT: [image: natft.png] What you're doing there is forwarding ports 3389-3399 on your WAN01 IP to the exact same port on 192.168.1.100. 3389 to 3389, 3390 to 3390, 3391 to 3391, etc. You only need 3389 there. Also make sure the Windows firewall isn't blocking it, it has the default behavior of blocking off-subnet RDP.

If it's a routed subnet, then there is no concept of a network or broadcast address, you can use all the IPs with NAT. There are a number of boxes out there running exactly that way that I've setup.

Assuming those IPs aren't being routed to you, you must configure virtual IPs for them.

I can only see that working on outbound NAT. Inbound is normally done to different hosts on the Vlans…..

I use pf 2.0.1 release w/ sip and rtp w/o a problem. i am also not using sipproxy my nat config is set to Manual Outbound Nat Generation with only 1 mapping for outbound which is : Interface Source Source Port Destination Destination Port NAT Address NAT Port Static Port Description WAN   192.168.0.20/32 * * * * * YES .20 above is the PBX port forwarding tab is set like this: If Proto Src. addr Src. ports Dest. addr Dest. ports NAT IP NAT Ports Description WAN UDP *         * WAN address 10000 - 20000 192.168.0.20 10000 - 20000   WAN UDP *        * WAN address 5004 - 5037 192.168.0.20 5004 - 5037   WAN UDP *        * WAN address 4569                192.168.0.20 4569   WAN UDP *        * WAN address 5039 - 5082 192.168.0.20 5039 - 5082 hopefully this formats properly for you. ports 10000-20000 are the RTP ports 5004-5082 will grab all the sip and if I remember 4569 was something used by my voip provider It took me a while to initially get the pbx and in/outbound calls to work. The best way to debug the issue is not w/ logs but use a cple tcpdumps at the same time from multiple terminals from pf box: tcpdump -v -i [WAN] src [voip provider] or dst [voip provider] tcpdump -v -i [LAN] src [voip provider] or dst [voip provider] from pbx: tcpdump -v -i [LAN] src [voip provider] or dst [voip provider] try to register the phone and make some calls/call in and watch the traffic flow, pay attn to port #s

try with``` netstat -lnptu

if you're on same lan gw has no influence what so ever trafic you send. gateway is only used for changing networks I know nothing about pgadmin, google it

Still running 1.2.3 here (better luck with VoIP traffic shaping than with 2.x so far.) This problem went away for a couple of weeks and then re-appeared today.  Nothing changed in pfSense config other than some dnsmasq static mappings (which regularly move about for testing.)  Running tcpdump on both the NAT target and on pfSense looking for the remote host IP shows the internal host sending keepalives to the ITSP, but nothing coming from them.  pfSense firewall rule logs packets that tcpdump does not report on either host: Act Time If Source Destination Proto Aug 2 13:37:32 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP Aug 2 13:37:30 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP Aug 2 13:37:29 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP Aug 2 13:37:28 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP Aug 2 13:37:21 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP Aug 2 13:37:19 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP Aug 2 13:37:18 NG0 66.241.X.Y:5060 192.168.X.24:5080 UDP pfsense:~#  tcpdump host 66.241.X.Y tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vr0, link-type EN10MB (Ethernet), capture size 96 bytes 13:36:19.710032 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:36:39.717413 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:36:59.723839 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:37:19.731218 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:37:39.737579 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:37:59.744985 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:38:19.751407 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:38:39.758748 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 13:38:59.765230 IP sipx.domain.com.5080 > 66.241.X.Y.5060: SIP, length: 4 [root@sipx sipxpbx]# tcpdump host 66.241.X.Y tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes 13:36:19.756734 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:36:39.757210 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:36:59.756742 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:37:19.757247 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:37:39.756711 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:37:59.757228 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:38:19.756763 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:38:39.757203 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4 13:38:59.756787 IP sipx.domain.com.5080 > 66.241.X.Y.sip: SIP, length: 4

Thank you for your help!

Trigger port forwarding is not really what you stated.. What you stated was sending to more than 1 pc behind your router unsolicited traffic at the same time. That is not what port trigger is, a trigger would allow you to take turns.. It can be used for allowing ports inbound when box is talking outbound on different ports or to different dst, etc.  But it does not allow that traffic at the same time. I don't believe there is anything in the gui for this, but I do believe you can do it with anchors and creating rules for pf directly.  I personally have never came across a need for port triggering in my time in IT, 25+ years. I think there was some bounties for adding this to the gui, but I don't think it ever went any where.