I had installed squid at one point in time, but removed it.

I'm almost wondering if one of my packages didn't uninstall properly. I currently do not have any packages installed. I will be performing a fresh install this coming Friday when I have a maintenance window. If I exhibit the same symptoms I may give the BETA a try.

I don't think you can.  I seem to recall there is a restriction that you can't have pf operate on a packet that comes in interface X and then would go back out that same interface.  If you are trying to redirect LAN hosts trying to go to some web server behind pfsense, use split dns (e.g. hosts inside the LAN see a different IP address than outside ones.)  Alternatively, if 192.168.100.1 happens to be the same webserver you port-forward https to, then enable NAT reflection, but split dns is a better way.

Ooohhhh…

I found the problem... Nat reflection was disabled.. I just had to enable that again, and then it worked...

Pheww...

I think one way such a configuration can be done on pfSense is to set up your DHCP server to hand out the public IP addresses directly on the LAN (possibly bridging LAN with WAN, but I'm not completely sure).  Under such a configuration, you would have it on manual outbound NAT and have the list of rules there cleared.

When your computers don't have public IP addresses, the router needs to change the source IP address because outside computers and routers don't know how to access 192.168.x.x addresses through your router.  When your internal computers do have public IP addresses, outside computers and routers do know where to send packets to reach your connection, and thus no modification of the source IP address is required for the replies to arrive back at your router.

As far as I know, the router can say anything it wants for the source address when passing packets out from WAN to the Internet or out from LAN to your internal network.  To get a reply, it basically only needs to be an IP address that the destination knows how to reply to. (assuming the destination is on a different side of the router)  The router could probably even say that the source was just some random IP address on the Internet and the reply would go to that address, but the reply packets would most likely get dropped when they arrived because the computer or router at that address wouldn't be expecting the packets. (since neither side requested to open a connection with it)

@whorobj:

@danswartz:

that isn't how it works (as you discovered.)

why don't you tell him how it does then?

Because he already discovered how it works. Re-read the first post in the thread.

Oh yes, that will do the trick of course! Did not even think about it, but it's indeed very obvious. :)
Many thanks for your help!

For the outbound NAT rule, set the source to the terminal server IP, port 5002. Then set the translation to the other Virtual IP address with a port of 5001 with the static port option.

OK, I figured it out. I thought the traffic was being routed by the gateway so the source IP was the gateway IP since the mail server said traffic was coming from that IP. Since that traffic was actually going to a WAN IP (not WAN2), it was coming from the gateway since it was getting routing across the net between our 2 ISP's. For traffic actually going to a WAN2 IP, it was getting sent to PFSense from the system's LAN IP, which was being filtered since LAN IP's shouldn't be received on a WAN interface. If I allow the gateway's subnet in WAN2's firewall rules, then it works.

Sorry for the confusion, bothering you with a problem unrelated to PFsense. I should've realized this earlier.

Lots of options and things to consider here, really more than can be reasonably done in a forum thread. Designing a network to meet SAS70 requirements is an involved process.

Putting in a transparent firewall is definitely an option. That might not be the best one. Knowing that would take a few hours of discussing the environment and looking at options, not something you can get knocked out in a quick forum thread.

You'd be well served with a few hours of my time to help you work through the current design, options for a better design to meet your audit requirements, and the pros and cons of all the options. See the link in my sig for commercial support, it's next to nothing compared to the cost of a SAS70.  ;D  In a previous job, I did the security portion of SAS70 audits.

1:1 NAT does not open all ports to the server, it doesn't open anything at all by default. Your WAN firewall rules control what can be accessed.

i upgraded to 1.2.3 final. and this issue has been resolved…..

thanks for reply

I think this is a deficiency in the GUI - no way to specify that?

That helped, although I did try that before! Apparently I have not been doing it right. Thank you very much, ShadowFlare!

I have found a solution to this problem.  It first requires installing the "arping" package (which worked on my embedded installation–yea!)

Then I added a cron entry to send the appropriate command periodically for each IP I want to keep alive.  On Embedded, the only way to do this is to add to the cron entries in the /conf/config.xml file.  You'll see a number of them there already.  Just add entries with the following command:

/usr/local/sbin/arping -s <mac address="" of="" wan="" port="">-c 1 -i <interface name="">-S <external ip="">-t ff:ff:ff:ff:ff:ff <external_ip>For example:

/usr/local/sbin/arping -s 00:30:48:4b:a8:07 -c 1 -i vr1 -S 166.15.11.137 -t ff:ff:ff:ff:ff:ff 166.15.11.137

Hope this helps...</external_ip></external></interface></mac>

So today I spent some more time trying to get my PS3 to use UPnP to no avail…  UPnP is on in pfSense and I configured it according to a post on this forum.  I checked the PS3 and UPnP is enabled, and it's enabled on my wireless router as well (to which the PS3 will be connected).  My configuration is WAN, LAN, and OPT1WiFi.  I have the OPT1WiFi bridged with the LAN (not sure if this is correct, but it made the wireless work) and rules in the firewall are set to allow traffic to the device.

Everything looks as if it should work but when I check the connection on my PS3, the UPnP service always says "not available."

There is no solution for IPsec right now. It's a limitation of the underlying software.

There was a bounty open with a proposed solution but the funding was removed before any work could be completed, and it required some lower-level changes in C code in the software being used.

Check the expired bounties forum for more details.

That does indeed make sense, thank you!

~~Create two rules:
1: allow, source 123.123.123.123:any, destination 10.10.10.10:80
2: allow, source 111.111.111.111:any, destination 10.10.10.10:80

Of course you have to delete the autocreated firewall rules. Otherwise anyone will be allowed.
For the source you could also create an alias containing all the sources you want to allow and then use this alias as source.~~

edit: i see now what you mean.
I dont think this is possible with the gui.
But why would you want something like that?