Nothing, per-se.  In automatic mode, there is an invisible rule that NAT things a certain way.  When you click manual, that rule appears explicitly and you can now tweak it.  Pfsense rewrites source port numbers in some situations and that can often cause problems.  static mode says to leave it alone.  This article on the wiki is more clear: http://doc.pfsense.org/index.php/Static_Port.

anything that is accessible to anyone (Internet or even intranet) should be on its own network for security reasons.
if its compromised so is the rest of the network.

Did you add a static route on pfSense that told it 192.168.11.x is reachable via 192.168.0.100?

Not yet, but that wont be a problem. (I think :P)
Need now 1st to forward tcp 25 and udp 1194 from my modem to pfSense, and make the tcp 25 outbound route over WANB.
tnx! :D

First Off, your any any default rule will allow all traffic to pass both ways and allow any client from either side to travel down the tunnel when they request it. You want to remove the allow all rule. Under The Rules section in the IPsec tab, you can deny and allow access how ever you want with your tunnel or tunnels. You need to focus primarly on your source and destination fields within the IPsec rules. Here you can specific a subnet or a single IP for source or destination.

So for example: I only want 1 system on my network to be able to travel across the tunnel to a remote network. Your rule would look like this

Proto         Source                   Port   Destination   Port   Gateway   Schedule   Description

192.168.1.10               *   10.2.2.20          *           *                                                  Test Tunnel Rule 1

The example up above will only allow this very thing to happen across the tunnel. Only 1 system from the LAN network will be able to access through the tunnel coming from any port and going to any port to only 1 specific system to the remote backup network. This is what you want, because nothing else can come back through your tunnel and access other systems on your network with out any addtional rule that allows it. In order to make the remote system at 10.2.2.20 to come back through the tunnel and talk with system 192.168.1.10, you would have to create another rule that looks like the following below.

Proto         Source            Port   Destination   Port   Gateway   Schedule   Description

10.2.2.20               *      192.168.1.10          *           *                                                Test Tunnel Rule 2

You can't easily enforce that, unfortunately.

You can do static ARP to ensure that those IPs and MACs are associated, but that also means you have to list every MAC address for every device that will communicate with the router.

(Also, static arp is very broken in 1.2.3. It works fine in 2.0 though.)

Can you elaborate the "my modem belkin i disable NAT and Firewall becuase that"?
Is the modem in bridge mode? Do you have a public IP on the pfSense directly?

Depending on how you are setting up access to the pfSense system, you may not even be using a port forward at all for that.  It only needs a firewall rule to allow it in, which is less than what is needed to access the AP from outside your network.

Anyway, I wouldn't recommend exposing it to the internet either.  It would be better to tunnel it through SSH (as already suggested) or a VPN.

This was added in 2.0, which is currently in beta.

@grazman:

I have a need for 1:1 NAT using one public IP address to accept traffic on a particular port and send it internally to another port, which seems simple enough.

This is normal port forwarding and not 1:1 NAT.

I also need outbound traffic destined for a particular CIDR to use a particular public IP address.

I see 1:1 NAT is not supported with NAT reflection. Are there any ways around this?

Firewall –> NAT --> outbound.
Enable manual rule generation and you can create rules to NAT as you want.

For reflection:
http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F

Port forwards do allow you to specify what the source must be for the rule to match in 2.0.

I've heard NAT is supposed to work on IPsec, though I haven't seen any reports on whether it does actually work after having added it to the list of available interfaces for NAT rules.

thanks a lot.  It turns out the wrt54G than i have on opt1 bridge with my lan is causing the ports to not forward properly.

guess ill try to make the ap work without bridging.

@jimp:

Are you doing a full traffic capture?

It could be doing some other kind of name query (like NBNS) and skipping DNS.

Thanks for the reply.  I just found the issue this evening…there was a registry entry on the server which pointed to the VIP of the SQL server...not sure where it came from but once I fixed that all was well.  Thanks again.

Steve

Why do you need to use both public ips?  I would assign 1 of the 2 to the wan port and leave the second one alone.  I wouldn't "assign" it at all actually.  I would set the wan interface to use dynamic ip.  Then nat behind that.

that test you linked only tests TCP ports, not UDP. There isn't a reliable way to test UDP being open. Probably a host firewall blocking it assuming the basic port forward is correct. http://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

Problem solved!  I moved away from pfSense and got a linksys router running DD-WRT and it works wonderfully.  Maybe someday this will work in pfSense since I like the sw so much better, but DD-WRT has VPN and NAT loopback operates great.

-Mike

So you want to spread your internal users out over multiple public IPs. You can do that via Outbound NAT. Put a few IPs on each outbound entry, one outbound entry per public IP.

Thanks!

I'll focus on the second case for now, since it's easier to explain.
It's definitely some issue on the pfSense box, whether it be a bug or config problem. I'll try to clarify a bit:

Basically, I have a machine (A) on the LAN making a request to another machine (B) on the LAN using an external IP that has NAT reflection enabled. When the UDP packet goes out on A, it hits the router (R), which from what I can tell, copies the packet and sends to machine B with R as the source. Machine B then correctly replies to the packet back to R, but then it seems to be dropped and never gets forwarded back to A.

The packet capture from before shows exactly that. I've confirmed the same results using Wireshark on both machines (essentially tcpdump on Windows).

Edit: I should also add that I can't use the split DNS option. Since this uses the steam service, they refer to all servers by IP afaik.