Thanks for the information. I got the book already. I am setting up a few pfsense with embedded and hardware installation and try to migrate some sonicwall and cisco firewall. Some of the behavior on the pfsense doesn’t work the way it should. I may need to spend more time to see what’s wrong. Regarding on the pfsense book, do you know if any book base on ver 2.0 pfsense will come out soon? Thanks.

In order to NAT some and Bridge some you will need to split them. opt1  bridge opt2  NAT LAN private for desktops. You will need to port forward to any servers on OPT2 You will need a public IP for the pfsense box and 1 for every box behind the bridge.

Yup, using the internal IP address for the webserver solves the problem. Thanks.

Thanks for the quick reply.   ;) This modem gives you the concurrent ability to turn NAT on/off, independent of the DMZ options.  I did wonder how the DMZ would get its data tho, and your explanation on that front makes sense (that it just does double-NAT)… Just now found these links: http://wiki.m0n0.ch/wikka.php?wakka=AccessingModemOutsideFirewall http://forum.pfsense.org/index.php/topic,5727.0.html Showing that it can be a real hassle to get access to a bridged modem while still maintaining connection to the 'net. I can see in the majority of cases that an IP can still be set on the modem (one outside of your WAN or LAN subnets), then you can bridge it and authenticate with pfsense. Then if you really needed to get at the config on the modem, at the very least you could take a workstation with a static IP in the same subnet as the modem IP, connect direct (thus disconnecting the rest of the network) will allow you to get at your modem settings in a pinch? Not very elegant I realize, but after bridging I won't really need to check the status of the modem itself very often.  Did my logic make sense? For some reason I thought that bridging the modem precluded webconfig access, until it was master reset.  Thought of it as a universal convention, rather than something dependent on the type of hardware you are using...

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