The subnet specified for the WAN side of the inner firewall should have been 192.168.1.0/24.  Once I fixed that, all is well.  Problem fixation.

Thanks to all,

I'm not understanding your question fully.  You want to screen ALL outbound traffic to web sites right?  So what is not working, and what happens instead.

You are correct that you cannot redirect traffic on one network segment back to a host in the same segment, unless if appears to be addressed outside the segment so that it gets routed to the gateway.  Think about it:  why would the switches and hosts bother addressing the gateway firewall if they are trying to reach a sibling host on their same subnet?  So hosts on the LAN are welcome to access their peers' http port without the firewall, but I think this is not your main concern.

Are you trying to do what captive portal does, maybe?  Might look at that.

Thanks again!

While sleepily changing IPs on the reverse proxy, I realised this would mean having to change how I ssh to the vms behind pfsense from the mac host, which is 192.168.1.1, and I'd also have to change IPs of the vms network adapters.
I'll have to forgo the flexibility and security of nating and try bridging WAN and LAN again.
Hopefully I can get it going now that I have network adapters currently working.

Yes that's possible. You have to have one rule per WAN, so that's two port forwards (they specify the public IP and that's different on each, hence the requirement).

Hey guys,

Sorry meant to get back to you - finally this one out.  Turns out that several stale MAC addresses on indirectly connected Cisco switches proved to be the issue (this would have been caused via my inter-vlan routing configuration).

Basically the pfsense instances having the problem were arping out for the administratively defined gateway.  These ip addresses were once in use on another portion of my network - the old MAC addresses were therefore still present in some (not all) of the multi-layer switches.  As a result, the virtual MAC of the gateway that the problem pfsense instances were seeing was forever changing (at least once a second as I found it in the pfsense logs).  Flushing the arp tables on the connecting switches and bringing the gateways back into the configuration with a new virtual mac address resolved the issues noted at the firewall layer. :-)

I'm not sure at face value without testing but I guess the same problem could arise if you aren't careful with an HSRP/VRRP configuration to be used for a pfsense gateway (since the likes of HSRP uses virtual MACS also).  Just a wee heads-up for anyone that might find it useful!

Cheers,

ehamil16

Sorry. Misinterpreted what was being asked for.

On the wan rules you don't need the 192.168.22 or 44/24 listed there. according to the diagram, those networks should not be on that side of the FW. plus the wan rule to block private ips above ensures that it will be blocked anyway.

Excellent! Thats worked, you are a star!!!!

Thank you very much for a quick resolution- i was almost about to give up on Pfsense!

Thanks

Hello, I do NAT but after some time has m external ports that I created stop working. What can be the problem? Do you have any examples?

@suicidegybe:

My question is can I send my port 80 request to some type of DNS serveice have it sent to my network under a diferent port and then once back inside my network sent to port 80 again. I know crazy but to get port 80 open it will at least double my monthly isp bill. If you know a way i'm all ears.

DNS doesn't do that…

You can and setup a NAT translation rule:
enable inbound port 8080 and set "Redirect target port" on the NAT rule to port 80

Then you can visit:
http://your_external_ip:8080/

That will be redirected to port 80 on your WHS.

Pretty sure he's looking for something like ProxyPass for apache.  I don't think there is a sutible module for pfSense, but I've never really looked for one before either.

Ok using the above info i found that it the ip address ending in 104 was not my old CSS server.  It was the UT3 server that had a port alias of 27000:28000.

Removed it, and redid those port forwards and its all good.

However it still doesnt explain the weird stuff I was seeing with the FTP servers.  Though that seemed to have stopped this morning as well.

Note to self…. no working on the firewall at 11 at night when you're too tired to see the most obvious things.

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: